Menguji penyiapan ketersediaan tinggi
Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Memastikan keandalan dan kualitas penyiapan Patroni ketersediaan tinggi Anda sangat penting untuk mempertahankan operasi database yang berkelanjutan dan meminimalkan periode nonaktif. Halaman ini memberikan panduan komprehensif untuk menguji cluster Patroni, yang mencakup berbagai skenario kegagalan, konsistensi replikasi, dan mekanisme failover.

Menguji penyiapan Patroni

Hubungkan ke instance patroni Anda (alloydb-patroni1, alloydb-patroni2, atau alloydb-patroni3) dan buka folder patroni AlloyDB Omni.
```
cd /alloydb/
```

Periksa log Patroni.

docker compose logs alloydbomni-patroni

Entri terakhir harus mencerminkan informasi tentang node Patroni. Anda akan melihat sesuatu yang mirip dengan berikut ini.

alloydbomni-patroni        | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock
alloydbomni-patroni        | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock

Hubungkan ke instance apa pun yang menjalankan Linux dan memiliki konektivitas jaringan ke instance Patroni utama Anda, alloydb-patroni1, dan dapatkan informasi tentang instance tersebut. Anda mungkin perlu menginstal alat jq dengan menjalankan sudo apt-get install jq -y.

curl -s http://alloydb-patroni1:8008/patroni | jq .

Anda akan melihat tampilan yang mirip dengan berikut ini.

{
  "state": "running",
  "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00",
  "role": "master",
  "server_version": 150005,
  "xlog": {
    "location": 83886408
  },
  "timeline": 1,
  "replication": [
    {
      "usename": "alloydbreplica",
      "application_name": "patroni2",
      "client_addr": "10.172.0.40",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    },
    {
      "usename": "alloydbreplica",
      "application_name": "patroni3",
      "client_addr": "10.172.0.41",
      "state": "streaming",
      "sync_state": "async",
      "sync_priority": 0
    }
  ],
  "dcs_last_seen": 1715870011,
  "database_system_identifier": "7369600155531440151",
  "patroni": {
    "version": "3.3.0",
    "scope": "my-patroni-cluster",
    "name": "patroni1"
  }
}

Memanggil endpoint HTTP API Patroni di node Patroni akan menampilkan berbagai detail tentang status dan konfigurasi instance PostgreSQL tertentu yang dikelola oleh Patroni, termasuk informasi status cluster, linimasa, informasi WAL, dan health check yang menunjukkan apakah node dan cluster aktif dan berjalan dengan benar.

Menguji penyiapan HAProxy

Di komputer yang dilengkapi browser dan konektivitas jaringan ke node HAProxy, buka alamat berikut: http://haproxy:7000. Atau, Anda dapat menggunakan alamat IP eksternal instance HAProxy, bukan nama hostnya.

Anda akan melihat sesuatu yang mirip dengan screenshot berikut.

Gambar 1. Halaman status HAProxy yang menampilkan status respons dan latensi node Patroni.

Di dasbor HAProxy, Anda dapat melihat status respons dan latensi node Patroni utama, patroni1, dan dua replika, patroni2 dan patroni3.
Anda dapat menjalankan kueri untuk memeriksa statistik replikasi di cluster. Dari klien seperti pgAdmin, hubungkan ke server database utama Anda melalui HAProxy dan jalankan kueri berikut.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
Anda akan melihat sesuatu yang mirip dengan diagram berikut, yang menunjukkan bahwa patroni2 dan patroni3 melakukan streaming dari patroni1.

Gambar 2. Output pg_stat_replication yang menampilkan status replikasi node Patroni.

Menguji failover otomatis

Di bagian ini, dalam cluster tiga node Anda, kami menyimulasikan pemadaman layanan pada node utama dengan menghentikan penampung Patroni yang berjalan dan terpasang. Anda dapat menghentikan layanan Patroni di node utama untuk menyimulasikan pemadaman layanan atau menerapkan beberapa aturan firewall untuk menghentikan komunikasi ke node tersebut.

