GIT – Nguồn “7 Ways To Crash a Database” của tác giả Sean Hull, thành viên của linuxtoday.com.Tôi thấy đây là một bài viết hay nên cố gắng dùng chút vốn tiếng Anh hạn chế của mình để dịch lại, và chia sẻ với các bạn.

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  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.

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 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ặclà 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 hài hước trên.

[MySQL] Repair all Tables in all Database

Trong khi chạy hệ cơ sở dữ liệu MySQL trên hệ thống của bạn, sẽ có lúc bạn gặp phải sự cố này.Và hy vọng bài viết này có thể giúp ích ít nhiều cho công việc và các dự án của các bạn.

Yêu cầu xử lý trong trường hợp này là phải thật nhanh chóng, tránh tổn thất đến cho khách hàng và các người dùng cuối . Việc ngồi kiểm tra xem có những database nào và table nào đang lỗi một các thủ công là điều không tưởng. Vì vậy phải có giải pháp nhanh gọn tự động kiểm tra và repair table mysql nếu lỗi.

Ta có thể sử dụng đoạn lệnh sau (Trên OS ) :

mysqlcheck -u -p –auto-repair –check –optimize –all-databases

Tuy nhiên khi chạy hệ thống sẽ yêu cầu nhập root của MySQL.Vì ngay bản thân khách hàng cũng không nhớ được hoặc chưa cấu hình pass root cho MySQL, nếu nhập pass sai bạn sẽ nhận được thông báo:

“Access denied for user: ‘root@localhost’ (Using password: YES)”

Nên phải tìm cách thay đổi mật khẩu hoặc bypass bằng cách chạy mysqld_safe (Khởi động MySQL an toàn).

Ở đây tôi dùng cách chạy mysqld_safe :
– Đầu tiên phải kill các process MySQL đang running, không không thể chạy đc mysqld_safe

#kill -9 mysqld

– Tiếp đó chạy mysqld_safe

mysqld_safe -skip-grant-tables &

Sau khi thực hiện 2 bước trên, tôi đã có thể chạy dòng lệnh

mysqlcheck -u root -p –auto-repair –check –optimize –all-database

để giải quyết vấn đề khúc mắc.

Nếu bạn quên mật khẩu MySQL hoặc không thể gõ được mật khẩu MySQL, bạn có thể dùng cách sau để khôi phục lại mật khẩu

http://www.gocit.vn/bai-viet/khoi-phuc-mat-khau-root-mysql/

Print Friendly

Comments

comments

Bài viết liên quan