Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian II:Manajer Replikasi

Apakah Anda menerapkan PostgreSQL di cloud dan ingin memahami opsi Anda untuk mencapai ketersediaan tinggi? Dalam postingan blog kami sebelumnya, Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian I, kami membahas kemampuan dan fungsi PostgreSQL Automatic Failover (PAF) oleh ClusterLabs. Di Bagian II, kami memperkenalkan kepada Anda alat sumber terbuka alternatif, Pengelola Replikasi dari 2ndQuadrant, untuk diikuti dengan cermat oleh Bagian III tempat kami menyelami alternatif ketiga kami, Patroni by Zalando.

Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian I:Kegagalan Otomatis PostgreSQL
Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian III:Patroni

Manajer Replikasi (repmgr)

repmgr adalah rangkaian alat sumber terbuka yang dikembangkan oleh 2ndQuadrant untuk mengelola replikasi dan failover klaster PostgreSQL Anda. Ini menyediakan alat untuk menyiapkan, mengonfigurasi, mengelola, dan memantau replikasi PostgreSQL, dan juga memungkinkan Anda untuk melakukan tugas peralihan dan failover manual menggunakan utilitas repmgr. Alat gratis ini mendukung dan meningkatkan replikasi streaming bawaan PostgreSQL.

Replication Manager menyediakan dua alat utama untuk mengelola replikasi dan failover PostgreSQL.

repmgr

Utilitas antarmuka baris perintah yang memungkinkan Anda melakukan berbagai tugas administratif.
repmgr memungkinkan Anda untuk menyiapkan server siaga, mempromosikan siaga, melakukan peralihan, dan memantau status kluster PostgreSQL Anda.
Ini juga menyediakan opsi dry run untuk hampir semua perintah administratif.

repmgrd

Ini adalah daemon yang:

Secara aktif memantau cluster PostgreSQL dan melakukan tindakan yang diperlukan berdasarkan status cluster.
Melakukan failover otomatis jika node utama mati dengan mempromosikan standby yang paling memenuhi syarat sebagai primer baru.
Menyediakan opsi untuk memantau dan menyimpan data yang terkait dengan kinerja replikasi.
Menyediakan pemberitahuan dengan memanggil skrip pengguna untuk acara terdaftar.

Cara Kerjanya

repmrg tidak hanya mengelola replikasi kluster PostgreSQL, tetapi juga memiliki kemampuan untuk menyiapkan server siaga untuk replikasi. Setelah instalasi awal, kita perlu membuat perubahan pada file konfigurasi repmgr (repmgr.conf) dengan detail yang diperlukan di setiap server. Ketika server dikonfigurasi, server harus didaftarkan dengan repmgr menggunakan perintah register primer/siaga repmgr. Pertama, node utama diatur dan didaftarkan. Kemudian, server standby dibuat dan dikonfigurasi menggunakan perintah repmgr standby clone yang mengkloning node standby PostgreSQL dari server PostgreSQL lain.

Replication Manager menggunakan fitur ekstensi PostgreSQL dan membuat skemanya sendiri di database cluster untuk menyimpan informasi terkait cluster. Pemasangan ekstensi dan pembuatan skema terjadi selama pendaftaran server utama menggunakan repmgr. Setelah penyiapan selesai, operasi administratif manual seperti promosi, ikuti, peralihan, dll. dapat dilakukan menggunakan utilitas repmgr. Untuk operasi peralihan, diperlukan SSH tanpa kata sandi untuk diatur di antara node.

Failover otomatis dapat diatur menggunakan repmgrd. repmgrd membutuhkan perpustakaan bersama 'repmgr' untuk dimuat pada saat memulai server PostgreSQL. Nama perpustakaan harus disebutkan di shared_preload_libraries parameter konfigurasi di file postgresql.conf. Juga, agar repmgrd berfungsi, failover=automatic parameter perlu diatur dalam file repmgr.conf. Setelah semua parameter ini disetel, daemon repmgrd mulai memantau cluster secara aktif. Jika ada kegagalan di node utama, itu akan mencoba menyambung kembali beberapa kali. Ketika semua upaya untuk menyambung ke primer gagal, standby yang paling memenuhi syarat dipilih melalui pemilihan sebagai primer baru oleh repmgrd.

