Berakit-rakit ke hulu berenang ke tepian, bukan ini maksud saya. Yang paling tepat sepertinya adalah “Sedikit demi sedikit lama-lama tak terungkit dan semakin menjangkit“. Ungkapan baru, yang tepat untuk artikel saya kali ini.
Salam bahagia untuk pembaca semua, tanpa terasa sudah 2 kali lebaran (Idul Fitri dan Idul Adha), blog ini tanpa ada kabar karena saya sendiri pun tidak tahu apa penyebabnya. Boleh jadi karena terlalu suntuk untuk berbagi, atau bahkan sudah terlalu lama ngoding sendiri. Sudahlah lupakan.
Behind the Disaster
Langsung saja, saya akan meloncat ke pembahasan dan dua paragraf diatas silahkan pembaca lupakan. MySQL, & yes MySQL! Hampir 2 tahun saya tidak menyentuh database legendaris ini. Hingga pada akhirnya saya harus berurusan dengan database yang memiliki cloning bernama Maria DB ini, berkaitan dengan blog yang pembaca kunjungi saat ini.
Saya akan memulainya dengan kisi-kisi requirement blog ini, berjiwa WordPress dan berkantung MySQL. Meskipun sudah tidak saya rumahkan di hosting, dan sudah tidur manis di dalam Cloud Server, ternyata masih ada juga masalah yang harus saya hadapi seiring dengan semakin beranak pinaknya data yang berada dalam server. Entah dari test project yang saya miliki dan juga dari blog ini.
Tidak ada masalah dengan konfigurasi server, hingga pada suatu ketika, notifikasi “Disk” yang kurang menyenangkan terjadi. 99% kapasitas penyimpanan dalam server telah terpakai. Masalah mulai muncul ketika beberapa database MySQL tidak dapat diakses, bahkan hingga artikel ini saya tulis. Masalah lain adalah saya pun tidak dapat masuk ke dalam dashboard WordPress. It so crazy !
Dalam hati harus merelakan, diluar hati tak mengenakkan. Kemudian tanpa disadari, sewaktu ingin melakukan restart mysql service, problem lain pun menghinggapi. Yes, “Mysql Server Failed To Start“. Setidaknya ada 2 baris kalimat ini yang menjadi penyakit didalam log server MySQL saya :
InnoDB: Error: log file ./ib_logfile0 is of different size 0 xxxxxxxx bytes InnoDB: than specified in the .cnf file 0 xxxxxxxx bytes! [ERROR] Plugin 'InnoDB' init function returned error. [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
Sebelum melangkah lebih jauh, alangkah manisnya kita mencari penjelasan dulu beberapa pengertian merujuk dari puisi error diatas. Kita mulai dari InnoDB. Jika kita ibaratkan MySQL adalah pabrik, maka InnoDB adalah mesin (engine) yang menggerakkan pabriknya. Karena MySQL adalah storage dan InnoDB adalah Engine, maka kita sebut saja InnoDB sebagai Storage Engine di MySQL. InnoDB cukup populer, dan banyak dipakai dibanding dengan mesin MySQL lain bernama MyISAM.
Terlepas dari perbedaan mekanisme yang dipakai antara InnoDB dan MyISAM, kedua engine ini sama-sama dikelola oleh satu vendor bernama Oracle. Berbicara mengenai vendor, sebenarnya ada satu vendor lagi yang sudah saya sebutkan diatas dimana saat ini juga cukup populer, vendor ini bernama MariaDB, dengan engine-nya yang bernama Aria.
Singkat sejarah yang bisa saya petik, suatu ketika MySQL diakusisi sepenuhnya oleh Oracle, meskipun setelah diakuisisi oleh Oracle dan masih berlisensi GPL, beberapa developer MySQL melakukan ‘forking’ terhadap MySQL dan kemudian diberi nama dengan MariaDB dengan tujuan utama memberikan keleluasaan lebih dibanding MySQL versinya Oracle. MySQL dan MariaDB adalah sama namun tak serupa.
Cukup untuk sejarahnya, saya akan kembali lagi ke 4 baris error di atas. ib_logfile0, apakah ini sebenarnya? ib_logfile adalah sebuah file log untuk MySQL. Jika pembaca menggunakan MySQL pada sistem operasi Linux, coba mampirlah kedalam direktori /var/lib/mysql (harus dengan permission user root), pembaca akan melihat beberapa file yang diantaranya:
- ibdata1,
- ib_logfile0 dan
- ib_logfile1.
Saya akan mencoba menjelaskan ketiga file tersebut (sebenarnya dua, karena ib_logfile0 dan ib_logfile1 itu identik). Kenapa tiga file tersebut, karena mereka adalah ‘bersaudara’.
Ketiga file-file tersebut umumnya memiliki ukuran yang cukup besar dibanding file lain di dalam direktori /var/lib/mysql. Karena, mereka bertiga memiliki peranan penting di dalam infrastruktur sistem yang bekerja pada MySQL.
ibdata1
ibdata1 merupakan rumah bagi informasi seluruh tabel dalam sebuah database, ketika pembaca melakukan ‘create database‘ beserta tabel-tabelnya, informasi seluruh tabel akan disimpan di dalam ibdata1, bahasa kerennya adalah ‘data dictionary’. Selain itu, ibdata1 juga menyimpan segments rollback dan juga undo space, keduanya memiliki fungsi untuk mengembalikan database jika terjadi permasalahan pada keadaan yang telah tersimpan sebelumnya di dalam ibdata1 itu sendiri.
ibdata1 juga dipakai sebagai penyangga database saat melakukan penulisan data, inilah yang disebut sebagai doublewrite buffer dan insert buffer yang ada pada ibdata1.
ib_logfile0 & 1
Sedangkan ib_logfile0 dan ib_logfile1 berfungsi merekam kegiatan penulisan di dalam MySQL yang tidak akan terekam oleh doublewrite buffer pada ibdata1. Oleh karena itu, ib_logfile0 dan ib_logfile1 adalah file yang menjadi kunci saat kita ingin melakukan redo pada database, namun tidak direkam oleh buffer ibdata1.
ib_logfile difungsikan oleh InnoDB untuk menyimpang kegiatan-kegiatan untuk me-redo database.
Problem Solved(ing)
Semakin tingginya penulisan dan penghapusan pada MySQL, semakin berkembang pula ukuran ketiga file tersebut. Seiring penggunaan harddisk yang juga tidak pernah berkurang namun bertambah, alokasi untuk log MySQL pun semakin berkurang untuk ketiga file tersebut dan log-log sistem yang lain selain MySQL. Jika tidak segera dilakukan scaling, bukan tidak mungkin sistem akan pincang, diakhiri dengan matisuri-nya si MySQL. Inilah yang menjadi poin utama permasalahan yang saya hadapi, rumah kecil berisi orang-orang gendut.
Jika dilihat permasalahan, kita berfikir cukup melakukan pelebaran area disk, maka permasalahan sepertinya akan selesai. Namun tidak sesederhana itu ternyata. Meskipun cloud server atau virtual server memiliki fitur scaling disk tanpa perlu repot, kita pun sebelumnya harus menggemboskan file-file tersebut sebelum melakukan penambahan ukuran penyimpanan server.
Karena berbentuk file, solusi yang saya dapatkan dari berbagai sumber adalah dengan :
- Backup ketiga file yakni ibdata1, ib_logfile0 dan ib_logfile1
- Mematikan seluruh proses MySQL. (Umumnya jika terjadi masalah, MySQL sudah tidak berjalan)
- menghapus ib_logfile0 dan ib_logfile1
- Dilanjut dengan sedikit melakukan konfigurasi pada my.cnf (terletak di /etc/mysql/) dengan menghilangkan komentar pada baris ‘record_buffer‘.
Alhasil, MySQL kembali berjalan dengan perintah ‘service mysql start‘ atau ‘/etc/init.d/mysqld start‘. Lantas selamat lah blog ini, meskipun begitu beberapa database di server masih terjadi problema.