Halaman ini menjelaskan ketersediaan tinggi dan alat yang sebaiknya digunakan.
Tentang ketahanan data
Anda dapat menganggap 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 mengalami pemadaman layanan selama lebih dari 52,6 menit per tahun, atau 4,38 menit per bulan. Waktu untuk memulihkan layanan setelah penghentian layanan disebut Batas Waktu Pemulihan, atau RTO. Jumlah kehilangan data yang dapat diterima akibat pemadaman layanan disebut Toleransi Jumlah Data yang Hilang, atau RPO, dan dinyatakan sebagai jumlah waktu yang hilang untuk transaksi. Misalnya, RPO 10 menit berarti 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 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 pencadangan 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 beberapa 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 untuk 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 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 yang bukan nol dengan mengorbankan latensi transaksional yang lebih rendah dengan menerapkan ketersediaan tinggi dengan replikasi asinkron, bukan sinkron. Karena potensi dampak replika sinkron terhadap latensi transaksi, arsitektur ketersediaan tinggi hampir selalu diterapkan dalam satu pusat data, atau di antara pusat data yang berdekatan (jarak puluhan km/latensi <10 milidetik). Namun, perhatikan bahwa dokumentasi ini menggunakan replikasi sinkron sebagai default.
Untuk disaster recovery, yaitu perlindungan terhadap hilangnya pusat data atau region tempat terdapat 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 hingga 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 langsung dilindungi setelah terjadi 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 terlibat dalam menerapkan ketersediaan tinggi untuk database, yang dapat bervariasi bergantung pada sistem manajemen database:
Redundansi: Mereplikasi database Anda di beberapa server atau wilayah geografis akan memberikan opsi failover jika instance utama tidak berfungsi.
Failover Otomatis: Mekanisme untuk mendeteksi kegagalan dan beralih dengan lancar ke replika yang sehat, sehingga meminimalkan periode 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 agar dapat berfungsi bersama sebagai satu sistem. Dengan cara ini, semua node dalam cluster akan aktif dan menangani permintaan yang menyediakan load balancing dan redundansi.
Penggantian: Metode untuk kembali ke arsitektur asli menggunakan node utama dan replika pra-failover pada kapasitas aslinya.
Load Balancing: Mendistribusikan permintaan database ke beberapa instance akan meningkatkan performa dan menangani peningkatan traffic.
Pemantauan dan Notifikasi: Alat pemantauan mendeteksi masalah seperti kegagalan server, latensi tinggi, kehabisan resource, dan memicu notifikasi, atau prosedur failover otomatis.
Pencadangan dan Pemulihan: Pencadangan dapat digunakan untuk memulihkan database ke status sebelumnya jika terjadi kerusakan data atau kegagalan besar.
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 status, 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 menggunakan Distributed Configuration Store (DCS) yang disebut etcd. Salah satu penggunaan etcd adalah untuk menyimpan dan mengambil informasi sistem terdistribusi seperti konfigurasi, kondisi, dan status saat ini, yang memastikan konfigurasi yang konsisten di semua node.
High Availability Proxy (HAProxy) adalah software open source yang digunakan untuk load balancing dan membuat proxy aplikasi berbasis TCP dan HTTP, yang digunakan untuk meningkatkan performa dan keandalan aplikasi web dengan mendistribusikan permintaan masuk ke beberapa server. HAProxy menawarkan load balancing dengan mendistribusikan traffic jaringan di beberapa server. HAProxy juga mempertahankan status kesehatan server backend yang terhubung 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 utama, sehingga memberikan ketahanan dan konsistensi data yang kuat. Primary menunggu konfirmasi dari standby sinkron, yang dapat menyebabkan latensi yang lebih tinggi dan berpotensi menurunkan throughput karena waktu bolak-balik 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. Replika utama mengirim data WAL ke standby, yang menerapkannya secara asinkron. Pendekatan asinkron ini mengurangi latensi tulis dan meningkatkan performa, tetapi membawa risiko kehilangan data jika primary gagal sebelum standby menyelesaikan. Standby mungkin berada di belakang primer, sehingga berpotensi menyebabkan inkonsistensi selama failover.
Pilihan antara replikasi sinkron dan asinkron di cluster Patroni bergantung pada persyaratan spesifik untuk ketahanan, konsistensi, dan performa data. Replikasi sinkron lebih disukai dalam skenario saat 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.