repmgr juga mendukung pemberitahuan acara. Ini memiliki serangkaian peristiwa yang telah ditentukan sebelumnya dan menyimpan setiap kemunculan peristiwa ini di tabel repmgr.events. repmgr memungkinkan pemberitahuan acara diteruskan ke program atau skrip yang ditentukan pengguna yang dapat mengambil tindakan lebih lanjut, seperti mengirim email atau memicu peringatan apa pun. Ini dilakukan dengan menyetel event_notification_command parameter di repmgr.conf.

Bagaimana Cara Menangani Skenario Split Brain?

repmgr menangani skenario otak terbelah menggunakan lokasi parameter, di mana setiap node harus menentukan parameter lokasi berdasarkan pusat data di mana ia ditempatkan. Jika terjadi perpecahan jaringan, repmgr akan memastikan promosi node yang berada di lokasi yang sama dengan yang utama. Jika tidak menemukan simpul apa pun di lokasi itu, itu tidak akan mempromosikan simpul apa pun di lokasi mana pun.

Ini juga menangani isolasi jaringan jika jumlah server genap dalam sebuah cluster. Ini dilakukan dengan menggunakan node tambahan yang disebut server saksi. Server saksi adalah simpul yang dianggap hanya untuk penghitungan suara mayoritas. Tidak akan ada instalasi PostgreSQL di server itu, dan karenanya, tidak ada bagian yang dimainkan dalam replikasi.

Apakah Ada Persyaratan Penyiapan?

repmgr akan membutuhkan database khusus dan pengguna dengan hak pengguna super. Namun, ada juga opsi untuk menyediakan pengguna super jika Anda tidak bersedia memberikan akses pengguna super kepada pengguna repmgr.
Jika Anda ingin repmgr menyalin file konfigurasi yang terletak di luar direktori data PostgreSQL, dan/atau untuk menguji fungsionalitas peralihan, Anda juga memerlukan koneksi SSH tanpa kata sandi antara kedua server, dan rsync harus diinstal.
Jika Anda bermaksud menggunakan perintah berbasis layanan selain pg_ctl (yang digunakan oleh repmgr secara default) untuk memulai, menghentikan, memuat ulang, dan memulai ulang, Anda dapat menentukannya di repmgr file konfigurasi (repmgr.conf).

Parameter konfigurasi dasar yang diperlukan dalam file konfigurasi repmgr adalah sebagai berikut:

node_id (int) – Sebuah bilangan bulat unik yang lebih besar dari nol yang mengidentifikasi node.node_name (string) – String arbitrer (tetapi unik), menggunakan nama host server atau pengenal lain yang jelas terkait dengan server disarankan untuk menghindari kebingungan.

conninfo (string) – Informasi koneksi database sebagai string conninfo. Semua server dalam cluster harus dapat terhubung ke node lokal menggunakan string ini.

direktori_data (string) – Direktori data node. Ini diperlukan oleh repmgr untuk melakukan operasi ketika instance PostgreSQL tidak berjalan dan tidak ada cara lain untuk menentukan direktori data.

repmgr Pro

Repmgr menyediakan utilitas yang membantu menyiapkan node utama dan siaga serta mengonfigurasi replikasi.
Tidak menggunakan port tambahan untuk komunikasi. Jika Anda ingin melakukan peralihan, hanya SSH tanpa kata sandi yang harus dikonfigurasi.
Menyediakan pemberitahuan dengan memanggil skrip pengguna untuk peristiwa yang terdaftar.
Melakukan failover otomatis jika server utama gagal.

kontra repmgr

repmgr tidak mendeteksi jika standby salah dikonfigurasi dengan node yang tidak dikenal atau tidak ada dalam konfigurasi pemulihan. Node akan ditampilkan sebagai standby meskipun sedang berjalan tanpa terhubung ke node standby primer/cascading.
Tidak dapat mengambil status node lain dari node di mana layanan PostgreSQL tidak aktif. Oleh karena itu, ini tidak memberikan solusi kontrol terdistribusi.
Ini tidak menangani pemulihan kesehatan setiap node.

