mysql bug? error after mysqlcheck optimize

hari ini ada error yang aneh sekali dimana saya tidak dapat login ke aplikasi php saya yang berbasis mysql. Action maintenance terakhir yang dilakukan adalah menjalankan mysqlcheck untuk mengecek database mysql (menggunakan opsi –check) & melakukan optimasi (menggunakan –optimize) database yang ada disana.

dari penggalian symptom, didapat bahwa aplikasi dapat connect ke database,  namun tidak dapat melakukan operasi update. pantesan websitenya bisa dibuka (operasi read), tapi ngak bisa login. karena operasi login akan menulis log ke database alias melakukan operasi update/insert.

investigasi dilanjutkan. ternyata penyebab error ini adalah database yang crash:

warning : Table is marked as crashed and last repair failed
warning : Size of datafile is: 845784 Should be: 802008
error : Record at: 3664 Can’t find key for index: 1
Got error: 144: Table ‘./dbtest/wp_commentmeta’ is marked as crashed and last (automatic?) repair failed when using LOCK TABLES

dan error permission:

[ERROR] bdb: /var/lib/mysql/mysqlXXX: Permission denied
dbtest.wp_options optimize error 9 when updating keyfile
dbtest.wp_options optimize Error Can’t change ownership of the file ‘/var/lib/mysql…
dbtest.wp_options optimize status Operation failed

bagi saya ini adalah error yang aneh sekali karena:

• aplikasi tidak pernah crash sehingga menyebabkan table crash
• komputer tidak pernah mati listrik mendadak sehingga menyebabkan table crash
• dan aplikasi telah berjalan beberapa lama dengan baik yang berarti user & permissionnya sudah benar.

namun sekarang kenapa jadi error begini ya? tidak masuk akal…

akhirnya saya putuskan untuk melakukan problem solving dahulu. permissionnya memang bermasalah, harusnya group dari file-file database adalah mysql, tetapi disini kok berubah menjadi 109 ya? alias memang tidak dikenali disystem. akhirnya problem permission ini saya bereskan dengan chown -R mysql:mysql, dan untuk crash table saya gunakan mysqlcheck –autorepair. anehnya lagi, ada beberapa table yang tidak mau direpair. akhirnya saya gunakan tools external (navicat) untuk repair, dan it works!! aneh sekali.

dari penelusuran lanjut, terlihat bahwa semua tabel yang bermasalah adalah tabel dengan type myisam. tabel bertipe innodb masih sehat walafiat. yah, myisam memang lebih rentan terhadap kerusakan data. hehehe

kesimpulannya:

• hati2 kalo pake tools mysqlcheck. terutama jika menggunakan opsi optimize. untuk lebih amannya sih jalankan mysqlcheck saat tidak ada query ke database
• ganti tipe engine table menjadi innodb karena lebih tahan crash jika dibandingkan dengan myisam

sekian, semoga berguna bagi pembaca.

URL pendek: http://wp.me/pRkxT-W5