Cơ sở dữ liệu MySQL của tôi bị hỏng ... Tôi phải làm gì bây giờ?

Làm thế nào để các bảng MySQL bị hỏng? Có nhiều cách để làm hỏng các tệp dữ liệu. Thông thường, hỏng hóc là do các khiếm khuyết trong nền tảng cơ bản mà MySQL dựa vào để lưu trữ và truy xuất dữ liệu - hệ thống con đĩa, bộ điều khiển, kênh giao tiếp, trình điều khiển, phần sụn hoặc các lỗi phần cứng khác. Lỗi dữ liệu cũng có thể xảy ra nếu daemon máy chủ MySQL khởi động lại đột ngột hoặc máy chủ của bạn khởi động lại do sự cố của các thành phần hệ điều hành khác. Nếu phiên bản cơ sở dữ liệu đang ở giữa quá trình ghi dữ liệu vào đĩa, nó có thể ghi một phần dữ liệu mà có thể kết thúc với tổng kiểm tra trang khác với mong đợi. Cũng có lỗi trong MySQL, vì vậy ngay cả khi phần cứng máy chủ ổn, bản thân MySQL có thể gây ra lỗi.

Thông thường khi dữ liệu MySQL bị hỏng, khuyến nghị là khôi phục nó từ lần sao lưu cuối cùng, chuyển sang máy chủ DR hoặc gỡ bỏ nút bị ảnh hưởng nếu bạn có cụm Galera để cung cấp dữ liệu ngay lập tức từ các nút khác. Trong một số trường hợp, bạn không thể - nếu bản sao lưu không có ở đó, cụm chưa bao giờ được thiết lập, quá trình sao chép của bạn bị ngừng hoạt động trong một thời gian rất dài hoặc quy trình DR chưa bao giờ được kiểm tra. Ngay cả khi bạn có bản sao lưu, bạn vẫn có thể muốn thực hiện một số hành động để cố gắng khôi phục vì có thể mất ít thời gian hơn để trực tuyến trở lại.

MyISAM, xấu và xấu

InnoDB có khả năng chịu lỗi cao hơn MyISAM. InnoDB có các tính năng auto_recovery và an toàn hơn nhiều so với công cụ MyISAM cũ hơn.

Bảng MyISAM có thể dễ dàng bị hỏng khi ghi nhiều lần và có nhiều khóa xảy ra trên bảng đó. Công cụ lưu trữ "ghi" dữ liệu vào bộ đệm ẩn của hệ thống tệp, có thể mất một khoảng thời gian trước khi nó được chuyển vào đĩa. Do đó, nếu máy chủ của bạn khởi động lại đột ngột, một số lượng dữ liệu không xác định trong bộ đệm sẽ bị mất. Đó là một cách thông thường để dữ liệu MyISAM bị hỏng. Khuyến nghị là chuyển từ MyISAM sang InnoDB, nhưng có thể có những trường hợp không thực hiện được.

Primum non nocere, bản sao lưu

Trước khi bạn cố gắng sửa chữa các bảng bị hỏng, trước tiên bạn nên sao lưu các tệp cơ sở dữ liệu của mình. Có, nó đã bị hỏng nhưng điều này là để giảm thiểu rủi ro có thể có thêm thiệt hại do hoạt động khôi phục gây ra. Không có gì đảm bảo rằng bất kỳ hành động nào bạn thực hiện sẽ không gây hại cho các khối dữ liệu chưa được tác động. Buộc khôi phục InnoDB với các giá trị lớn hơn 4 có thể làm hỏng các tệp dữ liệu, vì vậy hãy đảm bảo rằng bạn sẽ thực hiện việc đó với bản sao lưu trước và lý tưởng là trên một bản sao vật lý riêng của cơ sở dữ liệu.

Để sao lưu tất cả các tệp từ tất cả cơ sở dữ liệu của bạn, hãy làm theo các bước sau:

Dừng máy chủ MySQL

service mysqld stop

Nhập lệnh sau cho datadir của bạn.

cp -r /var/lib/mysql /var/lib/mysql_bkp

Sau khi chúng tôi có bản sao lưu của thư mục dữ liệu, chúng tôi đã sẵn sàng để bắt đầu khắc phục sự cố.

Nhận dạng lỗi dữ liệu

Nhật ký lỗi là người bạn tốt nhất của bạn. Thông thường, khi lỗi dữ liệu xảy ra, bạn sẽ tìm thấy thông tin có liên quan (bao gồm các liên kết đến tài liệu) trong nhật ký lỗi. Nếu bạn không biết nó nằm ở đâu, hãy kiểm tra my.cnf và biến log_error, để biết thêm chi tiết, hãy kiểm tra bài viết này https://dev.mysql.com/doc/refman/8.0/en/error-log-destination-configuration. html. Những gì bạn cũng nên biết là loại công cụ lưu trữ của bạn. Bạn có thể tìm thấy thông tin này trong nhật ký lỗi hoặc trong information_schema.

