lifelong learner — urip iku urup, currently working on accenture.

Mysql berhenti secara tiba-tiba : myisam-recover error

0
Degananda.com -

Hari ini terjadi suatu peristiwa yang belum pernah kami alami yakni berhentinnya mysql services secara sendirinnya / otomatis. Simak ulasan ini untuk mengetahui bagaimana mysql dapat berhenti secara tiba-tiba.

Senin, 24 Juli 2017 seperti biasa kami membuka website degananda.com. Namun, terjadi hal yang kurang menyenangkan bagi kami yakni website tidak dapat dibuka dan muncul peringatan berupa gagal melakukan koneksi ke database. Kami menggunakan wordpress untuk mensetup degananda.com sehingga terlihat bahwa konfigurasi yang disimpan dalam wp-config.php gagal dijalankan dengan baik. Disini kami berasumsi mengenai kemungkinan-kemungkinan yang terjadi.

Pertama yakni, website degananda.com dihack dan dicrack dengan mengubah username dan password mysql ataupun ditambah melakukan dump terhadap schema  maupun databasenya. Poin pertama ini sangat menganggu pikiran kami karena backup terahir dilakukan pada awal bulan juli ini. Sehingga kami sangat tidak berharap terjadinnya asumsi pertama ini.

Asumsi kedua yang merupakan harapan kami yaitu service dari mysql berhenti.  Kami yakin bahwa services mysql berhenti dikarenakan pada phpmyadmin ketika kita memasukan username dan password yang salah biasannya hanya akan memunculkan error berupa “cannot login to mysql server”.

Namun, pada kasus yang kami alami ketika mencoba username dan password yang salah terdapat dua pesan error yang ditampilkan. Yang pertama seperti gambar diatas dan yang kedua berbunyi ” Connection for controluser as defined in your configuration failed”. Mohon maaf kami tidak sempat menscreenshot pesan error yang kedua.  Sehingga karena terdapat dua pesan error kami yakin bahwa tidak terjadi “hacking” pada degananda.com

Pembuktian

untuk membuktikan kedua asumsi atau hipotesa tadi kami memutuskan untuk melakukan beberapa hal. Pertama adalah mengecek apakah terjadi perubahan password untuk mysql. File konfigurasi mysql terletak pada (kami menggunakan ubuntu)  , /etc/phpmyadmin/config-db.php Kami menjalan perintah

nano /etc/phpmyadmin/config-db.php

dan alhamdulillah tidak ada konfigurasi yang berubah terutama username dan password dari mysql.

asumsi pertama mengenai pergantian username dan password mysql dapat terbantahkan namun ini tidak menutup kemungkinan terjadinnya perusakan pada database. Kami sampingkan dulu kekhawatiran terjadinnya perusakan database dengan fokus untuk membuktikan asumsi yang kedua. Asumsi kedua kami yaitu menyatakan bahwa services dari mysql berhenti secara tiba-tiba. Untuk mengetahui apakah suatu services (dalam kasus ini mysql) maka kami menjalankan perintah dibawah ini.

ps -ax | grep "mysql"

grep adalah fungsi untuk melakukan search pada hasil dari suatu perintah yang ada pada terminal. Perintah diatas akan mencari apakah terdapat service mysql yang sedang berjalan.

dan ternyata, tidak terdapat service yang berjalan. Pada gambar diatas proses yang mengandung kata “mysql” adalah perintah ps -ax | grep “mysql” itu sendiri terlihat pada kata “grep” pada samping kanan (sebelum –color). Kami sangat lega karena hanya service dari mysql yang berhenti secara tiba-tiba. Padahal hari sebelumnya (minggu, 23 juli 2017) website masih dapat diakses secara normal.

Ahirnya kami menjalankan kembali services dari mysql dengan menggunakan perintah

service mysql start

alhamdulillah, website degananda.com dapat diakses kembali. Namun kemudian, muncul suatu pertanyaan apakah yang membuat mysql dapat berhenti secara tiba-tiba. Kami tidak pernah mematikan mysql sebelumnya. Namun memang ada kemungkinan terdapat “orang” yang dengan sengaja mematikan mysql. Tetapi kami rasa hal ini kecil karena server ini menggunakan ssh. Sehingga sangat susah untuk mendapatkan akses rootnya. Jika memang mendapatkan akses rootnya lantas mengapa hanya mematikan mysqlnya?. Sehingga kami asumsikan root aman dari pihak luar yang tidak bertanggung jawab.

Penyebab Mysql berhenti tiba-tiba

Ahirnya kami memutuskan untuk mencari tahu alasan-alasan yang menyebabkan berhentinnya mysql secara tiba-tiba. Namun sebelumnya, kita akan melihat log dari mysql untuk mengetahui sebab berhentinnya mysql. Lokasi log untuk mysql berada pada file /var/log/mysql/error.log (kami menggunakan ubuntu). Kita dapat mengkasesnya menggunakan nano ataupun tail. Berikut ini perintah yang kami gunakan untuk membaca log mysql.

nano /var/log/mysql/error.log

dari perintah diatas terlihat error yang terjadi sejak pukul 7.23 pagi tadi (24 juli 2017).

berdasarkan log diatas mysql “shutdown” atau mati secara tidak normal diakibatkan berbagai hal yang terjadi sesuai dengan log diatas yakni :

170724  7:23:26 [Warning] Using unique option prefix myisam-recover instead of myisam-recove$

170724  7:23:26 [Note] Plugin ‘FEDERATED’ is disabled.

170724  7:23:26 InnoDB: The InnoDB memory heap is disabled

170724  7:23:26 InnoDB: Mutexes and rw_locks use GCC atomic builtins

170724  7:23:26 InnoDB: Compressed tables use zlib 1.2.8

170724  7:23:26 InnoDB: Using Linux native AIO

170724  7:23:26 InnoDB: Initializing buffer pool, size = 128.0M

170724  7:23:26 InnoDB: Completed initialization of buffer pool

170724  7:23:26 InnoDB: highest supported file format is Barracuda.

InnoDB: The log sequence number in ibdata files does not match

InnoDB: the log sequence number in the ib_logfiles!

170724  7:23:26  InnoDB: Database was not shut down normally!

penyebab utamannya adalah “Using unique option prefix myisam-recover instead of myisam-recover”. Berdasarkan beberapa penjelasan yang kami peroleh dibawah ini

https://support.plesk.com/hc/en-us/articles/213943785-Mysql-shows-warning-Using-unique-option-is-deprecated-and-will-be-removed-in-a-future-release

hal ini terjadi dikarenakan perintah myisam-recover ini telah mengalami “deprecated”  a.k.a fitur atau perintah tersebut sudah tidak didukung lagi oleh mysql. Sangat logis, kemungkinan saat melakukan update mysql ada beberapa konfigurasi yang terlewat.

Solusi

Sehingga solusinnya adalah mengganti “myisam-recover” menjadi “myisam-recover-options” pada my.cnf. Untuk kasus kami(ubuntu 14.04) my.cnf berada pada /etc/mysqk/my.cnf

Pelajaran

Sehingga, berkaca pada kasus diatas, melakukan BACKUP untuk database sangatlah penting. Hal ini sangat memberikan pelajaran berharga khususnya bagi kami. Jika memungkinkan backup dilakukan berkala. Karena tanpa adannya backup jika terjadi hal-hal yang tidak di inginkan maka akan menimbulkan berbagai masalah. Backup paling sederhana adalah melakukan export sql tidak perlu melakukan replication server karena membutuhkan biaya yang murah (kasusnya untuk blog seperti degananda.com), melakukan replikasi hanya untuk kebutuhan enterprise.