Di instance Patroni utama, buka folder Patroni AlloyDB Omni.
```
cd /alloydb/
```
Hentikan penampung.
```
docker compose down
```
Anda akan melihat sesuatu yang mirip dengan output berikut. Tindakan ini akan memvalidasi bahwa penampung dan jaringan telah dihentikan.
```
[+] Running 2/2
✔ Container alloydb-patroni            Removed
✔ Network alloydbomni-patroni_default  Removed
```
Muat ulang dasbor HAProxy dan lihat bagaimana failover terjadi.

Gambar 3. Dasbor HAProxy yang menampilkan failover dari node utama ke node standby.

Instance patroni3 menjadi instance utama baru, dan patroni2 adalah satu-satunya replika yang tersisa. Primary sebelumnya, patroni1, tidak aktif dan pemeriksaan statusnya gagal.

Patroni melakukan dan mengelola failover melalui kombinasi pemantauan, konsensus, dan orkestrasi otomatis. Segera setelah node utama gagal memperpanjang sewanya dalam waktu tunggu yang ditentukan, atau jika node melaporkan kegagalan, node lain dalam cluster akan mengenali kondisi ini melalui sistem konsensus. Node yang tersisa akan berkoordinasi untuk memilih replika yang paling sesuai untuk dipromosikan sebagai node utama baru. Setelah replika kandidat dipilih, Patroni akan mempromosikan node ini ke utama dengan menerapkan perubahan yang diperlukan, seperti memperbarui konfigurasi PostgreSQL dan memutar ulang data WAL yang belum selesai. Kemudian, node utama baru akan memperbarui sistem konsensus dengan statusnya dan replika lainnya akan mengonfigurasi ulang dirinya sendiri untuk mengikuti node utama baru, termasuk mengalihkan sumber replikasinya dan berpotensi melakukan transaksi baru. HAProxy mendeteksi primary baru dan mengarahkan ulang koneksi klien, sehingga gangguan minimal.
Dari klien seperti pgAdmin, hubungkan ke server database melalui HAProxy dan periksa statistik replikasi di cluster Anda setelah failover.
```
SELECT
      pid, usename, application_name, client_addr, state, sync_state
FROM
      pg_stat_replication;
```
Anda akan melihat sesuatu yang mirip dengan diagram berikut, yang menunjukkan bahwa hanya patroni2 yang sedang melakukan streaming sekarang.

Gambar 4. Output pg_stat_replication yang menampilkan status replikasi node Patroni setelah failover.
Cluster tiga node Anda dapat bertahan dari satu pemadaman lagi. Jika Anda menghentikan node utama saat ini, patroni3, failover lain akan terjadi.

Gambar 5. Dasbor HAProxy yang menampilkan failover dari node utama, patroni3, ke node standby, patroni2.

Pertimbangan penggantian

Penggantian adalah proses untuk mengaktifkan kembali node sumber sebelumnya setelah terjadi failover. Fallback otomatis umumnya tidak direkomendasikan di cluster database ketersediaan tinggi karena beberapa masalah penting, seperti pemulihan yang tidak lengkap, risiko skenario split-brain, dan keterlambatan replikasi.

Di cluster Patroni, jika Anda mengaktifkan dua node yang digunakan untuk menyimulasikan penghentian layanan, node tersebut akan bergabung kembali ke cluster sebagai replika standby.

Dasbor HAProxy yang menampilkan pemulihan `patroni1` dan `patroni3` sebagai node standby

Gambar 6. Dasbor HAProxy yang menampilkan pemulihan patroni1 dan patroni3 sebagai node standby.

Sekarang patroni1 dan patroni3 mereplikasi dari patroni2 primer saat ini.

Output pg_stat_replication yang menampilkan status replikasi node Patroni setelah penggantian

Gambar 7. Output pg_stat_replication yang menampilkan status replikasi node Patroni setelah penggantian.

Jika ingin kembali ke primary awal secara manual, Anda dapat melakukannya dengan menggunakan antarmuka command line patronictl. Dengan memilih penggantian manual, Anda dapat memastikan proses pemulihan yang lebih andal, konsisten, dan diverifikasi secara menyeluruh, sehingga mempertahankan integritas dan ketersediaan sistem database Anda.