Halaman ini menjelaskan ketersediaan tinggi dan alat yang kami rekomendasikan untuk digunakan.
Tentang ketahanan data
Anda dapat memikirkan ketahanan data dalam hal ketersediaan, waktu untuk memulihkan layanan, dan kehilangan data. Ketersediaan biasanya diukur dalam hal waktu beroperasi dan dinyatakan sebagai persentase waktu database tersedia. Misalnya, untuk mencapai ketersediaan 99,99%, database Anda tidak boleh nonaktif selama lebih dari 52,6 menit per tahun, atau 4,38 menit per bulan. Waktu untuk memulihkan layanan setelah pemadaman disebut Batas Waktu Pemulihan, atau RTO. Jumlah kehilangan data yang dapat diterima akibat gangguan disebut Toleransi Jumlah Data yang Hilang, atau RPO, dan dinyatakan sebagai jumlah waktu hilangnya transaksi. Misalnya, RPO 10 menit berarti jika terjadi kegagalan, Anda dapat kehilangan data hingga 10 menit.
Target ketersediaan, atau Tujuan Tingkat Layanan (SLO), biasanya ditetapkan bersama dengan target untuk RTO dan RPO. Misalnya, untuk workload tertentu, Anda dapat menetapkan SLO ke 99,99%, dan juga memerlukan RPO 0, tidak ada kehilangan data pada kegagalan apa pun, dan RTO 30 detik. Untuk beban kerja lain, Anda dapat menetapkan SLO ke 99,9%, RPO ke 5 menit, dan RTO ke 10 menit.
Anda dapat menerapkan ketahanan database dasar dengan cadangan database. AlloyDB Omni mendukung pencadangan menggunakan pgBackRest dan juga mengarsipkan file Write Ahead Log (WAL) database untuk meminimalkan kehilangan data. Dengan pendekatan ini, jika database utama Anda tidak berfungsi, database tersebut dapat dipulihkan dari cadangan dengan RPO beberapa menit, dan RTO beberapa menit hingga jam, bergantung pada ukuran database.
Untuk persyaratan RPO dan RTO yang lebih ketat, Anda dapat menyiapkan AlloyDB Omni dalam konfigurasi ketersediaan tinggi menggunakan Patroni. Dalam arsitektur ini, ada satu database utama dan dua database standby, atau replika. Anda dapat mengonfigurasi AlloyDB Omni untuk menggunakan replikasi streaming PostgreSQL standar guna memastikan setiap transaksi yang dilakukan di database utama direplikasi secara sinkron ke kedua database standby. Hal ini memberikan RPO nol, dan RTO kurang dari enam puluh detik untuk sebagian besar skenario kegagalan.
Bergantung pada konfigurasi cluster Anda, replikasi sinkron dapat memengaruhi waktu respons untuk transaksi, dan Anda dapat memilih untuk mengambil risiko kehilangan data dalam jumlah kecil. Misalnya, Anda dapat memiliki RPO bukan nol sebagai ganti latensi transaksional yang lebih rendah dengan menerapkan ketersediaan tinggi dengan replikasi asinkron, bukan sinkron. Karena potensi dampak replikasi sinkron terhadap latensi transaksi, arsitektur ketersediaan tinggi hampir selalu diterapkan dalam satu pusat data, atau di antara pusat data yang berdekatan (berjarak puluhan km/berjarak <10 milidetik latensi). Namun, perhatikan bahwa dokumentasi ini menggunakan replikasi sinkron sebagai default.
Untuk pemulihan dari bencana, yang merupakan perlindungan terhadap hilangnya pusat data atau region tempat beberapa pusat data berdekatan, AlloyDB Omni dapat dikonfigurasi dengan replikasi streaming asinkron dari region utama ke region sekunder, yang biasanya berjarak ratusan atau ribuan km, atau berjarak 10-100 milidetik. Dalam konfigurasi ini, region utama dikonfigurasi dengan replikasi streaming sinkron antara database utama dan standby dalam region, dan replikasi streaming asinkron dikonfigurasi dari region utama ke satu atau beberapa region sekunder. AlloyDB Omni dapat dikonfigurasi di region sekunder dengan beberapa instance database untuk memastikan bahwa AlloyDB Omni dilindungi segera setelah failover dari region utama.
Cara kerja ketersediaan tinggi
Teknik dan alat khusus yang digunakan untuk menerapkan ketersediaan tinggi bagi database dapat bervariasi, bergantung pada sistem pengelolaan database. Berikut beberapa teknik dan alat yang biasanya digunakan dalam menerapkan ketersediaan tinggi untuk database, yang dapat bervariasi bergantung pada sistem pengelolaan database:
Redundansi: Mereplikasi database Anda di beberapa server atau region geografis memberikan opsi failover jika instance utama tidak berfungsi.
Pengalihan Otomatis: Mekanisme untuk mendeteksi kegagalan dan beralih dengan lancar ke replika yang berfungsi baik, sehingga meminimalkan periode nonaktif. Kueri dirutekan sehingga permintaan aplikasi mencapai node utama yang baru.
Kelangsungan Data: Pengamanan diterapkan untuk melindungi integritas data selama terjadi kegagalan. Hal ini mencakup teknik replikasi dan pemeriksaan konsistensi data.
Pengelompokan: Pengelompokan melibatkan pengelompokan beberapa server database untuk bekerja bersama sebagai satu sistem. Dengan cara ini, semua node dalam cluster akan aktif dan menangani permintaan yang menyediakan load balancing dan redundansi.
Fallback: Metode untuk kembali ke arsitektur asli menggunakan pre-failover utama dan node replika pada kapasitas aslinya.
Load Balancing: Mendistribusikan permintaan database ke beberapa instance meningkatkan performa dan menangani peningkatan traffic.
Pemantauan dan Pemberitahuan: Alat pemantauan mendeteksi masalah seperti kegagalan server, latensi tinggi, kehabisan resource, dan memicu pemberitahuan, atau prosedur failover otomatis.
Pencadangan dan Pemulihan: Cadangan dapat digunakan untuk memulihkan database ke status sebelumnya jika terjadi kerusakan data atau kegagalan yang parah.
Penggabungan koneksi (opsional): Mengoptimalkan performa dan skalabilitas aplikasi yang berinteraksi dengan database Anda.
Alat ketersediaan tinggi
Patroni adalah alat pengelolaan cluster open source untuk database PostgreSQL yang dirancang untuk mengelola dan mengotomatiskan ketersediaan tinggi untuk cluster PostgreSQL. Patroni menggunakan berbagai sistem konsensus terdistribusi seperti etcd, Consul, atau Zookeeper untuk mengoordinasikan dan mengelola status cluster. Beberapa fitur dan komponen utama Patroni mencakup ketersediaan tinggi dengan failover otomatis, pemilihan pemimpin, replikasi, dan pemulihan. Patroni berjalan bersama layanan PostgreSQL di instance server database, mengelola kesehatan, failover, dan replikasinya untuk memastikan ketersediaan dan keandalan yang tinggi.
Patroni menggunakan sistem konsensus terdistribusi untuk menyimpan metadata dan mengelola cluster. Dalam panduan ini, kita akan menggunakan Distributed Configuration Store (DCS) yang disebut etcd. Salah satu penggunaan etcd adalah untuk menyimpan dan mengambil informasi sistem terdistribusi seperti konfigurasi, kesehatan, dan status saat ini, sehingga memastikan konfigurasi yang konsisten di semua node.
High Availability Proxy (HAProxy) adalah software open source yang digunakan untuk menyeimbangkan beban dan memproksi aplikasi berbasis TCP dan HTTP, yang digunakan untuk meningkatkan performa dan keandalan aplikasi web dengan mendistribusikan permintaan yang masuk ke beberapa server. HAProxy menawarkan load balancing dengan mendistribusikan traffic jaringan di beberapa server. HAProxy juga mempertahankan status health server backend yang terhubung dengannya dengan melakukan health check. Jika server gagal dalam health check, HAProxy akan berhenti mengirim traffic ke server tersebut hingga server lulus health check lagi.
Pertimbangan replikasi sinkron dan asinkron
Dalam cluster PostgreSQL yang dikelola Patroni, replikasi dapat dikonfigurasi dalam mode sinkron dan asinkron. Secara default, Patroni menggunakan replikasi streaming asinkron. Untuk persyaratan RPO yang ketat, sebaiknya gunakan replikasi sinkron.
Replikasi sinkron di PostgreSQL memastikan konsistensi data dengan menunggu transaksi ditulis ke database utama dan setidaknya satu database standby sinkron sebelum melakukan commit. Replikasi sinkron memastikan bahwa data tidak hilang jika terjadi kegagalan primer, sehingga memberikan ketahanan dan konsistensi data yang kuat. Primer menunggu konfirmasi dari standby sinkron, yang dapat menyebabkan latensi lebih tinggi dan throughput yang berpotensi lebih rendah karena waktu perjalanan pulang pergi tambahan. Hal ini dapat mengurangi throughput sistem secara keseluruhan, terutama saat beban tinggi.
Replikasi asinkron memungkinkan transaksi di-commit di cluster utama tanpa menunggu konfirmasi dari cluster standby. Replika utama mengirimkan data WAL ke replika standby, yang menerapkannya secara asinkron. Pendekatan asinkron ini mengurangi latensi penulisan dan meningkatkan performa, tetapi disertai risiko kehilangan data jika server utama gagal sebelum server standby menyusul. Siaga mungkin tertinggal dari primer, sehingga menyebabkan potensi inkonsistensi selama failover.
Pilihan antara replikasi sinkron dan asinkron dalam cluster Patroni bergantung pada persyaratan spesifik untuk daya tahan, konsistensi, dan performa data. Replikasi sinkron lebih disukai dalam skenario ketika integritas data dan kehilangan data minimal sangat penting, sedangkan replikasi asinkron cocok untuk lingkungan yang memprioritaskan performa dan latensi yang lebih rendah. Anda dapat mengonfigurasi solusi campuran yang melibatkan cluster tiga node dengan standby sinkron di region yang sama, tetapi zona atau pusat data terdekat yang berbeda, dan standby asinkron kedua di region yang berbeda atau pusat data yang lebih jauh untuk melindungi dari potensi pemadaman layanan regional.