Các nguyên nhân gây lỗi crash database MySQL

  • Friday 21/08/2020

1. Don’t Take Backups: Không có sao lưu cơ sở dữ liệu

Phần cứng hư hại là chuyện thường xảy ra ở các trung tâm dữ liệu. do đó nếu không sao lưu dữ liệu thường xuyên thật sự là một thảm họa.Ổ cứng hư, hư nguồn, rút ra gắn vào các linh kiện đều có thể dấn đến crash database.
*Không nên lưu backup trên cùng 1 ổ hay 1 máy chủ với dịch vụ đang chạy.

2. Don’t Watch the Error Logs: Không kiểm tra các file Logs lỗi

File Logs lỗi có thể cảnh báo sớm cho bạn về các nguy cơ của hệ thống.Một số thông tin chỉ ra được các vấn đề sẽ xảy ra, và sẽ trở nên nghiêm trọng nếu như bạn bỏ qua.Vì vậy, nếu muốn hệ thống Database của bạn bị Crash, đừng xem các logs lỗi!

3. Don’t Use Memory Wisely: Không sử dụng bộ nhớ một cách khôn ngoan

Ngày nay tôi biết hệ thống của bạn được trang bị bộ nhớ, RAM rất lớn, lên đến 8G, 16GB, 32GB, chắc chắn thế.Bạn không phải lo lắng gì về bộ nhớ của bạn cả.Chỉ cần phân chia theo ý bạn thích, hoặc tốt hơn hết là để mặc định.Làm sao MySQL biết bạn có bao nhiêu GB bộ nhớ, hoặc bạn muốn dùng như thế nào.Mọi thứ sẽ trôi đi sạch sẽ.Không tin thì bạn đừng phân chia bộ nhớ, ngay cả trên server có bộ nhớ lớn, và server bạn sẽ bị Crash.Vậy nếu không muốn hệ thống ổn định, đừng phân chia bộ nhớ một cách khôn ngoan.

Bạn có thể dùng mysqltuner.pl để tính toán và tối ưu các thiết lập mysql 1 cách tối ưu nhất

4. Don’t Tune Queries: Không tối ưu các query

Các câu truy vấn luôn là sở thích của tôi. Nếu bạn muốn chắc chắn server mình sẽ bị crash, cứ để nó chạy hết cỡ. Tôi có 1 server lớn, rất nhiều bộ nhớ và ỗ đĩa tốc độ cao, đó là lý do tôi không lo lắng. Người phát triển mã nguồn dùng tìm kiếm toàn bộ trên các table, bỏ việc cache các query vào sọt rác, và bộ nhớ đệm của Innodb sẽ bị quá tải. Bạn tập trung vào ổ đĩa cứng như muốn nó thay thế bộ nhớ? Chả có vấn đề gì cả, mọi thứ rất nhanh. Đó là điều chắc chắn rằng đến mùa thu này, bạn sẽ dùng server để gối đầu mà ngủ nếu nhưng không tối ưu các cấu truy vấn, hoặc hãy làm điều đó ngay đi.

5. Don’t Worry About Indexes: Không quan tâm đến việc Indexes

Indexes là điều tôi yêu thích. Quên đi Indexes sẽ tàn phá hệ thống mọi lúc. Muốn điều khiển server bạn 60mph như trên đường cao tốc, nhưng điều đầu tiên là gì? Chắc chắn, đừng lo lắng quá nhiều về index table. Nó đã được làm trong quá trình phát triển ứng dụng. Vấn đề là khi sản xuất phần mềm, tác giả không thể phân tích hết được các nhu cầu thực tế, hệ thống chịu đựng hàng triệu và hàng triệu các câu truy vấn mỗi ngày. Như vậy, vài index cần thiết bị lãng quên sẽ biến các query thành những con chó hung dữ, cắn phá hệ thống của bạn đến lúc sập thì thôi. Bởi vậy, ko dùng các indexes là một nguyên nhân khác gây Crash Database.

6. Don’t Use Fast or Reliable Disk: Không sử dụng ổ đĩa cứng có tốc độ cao hoặc của hãng đáng tin cậy

Bạn chắc chắn I/O (Input/Output của ổ cứng) hoạt động bình thường trên 1 ổ đơn, hoặc là dùng 1 ổ khác nữa. Hệ thống của bạn sẽ luôn chiến đấu với database và ngược lại. Điều đó có nghĩa là luôn luôn có một hàng đợi song song để phục vụ cho 1 nhu cầu tại cùng một thời điểm.Thứ hai là sử dụng RAID-5.Thông thường các website, hệ thống lớn xử lý dữ liệu rất nhiều.RAID-5 có thể an toàn khi lỗi 1 ổ cứng. Nhưng không may ổ lỗi thường đi theo 1 cặp. Ngày nay database ghi xuống rất nhiều thứ, log nhị phân, log lỗi, các câu truy vấn chậm, và nhiều thứ khác. Như vậy nếu không dành sự quan tâm cho RAID-10, và không quan tâm đến I/O của hệ thống thì blog,website của bạn sẽ bị down, khi 1 ổ của bạn bị lỗi, hoặc cả 2 ổ đều lỗi.

7. Don’t Document Procedures and Configurations: Không theo thủ tục và tài liệu khi cấu hình

Mỗi DBA (Database Administrator – Người quản trị dữ liệu) và người phát triển tôi đều nói chuyện về việc tạo các tài liệu trong công việc của họ. Hey không bận tâm. Khi bạn đi ra ngoài, hoặc có ai đó đến hỗ trợ, không có tài liệu thì điều chắc chắn có thể là 1 hoặc 2 thứ sẽ bị xóa nhầm, dọn dẹp hoặc bỏ sót một thủ tục sao lưu, bảo trì cần thiết. Vâng, nếu bạn muốn dữ liệu của bạn không ổn định, thì đừng quan tâm đến thủ tục, tài liệu cấu hình.

Conclusion Kết luận

We hope you’ve enjoyed our hopefully comical journey through some of the mishaps and troubles we all want to avoid. Our day-to-day goal of course is keeping systems reliable. So we hope by turning this goal upside-down, we can more easily illustrate the risks and dangers that good DBA best practices help to avoid.

Chúng tôi ngày qua ngày muốn học cách ổn định hệ thống. Bằng cách xoay ngược vấn đề, chúng ta dễ dàng minh họa được các rủi ro và nguy hiểm của Database Administrator sẽ gặp phải và tìm cách tránh nó, hy vọng bạn có thể hiểu và thích cách viết này.

Nguồn “7 Ways To Crash a Database” của tác giả Sean Hull, thành viên của linuxtoday.com.

Trường hợp không may hệ thống MySQL database của bạn bị crash, bạn tham khảo thêm tại

Hướng dẫn xử lý database innodb MySQL bị crash

Hướng dẫn repair MySQL database sử dụng command line