Tujuan utama dari pengaturan multi-datacenter (atau multi-DC) — terlepas dari apakah ekosistem database adalah SQL (PostgreSQL, MySQL), atau NoSQL (MongoDB, Cassandra) untuk menyebutkan beberapa saja — adalah Latensi Rendah untuk pengguna akhir, Ketersediaan Tinggi, dan Pemulihan Bencana. Inti dari lingkungan seperti itu terletak pada kemampuan untuk mereplikasi data, dengan cara yang memastikan daya tahannya (sebagai catatan tambahan, parameter konfigurasi daya tahan Cassandra serupa dengan yang digunakan oleh PostgreSQL). Berbagai persyaratan replikasi akan dibahas di bawah, namun kasus ekstrem akan dibiarkan penasaran untuk penelitian lebih lanjut.
Replikasi menggunakan pengiriman log asinkron telah tersedia di PostgreSQL untuk waktu yang lama, dan replikasi sinkron yang diperkenalkan di versi 9.1 membuka serangkaian opsi baru untuk pengembang alat manajemen PostgreSQL.
Hal yang Perlu Dipertimbangkan
Salah satu cara untuk memahami kompleksitas implementasi multi-DC PostgreSQL adalah dengan belajar dari solusi yang diterapkan untuk sistem database lain, sambil mengingat bahwa PostgreSQL bersikeras untuk mematuhi ACID.
Penyiapan multi-DC mencakup, dalam banyak kasus, setidaknya satu pusat data di cloud. Sementara penyedia cloud menanggung beban mengelola replikasi database atas nama klien mereka, mereka biasanya tidak cocok dengan fitur yang tersedia di alat manajemen khusus. Misalnya dengan banyak perusahaan yang menggunakan solusi cloud hybrid dan/atau multi-cloud, selain infrastruktur lokal yang sudah ada, alat multi-DC harus mampu menangani lingkungan campuran seperti itu.
Selanjutnya, untuk meminimalkan waktu henti selama failover, sistem manajemen PostgreSQL harus dapat meminta (melalui panggilan API) pembaruan DNS, sehingga permintaan database dirutekan ke master cluster baru.
Jaringan yang mencakup area geografis yang luas adalah koneksi dengan latensi tinggi dan semua solusi harus berkompromi:lupakan replikasi sinkron, dan gunakan satu primer dengan banyak replika baca. Lihat studi AWS MongoDB dan Somenines/Galera Cluster untuk analisis mendalam tentang efek jaringan pada replikasi. Pada catatan terkait, alat yang bagus untuk menguji latensi antar lokasi adalah Statistik Ping Jaringan Ajaib.
Sementara sifat latensi tinggi WAN tidak dapat diubah, pengalaman pengguna dapat ditingkatkan secara dramatis dengan memastikan bahwa pembacaan disajikan dari replika baca yang dekat dengan lokasi pengguna, namun dengan beberapa peringatan. Dengan memindahkan replika dari yang utama, penulisan tertunda dan dengan demikian kita harus menyingkirkan replikasi sinkron. Solusinya juga harus dapat mengatasi masalah lain seperti konsistensi baca-setelah-tulis dan pembacaan sekunder yang basi karena terputusnya koneksi.
Untuk meminimalkan RTO, data perlu direplikasi ke penyimpanan tahan lama yang juga mampu memberikan throughput baca yang tinggi, dan menurut Citus Data satu opsi yang memenuhi persyaratan tersebut adalah AWS S3.
Gagasan tentang beberapa pusat data menyiratkan bahwa sistem manajemen basis data harus mampu menyajikan DBA dengan pandangan global dari semua pusat data dan berbagai cluster PostgreSQL di dalamnya, mengelola beberapa versi PostgreSQL, dan mengonfigurasi replikasi di antara mereka.
Saat mereplikasi penulisan ke pusat data regional, penundaan propagasi harus dipantau. Jika penundaan melebihi ambang batas, alarm harus dipicu yang menunjukkan bahwa replika berisi data basi. Prinsip yang sama berlaku untuk replikasi multi-master asinkron.
Dalam penyiapan sinkron, latensi tinggi, atau gangguan jaringan dapat menyebabkan penundaan dalam melayani permintaan klien sambil menunggu komit selesai, sementara dalam konfigurasi asinkron ada risiko otak terbelah, atau kinerja yang menurun untuk jangka waktu yang lama. Split-brain dan penundaan pada commit sinkron tidak dapat dihindari bahkan dengan solusi replikasi yang sudah mapan seperti yang dijelaskan dalam artikel Cluster Database Geo-Distributed dengan Galera.
Pertimbangan lainnya adalah dukungan vendor — hingga tulisan ini dibuat, AWS tidak mendukung replika lintas wilayah PostgreSQL.
Sistem manajemen cerdas harus memantau latensi jaringan antara pusat data dan merekomendasikan atau menyesuaikan perubahan, mis. replikasi sinkron sangat baik antara AWS Availability Zone di mana pusat data terhubung menggunakan jaringan serat. Dengan cara itu solusi dapat mencapai nol kehilangan data dan juga dapat menerapkan replikasi master-master bersama dengan penyeimbangan beban. Perhatikan bahwa AWS Aurora PostgreSQL saat ini tidak menyediakan opsi replikasi master-master.
Tentukan tingkat replikasi:cluster, database, tabel. Kriteria keputusan harus mencakup biaya bandwidth.
Terapkan replikasi berjenjang untuk mengatasi gangguan jaringan yang dapat mencegah replika menerima pembaruan dari master karena jarak geografis.
Solusi
Mempertimbangkan semua persyaratan mengidentifikasi produk yang paling cocok untuk pekerjaan itu. Catatan peringatan:setiap solusi dilengkapi dengan peringatannya sendiri yang harus ditangani dengan mengikuti rekomendasi dalam dokumentasi produk. Lihat misalnya persyaratan Pemantauan BDR.
Dokumentasi resmi PostgreSQL berisi daftar aplikasi open source non-komersial, dan daftar yang diperluas termasuk solusi closed source komersial dapat ditemukan di halaman wiki Replication, Clustering, dan Connection Pooling. Beberapa dari alat tersebut telah ditinjau secara lebih rinci di artikel Solusi HA Pengelompokan PG Teratas untuk PostgreSQL.
Tidak ada solusi turnkey, tetapi beberapa produk dapat menyediakan sebagian besar fitur, terutama saat bekerja dengan vendor.
Berikut daftar yang tidak lengkap:
- Citus Data menyediakan build PostgreSQL mereka sendiri, disempurnakan dengan fitur perusahaan yang mengesankan dan integrasi mendalam dengan AWS.
- EnterpriseDB menawarkan rangkaian besar layanan yang dapat digabungkan untuk memenuhi sebagian besar persyaratan. Sebagian besar informasi ada di Dokumentasi Produk.
- Postgres-BDR adalah alat replikasi canggih yang dirancang khusus untuk cluster yang terdistribusi secara geografis, namun tidak terintegrasi dengan penyedia cloud mana pun.
- ClusterControl hadir dengan set fitur yang mengesankan- untuk mengelola PostgreSQL. Ini juga memiliki integrasi cloud yang terbatas.
- ElephantSQL bekerja di banyak penyedia cloud. Namun, tidak ada opsi untuk penyiapan di lokasi.
- PostgreSQL yang renyah untuk Kubernetes adalah produk agnostik cloud yang dibangun di atas PostgreSQL hulu.
Kesimpulan
Seperti yang telah kita lihat, saat memilih solusi multi-pusat data PostgreSQL, tidak ada solusi satu ukuran yang cocok untuk semua. Seringkali, kompromi adalah suatu keharusan. Namun, pemahaman yang baik tentang persyaratan dan implikasinya bisa sangat membantu dalam membuat keputusan yang tepat.
Dibandingkan dengan data statis (hanya baca), solusi untuk database perlu mempertimbangkan replikasi pembaruan (tulis). Literatur yang menjelaskan solusi replikasi SQL dan NoSQL menekankan penggunaan satu sumber kebenaran untuk penulisan dengan banyak replika untuk menghindari masalah seperti split-brain, dan konsistensi baca-setelah-tulis.
Terakhir, interoperabilitas adalah persyaratan utama mengingat penyiapan multi-DC dapat menjangkau pusat data yang terletak di lokasi, dan berbagai penyedia cloud.
