Database MySQL Saya Rusak... Apa yang Harus Saya Lakukan Sekarang?

Bagaimana tabel MySQL bisa rusak? Ada banyak cara untuk merusak file data. Seringkali, korupsi disebabkan oleh cacat pada platform yang mendasarinya, yang diandalkan MySQL untuk menyimpan dan mengambil data - subsistem disk, pengontrol, saluran komunikasi, driver, firmware, atau kesalahan perangkat keras lainnya. Kerusakan data juga dapat terjadi jika daemon server MySQL dimulai ulang secara tiba-tiba, atau server Anda melakukan boot ulang karena kerusakan komponen OS lainnya. Jika instance database sedang menulis data ke disk, itu bisa menulis data sebagian yang mungkin berakhir dengan checksum halaman yang berbeda dari yang diharapkan. Ada juga bug di MySQL sehingga meskipun perangkat keras server baik-baik saja, MySQL sendiri dapat menyebabkan kerusakan.

Biasanya ketika data MySQL rusak, rekomendasinya adalah mengembalikannya dari cadangan terakhir, beralih ke server DR atau menghapus node yang terpengaruh jika Anda memiliki cluster Galera untuk segera melayani data dari node lain. Dalam beberapa kasus Anda tidak bisa - jika cadangan tidak ada, cluster tidak pernah diatur, replikasi Anda turun untuk waktu yang sangat lama, atau prosedur DR tidak pernah diuji. Meskipun Anda memiliki cadangan, Anda mungkin masih ingin melakukan beberapa tindakan untuk mencoba pemulihan karena mungkin perlu waktu lebih sedikit untuk kembali online.

MyISAM, yang jelek dan jelek

InnoDB lebih toleran terhadap kesalahan daripada MyISAM. InnoDB memiliki fitur auto_recovery dan jauh lebih aman dibandingkan dengan mesin MyISAM yang lebih lama.

Tabel MyISAM dapat dengan mudah rusak ketika banyak penulisan terjadi dan banyak kunci terjadi pada tabel itu. Mesin penyimpanan "menulis" data ke cache sistem file, yang mungkin memerlukan beberapa waktu sebelum dipindahkan ke disk. Oleh karena itu jika server Anda restart tiba-tiba, sejumlah data yang tidak diketahui dalam cache akan hilang. Itu cara yang biasa untuk data MyISAM rusak. Rekomendasinya adalah bermigrasi dari MyISAM ke InnoDB, tetapi mungkin ada kasus di mana hal ini tidak memungkinkan.

Primum non nocere, cadangan

Sebelum Anda mencoba untuk memperbaiki tabel yang rusak, Anda harus membuat cadangan file database Anda terlebih dahulu. Ya, memang sudah rusak tetapi ini untuk meminimalkan risiko kemungkinan kerusakan lebih lanjut yang mungkin disebabkan oleh operasi pemulihan. Tidak ada jaminan bahwa tindakan apa pun yang Anda ambil tidak akan membahayakan blok data yang tidak tersentuh. Memaksa pemulihan InnoDB dengan nilai lebih besar dari 4 dapat merusak file data, jadi pastikan Anda melakukannya dengan pencadangan sebelumnya dan idealnya pada salinan fisik database yang terpisah.

Untuk mencadangkan semua file dari semua database Anda, ikuti langkah-langkah berikut:

Hentikan server MySQL

service mysqld stop

Ketik perintah berikut untuk direktori data Anda.

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

Setelah kami memiliki salinan cadangan direktori data, kami siap untuk memulai pemecahan masalah.

Identifikasi Korupsi Data

Log kesalahan adalah teman terbaik Anda. Biasanya, ketika terjadi kerusakan data, Anda akan menemukan informasi yang relevan (termasuk tautan ke dokumentasi) di log kesalahan. Jika Anda tidak tahu di mana letaknya, periksa my.cnf dan variabel log_error, untuk lebih jelasnya periksa artikel ini https://dev.mysql.com/doc/refman/8.0/en/error-log-destination-configuration. html. Yang juga harus Anda ketahui adalah jenis mesin penyimpanan Anda. Anda dapat menemukan informasi ini di log kesalahan atau di information_schema.

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

Alat/perintah utama untuk mendiagnosis masalah dengan korupsi data adalah CHECK TABLE, REPAIR TABLE, dan myisamchk. Klien mysqlcheck melakukan pemeliharaan tabel:Ini memeriksa, memperbaiki (MyISAM), mengoptimalkan atau menganalisis tabel saat MySQL sedang berjalan.

mysqlcheck -uroot -p <DATABASE>

Ganti DATABASE dengan nama database, dan ganti TABLE dengan nama tabel yang ingin diperiksa:

mysqlcheck -uroot -p <DATABASE> <TABLE>

Mysqlcheck memeriksa database dan tabel yang ditentukan. Jika sebuah tabel lolos pemeriksaan, mysqlcheck menampilkan OK untuk tabel tersebut.

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

Masalah korupsi data mungkin juga terkait dengan masalah izin. Dalam beberapa kasus, OS dapat mengalihkan mount point ke mode read-only karena masalah R/W atau ini dapat disebabkan oleh pengguna yang secara tidak sengaja mengubah kepemilikan file data. Dalam kasus seperti itu, Anda akan menemukan informasi yang relevan di log kesalahan.

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

