Halaman ini menjelaskan ketersediaan tinggi dan alat yang kami sarankan untuk digunakan. Alat ini juga mendukung penyiapan HA untuk cluster yang mengaktifkan Enkripsi data transparan (TDE).
Tentang ketahanan data
Anda dapat menganggap ketahanan data dalam hal ketersediaan, waktu untuk memulihkan layanan, dan kehilangan data. Ketersediaan biasanya diukur dalam hal waktu aktif 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 gangguan disebut Batas Waktu Pemulihan, atau RTO. Jumlah kehilangan data yang dapat diterima karena gangguan disebut Toleransi Jumlah Data yang Hilang, atau RPO, dan dinyatakan sebagai jumlah waktu transaksi hilang. Misalnya, RPO 10 menit berarti bahwa jika terjadi kegagalan, Anda dapat kehilangan data hingga 10 menit.
Biasanya, target ketersediaan, atau Tujuan Tingkat Layanan (SLO), 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 workload lain, Anda dapat menetapkan SLO ke 99,9%, RPO ke 5 menit, dan RTO ke 10 menit.
Anda dapat menerapkan ketahanan database dasar dengan pencadangan database. AlloyDB Omni mendukung pencadangan menggunakan pgBackRest dan juga mengarsipkan file Log Write Ahead (WAL) database untuk meminimalkan kehilangan data. Dengan pendekatan ini, jika database utama Anda nonaktif, 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 database utama dan dua database standby, atau replika. Anda dapat mengonfigurasi AlloyDB Omni untuk menggunakan replikasi streaming PostgreSQL standar guna memastikan setiap transaksi yang di-commit 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, 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 pada latensi transaksi, arsitektur ketersediaan tinggi hampir selalu diterapkan dalam satu pusat data, atau antara pusat data yang berdekatan (berjarak puluhan km / latensi <10 milidetik). Namun, perhatikan bahwa dokumentasi ini menggunakan replikasi sinkron sebagai default.
Untuk pemulihan dari bencana, yang merupakan perlindungan terhadap kehilangan pusat data atau region yang memiliki beberapa pusat data yang berdekatan, AlloyDB Omni dapat dikonfigurasi dengan replikasi streaming asinkron dari region utama ke region sekunder, 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 database tersebut dilindungi segera setelah failover dari region utama.
Cara kerja ketersediaan tinggi
Teknik dan alat tertentu yang digunakan untuk menerapkan ketersediaan tinggi untuk database dapat bervariasi bergantung pada sistem pengelolaan database. Berikut adalah 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 nonaktif.
Failover Otomatis: Mekanisme untuk mendeteksi kegagalan dan beralih dengan lancar ke replika yang responsif, sehingga meminimalkan waktu nonaktif. Kueri dirutekan sehingga permintaan aplikasi mencapai node utama yang baru.
Kontinuitas Data: Pengamanan diterapkan untuk melindungi integritas data selama kegagalan. Hal ini mencakup teknik replikasi dan pemeriksaan konsistensi data.
Pengelompokan: Pengelompokan melibatkan pengelompokan beberapa server database untuk bekerja sama sebagai satu sistem. Dengan cara ini, semua node dalam cluster aktif dan menangani permintaan yang menyediakan load balancing dan redundansi.
Fallback: Metode untuk kembali ke arsitektur asli menggunakan node utama dan replika pra-failover pada kapasitas aslinya.
Load Balancing: Mendistribusikan permintaan database di 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.
Connection pooling (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 tinggi dan keandalan.
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 load balancing dan proxy aplikasi berbasis TCP dan HTTP, yang digunakan untuk meningkatkan performa dan keandalan aplikasi web dengan mendistribusikan permintaan masuk di beberapa server. HAProxy menawarkan load balancing dengan mendistribusikan traffic jaringan di beberapa server. HAProxy juga mempertahankan status kesehatan 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 tersebut 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 di-commit. Replikasi sinkron memastikan data tidak hilang jika terjadi kegagalan utama, sehingga memberikan ketahanan dan konsistensi data yang kuat. Database utama menunggu konfirmasi dari database standby sinkron, yang dapat menyebabkan latensi yang lebih tinggi dan berpotensi menurunkan throughput karena waktu pulang pergi yang ditambahkan. 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. Database utama mengirimkan catatan WAL ke database standby, yang menerapkannya secara asinkron. Pendekatan asinkron ini mengurangi latensi tulis dan meningkatkan performa, tetapi disertai risiko kehilangan data jika database utama gagal sebelum database standby berhasil. Database standby mungkin berada di belakang database utama, sehingga menyebabkan potensi inkonsistensi selama failover.
Pilihan antara replikasi sinkron dan asinkron dalam cluster Patroni bergantung pada persyaratan spesifik untuk ketahanan, 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 database standby sinkron di region yang sama, tetapi zona atau pusat data terdekat yang berbeda, dan database standby asinkron kedua di region yang berbeda atau pusat data yang lebih jauh untuk melindungi dari potensi gangguan regional.