mysql> select table_name,engine from information_schema.tables where table_name = '<TABLE>' and table_schema = '<DATABASE>';

Các công cụ / lệnh chính để chẩn đoán các vấn đề về hỏng dữ liệu là BẢNG KIỂM TRA, BẢNG SỬA CHỮA và myisamchk. Máy khách mysqlcheck thực hiện bảo trì bảng:Nó kiểm tra, sửa chữa (MyISAM), tối ưu hóa hoặc phân tích bảng trong khi MySQL đang chạy.

mysqlcheck -uroot -p <DATABASE>

Thay DATABASE bằng tên của cơ sở dữ liệu và thay TABLE bằng tên của bảng mà bạn muốn kiểm tra:

mysqlcheck -uroot -p <DATABASE> <TABLE>

Mysqlcheck kiểm tra cơ sở dữ liệu và bảng được chỉ định. Nếu một bảng vượt qua kiểm tra, mysqlcheck sẽ hiển thị OK cho bảng.

employees.departments                              OK
employees.dept_emp                                 OK
employees.dept_manager                             OK
employees.employees                                OK
Employees.salaries
Warning  : Tablespace is missing for table 'employees/salaries'
Error    : Table 'employees.salaries' doesn't exist in engine
status   : Operation failed
employees.titles                                   OK

Các vấn đề về hỏng dữ liệu cũng có thể liên quan đến các vấn đề về quyền. Trong một số trường hợp, Hệ điều hành có thể chuyển điểm gắn kết sang chế độ chỉ đọc do sự cố R / W hoặc điều này có thể do người dùng vô tình thay đổi quyền sở hữu tệp dữ liệu gây ra. Trong những trường hợp như vậy, bạn sẽ tìm thấy thông tin liên quan trong nhật ký lỗi.

[[email protected] employees]# ls -rtla
...
-rw-rw----. 1 mysql mysql  28311552 05-10 06:24 titles.ibd
-rw-r-----. 1 root  root  109051904 05-10 07:09 salaries.ibd
drwxr-xr-x. 7 mysql mysql      4096 05-10 07:12 ..
drwx------. 2 mysql mysql      4096 05-10 07:17 .

Máy khách MySQL

MariaDB [employees]> select count(*) from salaries;
ERROR 1932 (42S02): Table 'employees.salaries' doesn't exist in engine

Lỗi nhập nhật ký

2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Failed to find tablespace for table `employees`.`salaries` in the cache. Attempting to load the tablespace with space id 9
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Cannot open datafile for read-only: './employees/salaries.ibd' OS error: 81
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Operating system error number 13 in a file operation.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: The error means mysqld does not have the access rights to the directory.
2018-05-10  9:15:38 140703666226944 [ERROR] InnoDB: Could not find a valid tablespace file for `employees/salaries`. Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting-datadict.html for how to resolve the issue.

Khôi phục bảng InnoDB

Nếu bạn đang sử dụng công cụ lưu trữ InnoDB cho bảng cơ sở dữ liệu, bạn có thể chạy quy trình khôi phục InnoDB.
Để bật tính năng tự động khôi phục MySQL cần bật tùy chọn innodb_force_recovery. Innodb_force_recovery buộc InnoDB khởi động trong khi ngăn các hoạt động nền chạy, để bạn có thể kết xuất các bảng của mình.

Để thực hiện việc này, hãy mở my.cnf và thêm dòng sau vào phần [mysqld]:

[mysqld]
innodb_force_recovery=1
service mysql restart

Bạn nên bắt đầu từ innodb_force_recovery =1 lưu các thay đổi vào tệp my.cnf, sau đó khởi động lại máy chủ MySQL bằng lệnh thích hợp cho hệ điều hành của bạn. Nếu bạn có thể kết xuất các bảng của mình với giá trị innodb_force_recovery từ 3 trở xuống, thì bạn tương đối an toàn. Trong nhiều trường hợp, bạn sẽ phải tăng đến 4 và như bạn đã biết điều đó có thể làm hỏng dữ liệu.

[mysqld]
innodb_force_recovery=1
service mysql restart

Nếu cần, hãy thay đổi giá trị cao hơn, sáu là giá trị tối đa và nguy hiểm nhất.

Khi bạn có thể khởi động cơ sở dữ liệu của mình, hãy nhập lệnh sau để xuất tất cả cơ sở dữ liệu sang tệp databases.sql:

