PostgreSQL
 sql >> Teknologi Basis Data >  >> RDS >> PostgreSQL

Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian III:Patroni

Dalam posting blog kami sebelumnya, kami membahas kemampuan dan fungsi PostgreSQL Automatic Failover (PAF) oleh Cluster Labs dan Replication Manager (repmgr) oleh 2ndQuadrant. Di pos terakhir seri ini, kami akan meninjau solusi terakhir, Patroni by Zalando, dan membandingkan ketiganya di bagian akhir sehingga Anda dapat menentukan kerangka ketersediaan tinggi mana yang terbaik untuk penerapan hosting PostgreSQL Anda.

  • Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian I:Kegagalan Otomatis PostgreSQL
  • Mengelola Ketersediaan Tinggi di PostgreSQL – Bagian II:Manajer Replikasi

Pelindung untuk PostgreSQL

Patroni berasal sebagai garpu Gubernur, sebuah proyek dari Compose. Ini adalah rangkaian alat sumber terbuka, yang ditulis dengan Python, untuk mengelola ketersediaan tinggi klaster PostgreSQL. Alih-alih membangun protokol konsistensinya sendiri, Patroni dengan cerdas memanfaatkan model konsistensi yang disediakan oleh Distributed Configuration Store (DCS). Ini juga mendukung solusi DCS lainnya seperti Zookeeper, etcd, Consul, dan Kubernetes.

Patroni memastikan penyiapan end-to-end cluster PostgreSQL HA, termasuk replikasi streaming. Ini mendukung berbagai cara untuk membuat node siaga, dan berfungsi seperti template yang dapat disesuaikan dengan kebutuhan Anda.

Alat yang kaya fitur ini mengekspos fungsinya melalui REST API dan juga melalui utilitas baris perintah yang disebut patronictl. Ini mendukung integrasi dengan HAProxy dengan menggunakan API health check-nya untuk menangani load balancing.

Patroni juga mendukung notifikasi acara dengan bantuan callback, yang merupakan skrip yang dipicu oleh tindakan tertentu. Ini memungkinkan pengguna untuk melakukan tindakan pemeliharaan apa pun dengan menyediakan fungsionalitas jeda/lanjutkan. Fitur dukungan Watchdog membuat kerangka kerja lebih kuat.

Cara Kerjanya

Awalnya, binari PostgreSQL dan Patroni perlu diinstal. Setelah ini selesai, Anda juga perlu menyiapkan konfigurasi HA DCS. Semua konfigurasi yang diperlukan untuk bootstrap cluster perlu ditentukan dalam file konfigurasi yaml dan Patroni akan menggunakan file ini untuk inisialisasi. Pada node pertama, Patroni menginisialisasi database, memperoleh kunci pemimpin dari DCS, dan memastikan node dijalankan sebagai master.

Langkah selanjutnya adalah menambahkan node siaga, di mana Patroni menyediakan beberapa opsi. Secara default, Patroni menggunakan pg_basebackup untuk membuat node siaga, dan juga mendukung metode kustom seperti WAL-E, pgBackRest, Barman, dan lainnya untuk pembuatan node siaga. Patroni membuatnya sangat mudah untuk menambahkan node siaga, dan menangani semua tugas bootstrap dan pengaturan replikasi streaming Anda.

Mengelola Ketersediaan Tinggi di #PostgreSQL – Bagian III:Patroni vs. PAF vs. repmgrKlik Untuk Tweet

Setelah penyiapan cluster Anda selesai, Patroni akan secara aktif memantau cluster dan memastikannya dalam keadaan sehat. Node master memperbarui kunci pemimpin setiap ttl detik (default:30 detik). Ketika node master gagal memperbarui kunci pemimpin, Patroni memicu pemilihan, dan node yang akan mendapatkan kunci pemimpin akan dipilih sebagai master baru.

Bagaimana Menangani Skenario Split Brain?

Dalam sistem terdistribusi, konsensus memainkan peran penting dalam menentukan konsistensi, dan Patroni menggunakan DCS untuk mencapai konsensus. Hanya node yang memegang kunci pemimpin yang dapat menjadi master dan kunci pemimpin diperoleh melalui DCS. Jika master node tidak menahan kunci leader, maka akan langsung diturunkan oleh Patroni untuk dijalankan sebagai standby. Dengan cara ini, kapan saja, hanya ada satu master yang berjalan di sistem.

