matriphe! personal blog

Basis data adalah faktor penting dari sebuah aplikasi. Hampir semua aplikasi menyimpan datanya dalam basis data. MySQL merupakan basis data yang umum dan populer digunakan karena kemudahan pemakaian, kompatibel dengan beragam bahasa pemograman, dan sudah teruji kualitasnya.

Saya bukan seorang database administrator atau orang yang bekerja terus menerus dengan basis data, namun saya sering menggunakan MySQL untuk pekerjaan saya.

Saya menggunakan Percona Server XtraDB, sebuah varian MySQL yang telah dioptimasi, saat membangun Beritagar. Saya sendiri belum mendalami lebih lanjut keunggulan Percona dibandingkan MySQL, namun saya cukup percaya dengan fitur-fitur yang ditawarkan Percona.

Saya menggunakan Percona sejak Juli 2012, dibangun di atas layanan Amazon EC2. Kemudian pada Oktober 2012, saya melakukan replikasi untuk mengamankan data. Saya menggunakan sistem replikasi master-slave MySQL dengan menggunakan dua instance Amazon EC2 yang masing-masing dipasangi Percona.

Sistem berjalan cukup lancar, hingga suatu saat basis data utama (master) mengalami masalah pada instance-nya. Saya tidak menemukan penyebabnya dan satu-satunya cara untuk “mengatasi” masalah tersebut adalah mematikan instance-nya lalu menyalakan kembali (bukan restart).

Walhasil, basis data menjadi tidak sinkron. Kalau yang bermasalah adalah basis data replika (slave) tidak menjadi masalah karena basis data replika akan melakukan sinkronisasi secara otomatis. Namun jika yang bermasalah adalah basis data utama, ini membuat data menjadi tidak sinkron.

Saya mencoba melakukan sinkronisasi ulang. Dari berbagai cara yang saya dapatkan dari Google, saya memutuskan menggunakan Percona Toolkit. Saya menggunakan pt-table-checksum untuk memeriksa konsistensi dan pt-table-sync untuk melakukan sinkronisasi ulang.

Namun karena saya bukan seorang database administrator, saya kurang bisa menggunakan perintah-perintah tersebut. Saya mencoba dengan cara coba-coba, dan tetap tidak bisa melakukan sinkronisasi ulang, meski telah membaca dokumentasinya berulang kali.

Saya pun akhirnya memutuskan untuk menggunakan Amazon RDS. Pertimbangan kenapa tidak menggunakan layanan ini sejak awal adalah biaya. Layanan Amazon RDS bisa dibilang lebih mahal bila menggunakan layanan Amazon EC2 yang difungsikan sebagai basis data.

Berikut ini perbandingan harga dari kedua layanan. Spesifikasi instance relatif sama dan regional yang digunakan sama-sama berada di Singapura. Layanan Amazon EC2 menggunakan sistem operasi Linux sedangkan Amazon RDS menggunakan basis data MySQL. Harga dalam dolar Amerika dihitung per jam untuk layanan on-demand.

Harga tersebut belum termasuk biaya storage dan transfer data. Dari tabel di atas sudah terlihat Amazon RDS sedikit lebih mahal dibanding Amazon EC2. Untuk informasi lengkapnya tengok halaman di situs masing-masing layanan.

Namun bila dipertimbangkan ulang, kemudahan yang ditawarkan oleh Amazon RDS membuat harga yang mahal tersebut masuk akal. Apalagi memang Amazon RDS dirancang untuk basis data, sedangkan Amazon EC2 ibarat lahan kosong yang bisa difungsikan sesuai keinginan.

Beberapa keuntungan yang saya rasakan saat menggunakan Amazon RDS adalah:

1. Tidak membutuhkan perawatan. Apalagi bila tidak memiliki database administrator yang bertugas merawat, mengoptimasi, memantau, termasuk urusan update dan perbaikan software. Sebelumnya, saya harus melakukan sendiri proses instalasi, konfigurasi, optimasi, hingga menangani masalah ketika menggunakan Percona pada Amazon EC2.
2. Mudah melakukan pengaturan, mulai dari meningkatkan kapasitas storage, CPU, memori, hingga duplikasi read-replica melalui halaman AWS Management Console. Halaman ini pun sangat jarang saya sentuh, kecuali ketika membutuhkan modifikasi atau menambah instance.
3. Backup otomatis. Amazon RDS akan melakukan backup rutin pada waktu yang telah kita tentukan. Jika ingin menambah waktu backup, ada tambahan biaya lagi. Backup berupa snapshot (kondisi mesin) sehingga bisa dengan mudah di-restore jika terjadi masalah. Saat menggunakan Amazon EC2, saya membuat skrip untuk melakukan backup. Skrip melakukan dumping ke format SQL kemudian mengompresi dan menyimpan ke Amazon S3 yang dilakukan lewat cron. Kini saya tak perlu lagi melakukan proses ini.
4. Tersedia halaman monitoring. Meski tidak lengkap, namun untuk saya sudah cukup. Saya bisa mengetahui penggunaan CPU dan jumlah koneksi yang terjadi. Sayangnya, saya tidak bisa mengetahui penggunaan storage.

Dengan kemudahan-kemudahan tersebut, saya tidak perlu dipusingkan lagi dengan urusan basis data dan bisa fokus ke pengembangan aplikasi.

Namun ada beberapa limitasi bila menggunakan Amazon RDS. Beberapa di antaranya yang patut dicermati adalah:

1. Tidak ada akses langsung ke file konfigurasi. Jika pada MySQL biasa kita bisa melakukan konfigurasi spesifik melalui file my.cnf atau my.ini, Amazon RDS menggunakan API yang bisa diakses menggunakan Amazon RDS Command Line Tools.
2. Amazon RDS dibatasi oleh jumlah koneksi maksimal. Tidak ada cara lain untuk menaikkan jumlah koneksi maksimal kecuali menaikkan spesifikasi instance. Amazon sendiri tidak merilis angka pasti jumlah koneksi maksimal ini, namun melalui menurut blog ini (2011), koneksi maksimal masing-masing instance adalah sebagai berikut.
   

   Instance	Jumlah koneksi maksimal
   t1.micro	34
   m1.small	150
   m1.large	640
   m1.xlarge	1.263
   m2.xlarge	1.441
   m2.2xlarge	2.900
   m2.4xlarge	5.816

   Jadi sebelum menggunakan Amazon RDS, perlu mengetahui perkiraan jumlah koneksi ke basis data yang dilakukan oleh aplikasi. Cara lain untuk mengurangi koneksi ke basis data adalah dengan menggunakan cache, entah SQL cache atau memcached.