Mengelola Ketersediaan Tinggi di #PostgreSQL – Bagian II:Alat repmgr Sumber Terbuka Klik Untuk Tweet

Skenario Uji Ketersediaan Tinggi

Kami melakukan beberapa pengujian pada manajemen ketersediaan tinggi PostgreSQL menggunakan repmgr. Semua pengujian ini dijalankan saat aplikasi sedang berjalan dan memasukkan data ke database PostgreSQL. Aplikasi ini ditulis menggunakan PostgreSQL Java JDBC Driver dengan memanfaatkan kemampuan failover koneksi.

Pengujian Server Siaga

Sl. Tidak	Skenario Pengujian	Pengamatan
1	Bunuh proses PostgreSQL	Server siaga ditandai sebagai gagal. Tidak ada gangguan pada aplikasi penulis. Intervensi manual diperlukan untuk memulai kembali proses PostgreSQL.
2	Hentikan proses PostgreSQL	Server siaga ditandai sebagai gagal. Tidak ada gangguan pada aplikasi penulis. Intervensi manual diperlukan untuk memulai kembali proses PostgreSQL.
3	Reboot server	Server siaga ditandai sebagai gagal. Setelah server muncul setelah reboot, PostgreSQL dimulai secara manual dan server ditandai sebagai berjalan. Tidak ada gangguan pada aplikasi penulis.
4	Hentikan proses repmgrd	Server siaga tidak akan menjadi bagian dari situasi failover otomatis. Layanan PostgreSQL ditemukan berjalan. Tidak ada gangguan pada aplikasi penulis.

Pengujian Server Master/Primer

Sl. Tidak	Skenario Pengujian	Pengamatan
1	Bunuh proses PostgreSQL	repmgrd memulai pemeriksaan kesehatan untuk koneksi server utama di semua server siaga untuk interval tetap. Ketika semua percobaan ulang gagal, pemilihan dipicu di semua server siaga. Sebagai hasil dari pemilihan, siaga yang menerima LSN terakhir dipromosikan. Server siaga yang kalah dalam pemilihan akan menunggu notifikasi dari master node baru dan mengikutinya setelah mereka menerima notifikasi. Ada waktu henti di aplikasi penulis. Intervensi manual diperlukan untuk memulai kembali proses PostgreSQL.
2	Stop the PostgreSQL process and bring it back immediately after health check expiry	repmgrd started the health check for the primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby nodes. However, the newly elected master didn’t notify the existing standby servers since the old master was back. Cluster was left in an indeterminate state and manual intervention was required.
3	Reboot the server	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted. When this server came back, it didn’t join the cluster and was marked failed. repmgr node rejoin command was ran to add the server back to the cluster. There was downtime in the writer application.
4	Stop the repmgr process	The primary server will not be a part of the automated failover situation. PostgreSQL service was found to be running. There was no disruption in the writer application.

Network Isolation Tests

Sl. No	Test Scenario	Observation
1	Network isolate the primary server from other servers (all have same value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. The eligible standby was promoted, but the PostgreSQL process was still running on the old master node. There were two nodes running as master. Manual intervention was required after the network isolation was corrected.
2	Network isolate the primary server from other servers (the standby servers has same value for location but primary had a different value for location in repmgr configuration)	repmgrd started the election when master connection health check failed on all standby servers. But, there was no new master elected since the standby servers had a location different from that of the primary. repmgrd went into degrade monitoring mode. PostgreSQL was running on all the nodes and there was only one master in the cluster.

Inference

repmgr provides several commands to setup and monitor PostgreSQL replication. It is feature-rich and also eases the job of the database administrator (DBA). However, it’s not a full fledged high availability management tool since it will not manage the resources. Manual intervention is required to ensure the resource is in proper state.

So, in this post, we’ve discussed the capabilities and workings of Replication Manager by 2ndQuadrant. In our next post, we’ll discuss the same high availability aspects using Patroni by Zalando. For users looking to automate their high availability in the cloud, check out our PostgreSQL on Azure and PostgreSQL on AWS fully managed solutions.