Klien MySQL

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

Entri log kesalahan

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.

Memulihkan tabel InnoDB

Jika Anda menggunakan mesin penyimpanan InnoDB untuk tabel database, Anda dapat menjalankan proses pemulihan InnoDB.
Untuk mengaktifkan pemulihan otomatis, MySQL memerlukan opsi innodb_force_recovery untuk diaktifkan. Innodb_force_recovery memaksa InnoDB untuk memulai sekaligus mencegah operasi latar belakang berjalan, sehingga Anda dapat membuang tabel Anda.

Untuk melakukan ini, buka my.cnf dan tambahkan baris berikut ke bagian [mysqld]:

[mysqld]
innodb_force_recovery=1
service mysql restart

Anda harus mulai dari innodb_force_recovery=1 menyimpan perubahan ke file my.cnf, dan kemudian restart server MySQL menggunakan perintah yang sesuai untuk sistem operasi Anda. Jika Anda dapat membuang tabel Anda dengan nilai innodb_force_recovery 3 atau kurang, maka Anda relatif aman. Dalam banyak kasus, Anda harus naik ke 4 dan seperti yang sudah Anda ketahui bahwa itu dapat merusak data.

[mysqld]
innodb_force_recovery=1
service mysql restart

Jika perlu, ubah ke nilai yang lebih tinggi, enam adalah nilai maksimum dan paling berbahaya.

Setelah Anda dapat memulai database Anda, ketik perintah berikut untuk mengekspor semua database ke file databases.sql:

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

Mulai mysql, lalu coba hapus database atau database yang terpengaruh menggunakan perintah DROP DATABASE. Jika MySQL tidak dapat menghapus database, Anda dapat menghapusnya secara manual menggunakan langkah-langkah di bawah ini setelah Anda menghentikan server MySQL.

service mysqld stop

Jika Anda tidak dapat menghapus database, ketik perintah berikut untuk menghapusnya secara manual.

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

Pastikan Anda tidak menghapus direktori database internal.
Setelah selesai, beri komentar pada baris berikut di [mysqld] untuk menonaktifkan mode pemulihan InnoDB.

#innodb_force_recovery=...

Simpan perubahan ke file my.cnf, lalu jalankan server MySQL

service mysqld start

Ketik perintah berikut untuk memulihkan database dari file cadangan yang Anda buat pada langkah 5:

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

Memperbaiki MyISAM

Jika mysqlcheck melaporkan kesalahan untuk tabel, ketik perintah mysqlcheck dengan flag -repair untuk memperbaikinya. Opsi perbaikan mysqlcheck berfungsi saat server aktif dan berjalan.

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

Jika server sedang down dan karena alasan apa pun mysqlcheck tidak dapat memperbaiki tabel Anda, Anda masih memiliki opsi untuk melakukan pemulihan langsung pada file menggunakan myisamchk. Dengan myisamchk, Anda perlu memastikan bahwa server tidak membuka tabel.

Hentikan MySQL

service mysqld stop
cd /var/lib/mysql

Ubah ke direktori tempat database berada.

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

Untuk memeriksa semua tabel dalam database, ketik perintah berikut:

myisamchk *.MYI

Jika perintah sebelumnya tidak berfungsi, Anda dapat mencoba menghapus file sementara yang mungkin mencegah myisamchk berjalan dengan benar. Untuk melakukannya, ubah kembali ke direktori data dir, lalu jalankan perintah berikut:

ls */*.TMD

Jika ada file .TMD yang terdaftar, hapus file tersebut:

rm */*.TMD

Kemudian jalankan kembali myisamchk.

Untuk mencoba memperbaiki tabel, jalankan perintah berikut, ganti TABLE dengan nama tabel yang ingin Anda perbaiki:

myisamchk --recover <TABLE>

Mulai ulang server MySQL

service mysqld start

Cara menghindari kehilangan data

Ada beberapa hal yang dapat Anda lakukan untuk meminimalkan risiko data yang tidak dapat dipulihkan. Pertama-tama backup. Masalah dengan pencadangan adalah terkadang mereka dapat diabaikan. Untuk pencadangan terjadwal cron, biasanya kami menulis skrip pembungkus yang mendeteksi masalah di log pencadangan, tetapi itu tidak termasuk kasus ketika pencadangan tidak dimulai sama sekali. Cron terkadang bisa hang dan seringkali tidak ada set pemantauan di atasnya. Masalah potensial lainnya dapat terjadi ketika cadangan tidak pernah disiapkan. Praktik yang baik adalah menjalankan laporan dari alat terpisah yang akan menganalisis status pencadangan dan memberi tahu Anda tentang jadwal pencadangan yang hilang. Anda dapat menggunakan ClusterControl untuk itu atau menulis program Anda sendiri.

Untuk mengurangi dampak kemungkinan korupsi data, Anda harus selalu mempertimbangkan sistem berkerumun. Hanya masalah waktu ketika database akan crash atau rusak, jadi ada baiknya untuk memiliki salinan yang dapat Anda alihkan. Bisa jadi replikasi Master / Slave. Aspek penting di sini adalah memiliki pemulihan otomatis yang aman untuk meminimalkan kerumitan peralihan dan meminimalkan waktu pemulihan (RTO).