Semalam Bersama Raspberry Pi

Ini masih cerita saya bersama Raspberry Pi yang telah lama teronggok di laci. Setelah berhasil menyalakan lagi, saya pun memberdayakannya untuk hal yang lebih bermanfaat, lebih dari sekedar “mainan”. Pertama yang saya lakukan adalah menginstall samba server sehingga bisa dijadikan file sharing. Sayangnya dengan koneksi WiFi kecepatan file sharing termasuk lambat, cuma bisa 1-1.2 Mbps. Secara teknis kalah cepat sama koneksi internetnya, hehehe…

Hal yang kedua adalah menjadikannya mesin backup MySQL otomatis. Saya menggunakan Automysqlbackup dan telah berhasil melakukan backup server KUNET di cloud. Kemudian saya jadwalkan untuk otomatis backup jam 12.00. Kok tidak dijadwalkan tengah malam saja? Soalnya backup tengah malam sudah dilakukan server KUNET sendiri, hehehe…

Sebenarnya solusi backup remote dengan automysqlbackup tidaklah terlalu baik jika ukuran database sudah besar. Soalnya bisa makan resources server dan juga memenuhi bandwidth jaringan. Bisa parah jika koneksi yang dipakai ada kuotanya. Lagi pula backup model begini cuma menyimpan data pada posisi waktu tertentu.

Yang lebih efisien mungkin mensetupnya sebagai replikasi database. Tapi saya masih ragu, apakah Raspberry Pi mampu? Mengingat Raspberry Pi saya ini generasi 1 yang hanya punya RAM 256 MB. Sudah gitu, berdasarkan pengalaman beberapa kali saya konfigurasi replikasi MySQL seringnya macet sendiri tanpa diketahui penyebabnya.

Tapi apa salahnya dicoba ya? Baiklah, nanti kalau ada kesempatan akan saya coba jadikan RPi ini mesin replikasi.

Iklan

Tech Talk: Optimasi dan Tuning Server

Sekali-kali ngomongin pekerjaan ya? Biar blog ini lebih nampak serius (*hayah*). Maka perkenankanlah saya menulis tech talk. Oh iya, tulisan ini juga dimuat di studewo.com.

Salah satu masalah yang kami hadapi saat ini adalah semakin melambatnya sistem, terutama di saat beban puncak di jam-jam tertentu. Sebenarnya kami sudah memiliki server yang cukup powerful, namun ternyata itu saja tidak cukup. Lalu kami pun berdiskusi dengan salah seorang konsultan sistem. Setelah berdiskusi dengan beliau, kami pun menganalisa sistem bersama tim.

Optimasi server

Kita perlu mengoptimasi peletakan beberapa folder sistem di partisi terpisah. Itu pun perlu diurutkan dengan mempertimbangkan harddisk mekanis yang memiliki kecepatan tertinggi dengan metode sequential. Partisi yang perlu dibuat dengan urutan: system, home, DB (khusus), var, swap.

Tentu hal ini tidak berlaku jika menggunakan SSD, karena SSD tidak memiliki komponen mekanis. Lebih lanjut, berdasarkan pengalaman, perlu ditentukan penggunaan RAID yang paling cepat dan aman. Tempo hari kami berhasil mengkonfigurasikan RAID50 yang kecepatannya 2x konfigurasi RAID5 biasa.

Mulai Belajar Cluster MySQL

Saat ini kami sedang memulai belajar membuat cluster MySQL. Kami membuat cluster ini karena ingin meningkatkan kinerja database sekaligus meningkatkan reliabilitas-nya. Tadinya mau experimen di Pekanbaru, tapi karena terkendala waktu saat saya berkunjung ke sana, maka experimen dilakukan di Bekasi. Jika berhasil baik, maka model cluster MySQL ini akan diterapkan di semua RS.

Kami pun menyiapkan 4 buah PC untuk experimen. 4 PC ini hanya ditenagai prosesor Atom dengan RAM 2 GB dan hanya menggunakan USB sebagai media penyimpanannya. Jika dapat berjalan baik, maka kami akan menggunakan 4 buah PC dengan spesifikasi yang lebih tinggi.

Berikut ini beberapa link penting:
~ MySQL Cluster NDB 7.2
~ Download MySQL CLuster
~ MySQL Cluster Quick Start for Linux
~ MySQL Cluster and Ubuntu 12.04

Ada yang pernah punya pengalaman menggunakan cluster MySQL dengan konfigurasi standard?

Database Replication

Backup database itu penting. Tetapi membuat file backup database saja tidak cukup. Walau pun backup dibuat secara otomatis di suatu periode waktu tertentu yang mungkin dilakukan beberapa kali dalam sehari, itu tetap tidak cukup.

Mengapa tidak cukup? Karena backup hanya membuat copy atas database pada posisi tertentu. Katakanlah backup dibuat pada jam 00:00, sebenarnya data yang tersimpan hanya sampai jam 00:00. Seandainya terjadi kerusakan data pada jam 11:00, maka semua transaksi yang dilakukan antara jam 00:00 sampai jam 11:00 akan hilang. Terpaksa user harus memasukkan ulang transaksi antara jam 00:00 sampai jam 11:00 setelah backup di-restore. Bayangkan jika transaksi yang terjadi sangat banyak atau jika transaksi tidak memiliki bukti fisik seperti struk/nota transaksi. Memasukkan ulang transaksi bisa membuat user frustasi. Apalagi jika transaksi ini harus dilakukan urut lantaran sifat transaksinya panjang untuk 1 account sesuai dengan alur bisnis perusahaan. Jika ada transaksi yang tidak ter-input, maka perusahaan atau pelanggan bisa rugi.

Untuk itu perlu dibuat replikasi database. Topologinya adalah ada 1 master server dan minimal 1 slave server. Setiap kali master server melakukan transaksi, maka slave server akan melakukan transaksi yang sama. Jadi posisi database slave akan sama dengan master. Tentu ada delay beberapa waktu. Tetapi delay ini tidak terlalu membahayakan karena relatif cepat. Kalau pun slave mati, dia akan kembali melakukan sinkronisasi ke master pada posisi terakhir dia sinkronisasi. Slave akan mengejar transaksi master sehingga posisinya akan mendekati posisi transaksi di master.

Unique Key yang Tidak Unique

Ini adalah salah satu tantangan kami secara teknis berkaitan dengan database. Suatu saat kami mencatatkan header transaksi dengan autogenerated number yang merupakan fitur natif dari database. Field bertipe big integer ini menjadi Primary Key untuk relasi ke tabel detail atau tabel lain yang berelasi. Semua baik-baik saja.

Keadaan berubah saat ada beberapa divisi memerlukan penomeran yang lebih mudah dibaca (readable). Beberapa divisi ini menginginkan penggunaan prefix untuk membedakan dengan transaksi dari divisi lain. Misalnya divisi penjualan umum menggunakan prefix “FU”, penjualan rawat inap dengan prefix “FI” dan penjualan rawat jalan dengan “FJ”. Ditambahkan lagi prefix berdasarkan waktu transaksi sehingga formatnya menjadi “FJ1208xxxxx” untuk penjualan rawat jalan.

Dengan penomeran model begini user bisa dengan cepat mengidentifikasi transaksi tersebut dari divisi mana dan terjadi pada tahun dan bulan berapa.

Beberapa divisi lain juga menginginkan hal yang sama, misalnya divisi Laboratorium dan Radiologi. Sedangkan divisi lain tidak memerlukan fitur penomeran readable ini. Jadi divisi lain tetap menggunakan Primary Key. Sedangkan beberapa divisi menggunakan TrxID.