Apakah Ada Persyaratan Penyiapan?

  • Patroni membutuhkan python 2.7 dan yang lebih baru.
  • DCS dan modul python spesifiknya harus diinstal. Untuk tujuan pengujian, DCS dapat diinstal pada node yang sama yang menjalankan PostgreSQL. Namun, dalam produksi, DCS harus diinstal pada node yang terpisah.
  • File konfigurasi yaml harus ada menggunakan setelan konfigurasi tingkat tinggi berikut:

    Global/Universal
    Ini termasuk konfigurasi seperti nama host (nama) yang harus unik untuk cluster, nama cluster (lingkup) dan jalur untuk menyimpan konfigurasi di DCS (namespace).

    Log
    Setelan log khusus Patroni termasuk level, format, file_num, file_size, dll.

    Konfigurasi bootstrap
    Ini adalah konfigurasi global untuk cluster yang akan ditulis ke DCS. Parameter konfigurasi ini dapat diubah dengan bantuan API Patroni atau langsung di DCS. Konfigurasi bootstrap mencakup metode pembuatan siaga, parameter initdb, skrip inisialisasi pasca, dll. Ini juga berisi konfigurasi batas waktu, parameter untuk memutuskan penggunaan fitur PostgreSQL seperti slot replikasi , mode sinkron, dll. Bagian ini akan ditulis ke dalam ///config dari penyimpanan konfigurasi yang diberikan setelah inisialisasi cluster baru.

    PostgreSQL
    Bagian ini berisi parameter khusus PostgreSQL seperti otentikasi, jalur direktori untuk data, biner dan konfigurasi, mendengarkan alamat ip, dll.

    REST API
    Bagian ini mencakup konfigurasi khusus Patroni yang terkait dengan REST API seperti mendengarkan alamat, autentikasi, SSL, dll.

    Konsul
    Setelan khusus untuk Konsul DCS.

    Dll
    Setelan khusus untuk Dll DCS.

    Pameran
    Setelan khusus untuk Peserta Pameran DCS.

    Kubernetes
    Setelan khusus untuk Kubernetes DCS.

    Penjaga Kebun Binatang
    Setelan khusus untuk ZooKeeper DCS.

    Watchdog
    Setelan khusus untuk Watchdog.

Pro Patroni

  • Patroni memungkinkan penyiapan cluster secara menyeluruh.
  • Mendukung REST API dan integrasi HAproxy.
  • Mendukung pemberitahuan acara melalui skrip panggilan balik yang dipicu oleh tindakan tertentu.
  • Memanfaatkan DCS untuk konsensus.

Kontra Patroni

  • Patroni tidak akan mendeteksi kesalahan konfigurasi standby dengan node yang tidak dikenal atau tidak ada dalam konfigurasi pemulihan. Node akan ditampilkan sebagai slave meskipun standby berjalan tanpa terhubung ke node standby master/cascading.
  • Pengguna perlu menangani penyiapan, pengelolaan, dan peningkatan versi perangkat lunak DCS.
  • Memerlukan beberapa port terbuka untuk komunikasi komponen:
    • Port API REST untuk Patroni
    • Minimal 2 port untuk DCS

Skenario Uji Ketersediaan Tinggi

Kami melakukan beberapa pengujian pada manajemen HA PostgreSQL menggunakan Patroni. Semua pengujian ini dilakukan 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 Patroni mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
2 Hentikan proses PostgreSQL Patroni mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
3 Reboot server Patroni harus dimulai setelah reboot, kecuali jika dikonfigurasi untuk tidak memulai saat reboot. Setelah Patroni dimulai, ia memulai proses PostgreSQL dan menyiapkan konfigurasi siaga.

  • Tidak ada gangguan pada aplikasi penulis.
4 Hentikan proses Patroni
  • Itu tidak menghentikan proses PostgreSQL.
  • daftar pelindung tidak menampilkan server ini.
  • Tidak ada gangguan pada aplikasi penulis.

Jadi, pada dasarnya, Anda perlu memantau kesehatan proses Patroni – jika tidak, akan menimbulkan masalah.

Pengujian Server Master/Primer

Sl. Tidak Skenario Pengujian Pengamatan
1 Bunuh proses PostgreSQL Patroni mengembalikan proses PostgreSQL ke status berjalan. Patroni yang berjalan pada simpul tersebut memiliki kunci utama sehingga pemilihan tidak dipicu.

  • Ada waktu henti di aplikasi penulis.
