High Availability in PostgreSQL

High availability adalah sebuah fitur yang sangat dibutuhkan dalam dunia Enterprise, untuk menjaga ketersediaan layanan utama. High availability adalah sebuah metode, atau teknologi atau mekanisme yang dibuat dengan teknik tertentu agar ketersediaan layanan terjaga, meskipun ada gangguan. Untuk selanjutnya kita singkat dengan istilah HA.

Tidak ada satu orang maupun sistem yang mampu menjamin ketersediaan layanan fasiliatas yang terus menerus tanpa interupsi barang sedetikpun. Padahal dalam dunia Komputer tidak ada sistem komputer yang mampu bertahan tanpa pasokan listrik barang sedetikpun. Manusia masih patut banyak bersyukur, masih bisa hidup walau nafas terinterupsi satu menit. Terputusnya jalur listrik kurang dari sedetik akan mampu mematikan server, dan oleh karenanya menghentikan layanan dari server tersebut.

Tidak hanya listrik, ketersediaan pendingin udara mutlak diperlukan oleh sistem komputer perusahaan, karena CPU yang bekerja selalu dirancang pada suhu kamar, namun kondisi pekerjaan yang tinggi akan selalu membuat CPU bekerja diluar batas normal sehingga tentunya menghasilkan disipasi panas yang harus segera dibuang, agar tidak membuat overheat yang dapat menyebabkan CPU terhenti (halted).

Begitupula komponen-komponen elektronika yang dipergunakan didalam sistem komputer tersebut seperti Power Supply, Voltage regulator, jalur bus komunikasi, chip, dan lain-lainnya kesemuanya memiliki kesempatan untuk short circuit, atau overheater yang dapat menyebabkan hardware failure.

HA melakukan mitigasi terhadap permasalahan yang sebabkan faktor luar diluar aplikasi atau proses bisnis yang ada didalam aplikasi tersebut. HA memitigasi perangkat keras, dan (bisa jadi) fasiliatas yang disediakan. Secara umum, HA diimplementasi dengan menggunakan redudancy hardware. namun beda denagn Hot Stanby ataupun Cold Standby, atau juga Warm Standby, HA memiliki karakteristik yang lebih baik daripada Hot Standby, yaitu mampu melakukan proses failover secara otomatis sehingga downtime sangat minimal. Jadi HA memiliki satu level lebih tinggi daripada Hot Standby.

Ada engineer yang mengimplementasikan Hot Standby dengan mode Active-Passive, ada yang menggunakan mode Active-Active (oleh karenanya disebut load balance) ada yang menggunakan Cluster Server lebih dari 2, dimana satu active dan lainnya adalah passive. ada beberapa pendekatan, tata cara dan metodologi. Namun secara umum, sesuai dengan definisinya HA adalah suatu teknologi yang bertujuan untuk meningkatkan layanan dengan cara memitigasi downtime yang disebabkan oleh sebab diluar aplikasi, dengan cara menghindarkan SPOF (Single Point Of Failure).

HA pada dasarnya automatic fail-over in redundant system. namun ada orang yang salah menerjemahkan redundant system itu artinya harus active-active. sebab untuk aplikasi memang tidak ada masalah untuk active-active. Hal yang berbeda jauh dengan databaase yang membutuhkan harga yang mahal untuk mencapai active-active tersebut.

Aplikasi dapat disetup Active-Active dengan mudah karena aplikasi tidak berurusan dengan proses update data yang sangat dinamis. Sedangkan Database RDBMS setiap saat harus memaintain data yang sangat cepat berubah dan oleh karenanya harus selalu saling update antara satu database dengan yang lainnya, dan kalau pun ingin dibuat Active-Active maka dibutuhkan sinkronisasi data 2-arah yang dapat memperlambat kinerja dengan cukup significant.

Jadi untuk implementasi HA pada RDBMS, langkah terbaik adalah menggunakan Active-Passive dimana replikasi data antara Master dengan Replika berjalan secara satu arah, bisa sinkronous atau asinkronous. Pendekatan ini yang paling umum dipergunakan pada sistem Aplikasi maupun database dengan menggunakan Pacemaker/Corosync.

Hal kedua yang menjadi perhatian adalah, berapa server database yang harus dideploy agar kita dapat membangun HA dengan baik? pilihannya jelas bukan 1, apakah 2 cukup apakah harus minimal 3?

Pada satu pendekatan, mengembangkan HA bisa dilakukan dengan mekanisme Quorum, dimana terdapat 3 atau lebih server yang bekerja, dengan 1 Master dan 2 Replika. Bilamnaa ada permasalahan yang terjadi dengan Master, maka salah satu diantara kedua Replika akan mengambil alih menjadi Master. Sistem ini dikembangkan dalam Aplikasi yagn disebut dengan Patroni.

Maka yang paling baik? Penilaian mungkin bisa dilakukan secara objective ataupun subjective berdasarkan kasus-kasus yang ada. Pacemaker cukup efisien dan hanya membutuhkan 2 server saja, ada 1 ato 2 kasus khusus yang mungkin menjadi downside dari Pacemaker. Patroni membutuhkan lebih banyak server, minimal 3, dan failover tentunya tidak akan secepat Pacemaker.

Tidak ada simpulan akhir untuk hal ini, kesemua pendekatan teknologi memiliki keunggulan maupun kelemahannya masing-masing.