Galau CubieTruck, Banana Pi atau NUC

Tempo hari saya teringat Raspberry Pi yang telah teronggok beberapa lama. Mau diapakan ya? Lantas saya sibuk mengurus start-up yang baru saya rintis. Di sela-sela kesibukan terbersit ide untuk bikin PC backup atau replicator dengan Raspberry Pi. Namun saya ingat kalau Raspberry Pi milik saya ini cuma punya RAM 256MB. Apa bisa diinstall MySQL?

Kepikiran pula untuk merakit PC sendiri. Tapi kayaknya tidak mudah. Baru mau menentukan komponen saja sudah bikin puyeng. Sempat pula melirik NUC milik Intel. Keren juga sih, sayangnya tidak murah. Yang termurah dengan prosesor Intel Celeron saja sudah lebih nyaris 3 juta. Kayaknya terlalu mahal untuk budget startup. Kan belum punya penghasilan, jadi harus hemat.

Lantas googling alternatif lain nemu Banana Pi dan Cubietruck. Konon Banana Pi merupakan tiruan dari Raspberry Pi namun punya spesifikasi lebih baik. Selain menggunakan prosesor dual core, Banana Pi sudah dibekali RAM 1 GB. Keren to?

Namun rupanya CubieTruck lebih mumpuni. Sama-sama sudah dual core, Cubietruck punya RAM onboard 2 GB. Ditambah port SATA sehingga Cubietruck bisa dihubungkan ke harddisk. Jangan lupa dicatat, Cubietruck sudah punya koneksi WiFi+BT di samping ethernet Gigabit-nya. Mantab ya?

Nampaknya Banana Pi atau Cubieboard bisa digunakan untuk tujuan saya, yaitu membuat PC Backup atau DB Replicator dengan pemakaian daya yang rendah dan bisa ditenteng. Beberapa video di Youtube malah menampilkan penggunaan board-board ini sebagai server.


{Gambar dipinjam dari sini}

Namun kemudian saya tersadar kalau saya belum menyelesaikan pekerjaan, tapi pikiran sudah melayang kemana-mana. Hampir saja saya order Cubietruck, tapi saya urungkan. Lebih baik saya menyelesaikan pekerjaan dulu, barulah nanti dilanjut galaunya kalau sudah selesai kerja. Hiks…

~~~

Bacaan:
Spesifikasi Cubietruck
Spesifikasi Banana Pi

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.

Baca selebihnya »