2 Hentikan proses PostgreSQL dan kembalikan segera setelah health check berakhir Patroni mengembalikan proses PostgreSQL ke status berjalan. Patroni yang berjalan pada simpul tersebut memiliki kunci utama sehingga pemilihan tidak dipicu.

  • Ada waktu henti di aplikasi penulis.
3 Reboot server Kegagalan terjadi dan salah satu server siaga dipilih sebagai master baru setelah mendapatkan kunci. Ketika Patroni dimulai pada master lama, itu membawa kembali master lama dan melakukan pg_rewind dan mulai mengikuti master baru.T

  • Ada waktu henti di aplikasi penulis.
4 Hentikan/Bunuh proses Patroni
  • Salah satu server siaga memperoleh kunci DCS dan menjadi master dengan mempromosikan dirinya sendiri.
  • Master lama masih berjalan dan itu mengarah ke skenario multi-master. Aplikasi masih menulis ke master lama.
  • Setelah Patroni dimulai pada master lama, itu memutar ulang master lama (use_pg_rewind disetel ke true) ke timeline master baru dan lsn dan mulai mengikuti master baru.

Seperti yang Anda lihat di atas, sangat penting untuk memantau kesehatan proses Patroni pada master. Kegagalan untuk melakukannya dapat menyebabkan skenario multi-master dan potensi kehilangan data.

Tes Isolasi Jaringan

Sl. Tidak Skenario Pengujian Pengamatan
1 Isolasi jaringan server master dari server lain Komunikasi DCS diblokir untuk node master.

  • PostgreSQL diturunkan di server master.
  • Seorang master baru terpilih di partisi mayoritas.
  • Ada waktu henti di aplikasi penulis.
2 Isolasi jaringan server siaga dari server lain Komunikasi DCS diblokir untuk node siaga.

  • Layanan PostgreSQL berjalan, namun node tidak dipertimbangkan untuk pemilihan.
  • Tidak ada gangguan pada aplikasi penulis.

Apa Kerangka HA PostgreSQL Terbaik?

Patroni adalah alat yang berharga untuk administrator database PostgreSQL (DBA), karena melakukan penyiapan dan pemantauan end-to-end cluster PostgreSQL. Fleksibilitas dalam memilih DCS dan pembuatan standby merupakan keuntungan bagi pengguna akhir, karena mereka dapat memilih metode yang nyaman bagi mereka.

REST API, integrasi HaProxy, dukungan Watchdog, callback, dan manajemen kaya fiturnya menjadikan Patroni solusi terbaik untuk manajemen PostgreSQL HA.

Pengujian Kerangka HA PostgreSQL:PAF vs. repmgr vs. Patroni

Termasuk di bawah ini adalah tabel komprehensif yang merinci hasil semua pengujian yang telah kami lakukan pada ketiga kerangka kerja – PostgreSQL Automatic Failover (PAF), Replication Manager (repmgr) dan Patroni.

Pengujian Server Siaga

Skenario Pengujian PostgreSQL Automatic Failover (PAF) Manajer Replikasi (repmgr) Pelindung
Bunuh proses PostgreSQL Pacemaker mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
 Server siaga ditandai sebagai gagal. Intervensi manual diperlukan untuk memulai kembali proses PostgreSQL.

  • Tidak ada gangguan pada aplikasi penulis.
 Patroni mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
Hentikan proses PostgreSQL Pacemaker mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
 Server siaga ditandai sebagai gagal. Intervensi manual diperlukan untuk memulai kembali proses PostgreSQL.

  • Tidak ada gangguan pada aplikasi penulis.
 Patroni mengembalikan proses PostgreSQL ke status berjalan.

  • Tidak ada gangguan pada aplikasi penulis.
Reboot server Server siaga pada awalnya ditandai offline. Setelah server muncul setelah reboot, PostgreSQL dimulai oleh Pacemaker dan server ditandai sebagai online. Jika pagar diaktifkan, simpul tidak akan ditambahkan secara otomatis ke klaster.

  • Tidak ada gangguan pada aplikasi penulis.
 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.
 Patroni needs to be started after reboot, unless configured to not start on reboot. Once Patroni was started, it started the PostgreSQL process and setup the standby configuration.

  • There was no disruption of the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and was marked offline.
  • There was no disruption of the writer application.
 Agent:repmgrd

  • The standby server will not be part of automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption of the writer application.
 Agent:patroni

  • It did not stop the PostgreSQL process.
  • patronictl list did not display this server.
  • There was no disruption of the writer application.