mysqldump --all-databases --add-drop-database --add-drop-table > dump.sql

Khởi động mysql, sau đó cố gắng loại bỏ cơ sở dữ liệu hoặc cơ sở dữ liệu bị ảnh hưởng bằng cách sử dụng lệnh DROP DATABASE. Nếu MySQL không thể xóa cơ sở dữ liệu, bạn có thể xóa cơ sở dữ liệu đó theo cách thủ công bằng các bước bên dưới sau khi dừng máy chủ MySQL.

service mysqld stop

Nếu bạn không thể xóa cơ sở dữ liệu, hãy nhập các lệnh sau để xóa cơ sở dữ liệu đó theo cách thủ công.

cd /var/lib/mysql
rm -rf <DATABASE>

Đảm bảo rằng bạn không xóa các thư mục cơ sở dữ liệu nội bộ.
Sau khi hoàn tất, hãy nhận xét dòng sau trong [mysqld] để tắt chế độ khôi phục InnoDB.

#innodb_force_recovery=...

Lưu các thay đổi vào tệp my.cnf, sau đó khởi động máy chủ MySQL

service mysqld start

Nhập lệnh sau để khôi phục cơ sở dữ liệu từ tệp sao lưu bạn đã tạo ở bước 5:

mysql> tee import_database.log
mysql> source dump.sql

Sửa chữa MyISAM

Nếu mysqlcheck báo lỗi cho một bảng, hãy nhập lệnh mysqlcheck với cờ -repair để sửa lỗi đó. Tùy chọn sửa chữa mysqlcheck hoạt động trong khi máy chủ đang hoạt động.

mysqlcheck -uroot -p -r <DATABASE> <TABLE>

Nếu máy chủ gặp sự cố và vì bất kỳ lý do gì mysqlcheck không thể sửa chữa bảng của bạn, bạn vẫn có tùy chọn để thực hiện khôi phục trực tiếp trên các tệp bằng myisamchk. Với myisamchk, bạn cần đảm bảo rằng máy chủ không có các bảng đang mở.

Dừng MySQL

service mysqld stop
cd /var/lib/mysql

Thay đổi thư mục chứa cơ sở dữ liệu.

cd /var/lib/mysql/employees
myisamchk <TABLE>

Để kiểm tra tất cả các bảng trong cơ sở dữ liệu, hãy nhập lệnh sau:

myisamchk *.MYI

Nếu lệnh trước đó không hoạt động, bạn có thể thử xóa các tệp tạm thời có thể ngăn myisamchk chạy chính xác. Để thực hiện việc này, hãy thay đổi trở lại thư mục dir dữ liệu, rồi chạy lệnh sau:

ls */*.TMD

Nếu có bất kỳ tệp .TMD nào được liệt kê, hãy xóa chúng:

rm */*.TMD

Sau đó, chạy lại myisamchk.

Để sửa chữa bảng, hãy thực hiện lệnh sau, thay thế TABLE bằng tên của bảng mà bạn muốn sửa chữa:

myisamchk --recover <TABLE>

Khởi động lại máy chủ MySQL

service mysqld start

Cách tránh mất dữ liệu

Có một số điều bạn có thể làm để giảm thiểu nguy cơ dữ liệu không thể khôi phục. Trước hết là các bản sao lưu. Vấn đề với các bản sao lưu là đôi khi chúng có thể bị bỏ qua. Đối với các bản sao lưu theo lịch trình cron, thông thường chúng tôi viết các tập lệnh trình bao bọc để phát hiện sự cố trong nhật ký sao lưu, nhưng điều đó không bao gồm các trường hợp khi sao lưu hoàn toàn không bắt đầu. Cron đôi khi có thể bị treo và thường không có thiết lập giám sát trên đó. Một vấn đề tiềm ẩn khác có thể là trường hợp sao lưu chưa bao giờ được thiết lập. Thực tiễn tốt là chạy báo cáo từ một công cụ riêng biệt sẽ phân tích trạng thái sao lưu và thông báo cho bạn về lịch trình sao lưu bị thiếu. Bạn có thể sử dụng ClusterControl cho việc đó hoặc viết các chương trình của riêng bạn.

Để giảm tác động của việc dữ liệu có thể bị hỏng, bạn nên luôn xem xét các hệ thống được phân cụm. Cơ sở dữ liệu sẽ gặp sự cố hoặc bị hỏng chỉ là vấn đề thời gian, vì vậy, rất tốt để có một bản sao để bạn có thể chuyển sang. Nó có thể là bản sao Master / Slave. Khía cạnh quan trọng ở đây là khôi phục tự động an toàn để giảm thiểu sự phức tạp của trình chuyển đổi và giảm thiểu thời gian khôi phục (RTO).