Pengujian Server Master/Primer

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Kill the PostgreSQL process Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connection on all standby servers for a fixed interval. When all retries failed, an election was triggered on all the standby servers. As a result of the election, the standby which had the latest received LSN got promoted. The standby servers which lost the election will wait for the notification from the new master node and will follow it once they receive the notification.Manual intervention was required to start the postgreSQL process again.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Stop the PostgreSQL process and bring it back immediately after health check expiry Pacemaker brought the PostgreSQL process back to running state. Primary got recovered within the threshold time and hence election was not triggered.

  • There was downtime in the writer application.
 repmgrd started health check for primary server connections on all standby servers for a fixed interval. When all the 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.

  • There was downtime in the writer application.
 Patroni brought the PostgreSQL process back to running state. Patroni running on that node had primary lock and hence election was not triggered.

  • There was downtime in the writer application.
Reboot the server Election was triggered by Pacemaker after the threshold time for which master was not available. Server siaga yang paling memenuhi syarat dipromosikan sebagai master baru. Once the old master came up after reboot, it was added back to the cluster as a standby. If fencing was enabled, then node wouldn’t have been added automatically to cluster.

  • There was downtime in the writer application.
 repmgrd started 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 run to add the server back to the cluster.

  • There was downtime in the writer application.
 Failover happened and one of the standby servers was elected as the new master after obtaining the lock. When Patroni was started on the old master, it brought back the old master up and performed pg_rewind and started following the new master.

  • There was downtime in the writer application.
Stop the framework agent process Agent:pacemaker

  • The PostgreSQL process was stopped and it was marked offline.
  • Election was triggered and new master was elected.
  • There was downtime in writer application.
 Agent:repmgrd

  • The primary server will not be part of the automated failover situation.
  • PostgreSQL service was found to be running.
  • There was no disruption in writer application.
 Agent:patroni

  • One of the standby servers acquired the DCS lock and became the master by promoting itself.
  • The old master was still running and it led to multi-master scenario. The application was still writing to the old master.
  • Once Patroni was started on the old master, it rewound the old master (use_pg_rewind was set to true) to the new master timeline and lsn and started following the new master.

Tes Isolasi Jaringan

Test Scenario PostgreSQL Automatic Failover (PAF) Replication Manager (repmgr) Patroni
Network isolate the master server from other servers (split brain scenario) Corosync traffic was blocked on the master server.

  • PostgreSQL service was turned off and master server was marked offline due to quorum policy.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
 All servers have the same value for location in repmgr configuration:

  • repmgrd started 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.

The standby servers have the same value for location but the primary had a different value for location in repmgr configuration:

  • repmgrd started election when master connection health check failed on all standby servers.
  • But, there was no new master elected since the standby servers had 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.
 DCS communication was blocked for master node.

  • PostgreSQL was demoted on the master server.
  • A new master was elected in the majority partition.
  • There was a downtime in the writer application.
Network-isolate the standby server from other servers Corosync traffic was blocked on the standby server.

  • The server was marked offline and PostgreSQL service was turned off due to quorum policy.
  • There was no disruption in the writer application.
  • repmgrd went into degrade monitoring mode.
  • The PostgreSQL process was still running on the standby node.
  • Manual intervention was required after the network isolation was corrected.
 DCS communication was blocked for the standby node.

  • The PostgreSQL service was running, however, the node was not considered for elections.
  • There was no disruption in the writer application.


  1. Database
    2.   
  2. Mysql
    3.   
  3. Oracle
    4.   
  4. Sqlserver
    5.   
  5. PostgreSQL
    6.   
  6. Access
    7.   
  7. SQLite
    8.   
  8. MariaDB

  1. kesalahan aplikasi uji django - Mendapat kesalahan saat membuat basis data uji:izin ditolak untuk membuat basis data

  2. Tidak dapat terhubung ke postgres menggunakan jdbc di pyspark Shell

  3. SQL - Menggabungkan beberapa kueri serupa

  4. Cara menemukan catatan duplikat di PostgreSQL

  5. Cara Menguji Tanggal yang Tumpang Tindih di PostgreSQL