Kluster Failover PostgreSQL + Patroni. Pengalaman implementasine

Ing artikel aku bakal pitutur marang kowe carane kita nyedhaki masalah PostgreSQL toleransi fault, kok dadi penting kanggo kita lan apa kedaden ing pungkasan.

Kita duwe layanan sing akeh banget: 2,5 yuta pangguna ing saindenging jagad, 50K+ pangguna aktif saben dina. Server kasebut ana ing Amazone ing salah sawijining wilayah Irlandia: 100+ server sing beda-beda terus digunakake, sing meh 50 karo database.

Kabeh backend minangka aplikasi Java stateful monolithic gedhe sing tetep sambungan websocket pancet karo klien. Nalika sawetara pangguna kerja ing papan sing padha ing wektu sing padha, kabeh padha ndeleng owah-owahan ing wektu nyata, amarga kita nulis saben owah-owahan ing database. Kita duwe udakara 10K panjaluk saben detik menyang database kita. Ing beban puncak ing Redis, kita nulis 80-100K panjalukan saben detik.

Napa kita ngalih saka Redis menyang PostgreSQL

Kaping pisanan, layanan kita makarya karo Redis, toko kunci-nilai sing nyimpen kabeh data ing RAM server.

Pros saka Redis:

1. Kacepetan respon dhuwur, amarga kabeh disimpen ing memori;
2. Gampang serep lan replikasi.

Cons saka Redis kanggo kita:

1. Ora ana transaksi nyata. Kita nyoba kanggo simulasi ing tingkat aplikasi kita. Sayange, iki ora mesthi bisa digunakake lan mbutuhake nulis kode sing rumit banget.
2. Jumlah data diwatesi kanthi jumlah memori. Nalika jumlah data mundhak, memori bakal tuwuh, lan, ing pungkasan, kita bakal mbukak karakteristik saka conto sing dipilih, sing ing AWS mbutuhake mungkasi layanan kanggo ngganti jinis conto.
3. Sampeyan perlu kanggo terus-terusan njaga tingkat latensi sing kurang, amarga. kita duwe nomer akeh banget panjalukan. Tingkat tundha optimal kanggo kita yaiku 17-20 ms. Ing tingkat 30-40 ms, kita entuk tanggapan sing dawa kanggo panjaluk saka aplikasi lan degradasi layanan kasebut. Sayange, iki kedadeyan ing wulan September 2018, nalika salah sawijining kedadeyan karo Redis kanggo sawetara sebab nampa latensi kaping 2 luwih saka biasane. Kanggo ngatasi masalah kasebut, kita mandhegake layanan ing tengah dina kanggo pangopènan sing ora dijadwal lan ngganti conto Redis sing ana masalah.
4. Iku gampang kanggo njaluk inconsistency data sanajan karo kasalahan cilik ing kode lan banjur nglampahi akèh sing wektu nulis kode kanggo mbenerake data iki.

We njupuk menyang akun cons lan temen maujud sing kita kudu pindhah menyang soko luwih trep, karo transaksi normal lan kurang katergantungan ing latensi. Nindakake riset, nganalisa akeh opsi lan milih PostgreSQL.

Kita wis pindhah menyang database anyar kanggo 1,5 taun wis lan wis dipindhah mung bagean cilik saka data, supaya saiki kita digunakake bebarengan karo Redis lan PostgreSQL. Informasi liyane babagan tahapan obah lan ngoper data antarane database ditulis ing artikel rekanku.

Nalika kita wiwit pindhah, aplikasi kita bisa langsung karo database lan ngakses master Redis lan PostgreSQL. Kluster PostgreSQL kalebu master lan replika kanthi replikasi asinkron. Iki kaya skema database:

Implementasi PgBouncer

Nalika kita obah, produk kasebut uga berkembang: jumlah pangguna lan jumlah server sing makarya karo PostgreSQL tambah, lan kita wiwit kekurangan sambungan. PostgreSQL nggawe proses kapisah kanggo saben sambungan lan nggunakake sumber daya. Sampeyan bisa nambah jumlah sambungan nganti titik tartamtu, yen ora ana kasempatan kanggo entuk kinerja database suboptimal. Pilihan becik ing kahanan kaya mengkono iku kanggo milih manager sambungan sing bakal ngadeg ing ngarepe basa.

Kita duwe rong pilihan kanggo manajer sambungan: Pgpool lan PgBouncer. Nanging sing pisanan ora ndhukung mode transaksional nggarap database, mula kita milih PgBouncer.

Kita wis nyiyapake skema kerja ing ngisor iki: aplikasi kita ngakses siji PgBouncer, ing mburi ana master PostgreSQL, lan ing mburi saben master ana siji replika kanthi replikasi asinkron.


Ing wektu sing padha, kita ora bisa nyimpen kabeh jumlah data ing PostgreSQL lan kacepetan nggarap database penting kanggo kita, mula kita miwiti sharding PostgreSQL ing tingkat aplikasi. Skema sing diterangake ing ndhuwur cukup trep kanggo iki: nalika nambahake serpihan PostgreSQL anyar, cukup nganyari konfigurasi PgBouncer lan aplikasi kasebut bisa langsung nggarap beling anyar.

PgBouncer failover

Skema iki makarya nganti saiki mung PgBouncer sing mati. Kita ana ing AWS, ing ngendi kabeh kedadeyan ing hardware sing mati sacara periodik. Ing kasus kaya mengkono, contone mung pindhah menyang hardware anyar lan bisa digunakake maneh. Iki kedadeyan karo PgBouncer, nanging ora kasedhiya. Asil musim gugur iki yaiku ora kasedhiya layanan kita sajrone 25 menit. AWS nyaranake nggunakake redundansi sisih pangguna kanggo kahanan kaya ngono, sing ora ditindakake ing negara kita nalika iku.

Sawise iku, kita mikir kanthi serius babagan toleransi kesalahan klompok PgBouncer lan PostgreSQL, amarga kahanan sing padha bisa kedadeyan ing akun AWS.

Kita mbangun skema toleransi kesalahan PgBouncer kaya ing ngisor iki: kabeh server aplikasi ngakses Network Load Balancer, ing mburine ana rong PgBouncer. Saben PgBouncer ndeleng master PostgreSQL sing padha ing saben beling. Yen kacilakan conto AWS kedadeyan maneh, kabeh lalu lintas dialihake liwat PgBouncer liyane. Network Load Balancer failover diwenehake dening AWS.

Skema iki nggawe gampang nambah server PgBouncer anyar.

Nggawe Kluster Failover PostgreSQL

Nalika ngatasi masalah iki, kita dianggep opsi beda: failover poto-ditulis, repmgr, AWS RDS, Patroni.

Skrip sing ditulis dhewe

Dheweke bisa ngawasi karya master lan, yen gagal, promosi replika menyang master lan nganyari konfigurasi PgBouncer.

Kauntungan saka pendekatan iki yaiku kesederhanaan maksimal, amarga sampeyan nulis skrip dhewe lan ngerti cara kerjane.

Cons:

• Master bisa uga ora mati, nanging bisa uga ana kegagalan jaringan. Failover, ora ngerti babagan iki, bakal ningkatake replika menyang master, nalika master lawas bakal terus kerja. Akibaté, kita bakal entuk rong server sing dadi master lan kita ora bakal ngerti sapa sing duwe data paling anyar. Kahanan iki uga disebut pamisah-otak;
• Kita ditinggal tanpa wangsulan. Ing konfigurasi kita, master lan siji replika, sawise ngoper, replika pindhah menyang master lan kita ora duwe replika maneh, supaya kita kudu nambah replika anyar kanthi manual;
• We kudu ngawasi tambahan saka operasi failover, nalika kita duwe 12 pecahan PostgreSQL, kang tegese kita kudu ngawasi 12 kluster. Kanthi Tambah ing jumlah shards, sampeyan uga kudu elinga nganyari failover.

Failover sing ditulis dhewe katon rumit banget lan mbutuhake dhukungan sing ora pati penting. Kanthi kluster PostgreSQL siji, iki bakal dadi pilihan sing paling gampang, nanging ora ukurane, mula ora cocog kanggo kita.

Repmgr

Manajer Replikasi kanggo kluster PostgreSQL, sing bisa ngatur operasi kluster PostgreSQL. Ing wektu sing padha, ora duwe failover otomatis metu saka kothak, supaya kanggo karya sampeyan kudu nulis "wrapper" dhewe ing ndhuwur solusi rampung. Dadi kabeh bisa dadi luwih rumit tinimbang karo skrip sing ditulis dhewe, mula kita ora nyoba Repmgr.

AWS RDS

Ndhukung kabeh sing perlu, ngerti carane nggawe serep lan njaga blumbang sambungan. Wis otomatis ngoper: nalika master mati, tiron dadi master anyar, lan AWS ngganti rekaman dns kanggo master anyar, nalika replika bisa dumunung ing AZ beda.

Kerugian kalebu kekurangan pangaturan sing apik. Minangka conto fine tuning: conto kita duwe watesan kanggo sambungan tcp, sing, sayangé, ora bisa ditindakake ing RDS:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Kajaba iku, AWS RDS meh kaping pindho luwih larang tinimbang rega conto biasa, sing dadi alasan utama kanggo ninggalake solusi iki.

Patroni

Iki minangka cithakan python kanggo ngatur PostgreSQL kanthi dokumentasi sing apik, failover otomatis lan kode sumber ing github.

Pros saka Patroni:

• Saben parameter konfigurasi diterangake, iku cetha cara kerjane;
• Failover otomatis dianggo metu saka kothak;
• Ditulis nganggo python, lan amarga kita dhewe nulis akeh ing python, bakal luwih gampang kanggo ngatasi masalah lan, mbok menawa, malah mbantu pangembangan proyek kasebut;
• Kanthi ngatur PostgreSQL, ngijini sampeyan kanggo ngganti konfigurasi ing kabeh kelenjar kluster bebarengan, lan yen kluster kudu diwiwiti maneh kanggo aplikasi konfigurasi anyar, iki bisa rampung maneh nggunakake Patroni.

Cons:

• Ora jelas saka dokumentasi babagan cara nggarap PgBouncer kanthi bener. Sanajan angel diarani minus, amarga tugas Patroni yaiku ngatur PostgreSQL, lan kepiye sambungan menyang Patroni wis dadi masalah;
• Ana sawetara conto implementasine saka Patroni ing volume gedhe, nalika ana akeh conto implementasine saka ngeruk.

Akibaté, kita milih Patroni kanggo nggawe kluster failover.

Proses Pelaksanaan Patroni

Sadurunge Patroni, kita duwe 12 pecahan PostgreSQL ing konfigurasi siji master lan siji replika kanthi replikasi asinkron. Server aplikasi ngakses database liwat Network Load Balancer, ing mburi ana rong kedadeyan karo PgBouncer, lan ing mburi kabeh ana server PostgreSQL.


Kanggo ngleksanakake Patroni, kita kudu milih konfigurasi cluster panyimpenan sing disebarake. Patroni dianggo karo sistem panyimpenan konfigurasi mbagekke kayata etcd, Zookeeper, Konsul. Kita mung duwe kluster Konsul lengkap ing pasar, sing dianggo bebarengan karo Vault lan kita ora nggunakake maneh. Alasan sing apik kanggo miwiti nggunakake Konsul kanggo tujuan sing dituju.

Carane Patroni dianggo karo Konsul

We duwe kluster Konsul, kang kasusun saka telung simpul, lan kluster Patroni, kang kasusun saka pimpinan lan tiron (ing Patroni, master disebut pimpinan kluster, lan babu disebut replika). Saben conto kluster Patroni terus-terusan ngirim informasi babagan kahanan kluster menyang Konsul. Mulane, saka Konsul sampeyan bisa tansah ngerteni konfigurasi saiki saka kluster Patroni lan sing pimpinan ing wayahe.

Kanggo nyambungake Patroni menyang Konsul, cukup sinau dokumentasi resmi, sing ujar manawa sampeyan kudu nemtokake host ing format http utawa https, gumantung saka cara kerjane karo Konsul, lan skema sambungan, kanthi opsional:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Iku katon prasaja, nanging ing kene pitfalls diwiwiti. Kanthi Konsul, kita nggarap sambungan sing aman liwat https lan konfigurasi sambungan bakal katon kaya iki:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Nanging ora bisa. Nalika wiwitan, Patroni ora bisa nyambung menyang Konsul, amarga nyoba liwat http.

Kode sumber Patroni mbantu ngatasi masalah kasebut. Untunge ditulis nganggo python. Pranyata parameter host ora diurai kanthi cara apa wae, lan protokol kasebut kudu ditemtokake ing skema. Mangkene carane blok konfigurasi sing digunakake kanggo nggarap Konsul katon kanggo kita:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

konsul-template

Dadi, kita wis milih panyimpenan kanggo konfigurasi. Saiki kita kudu ngerti carane PgBouncer bakal ngalih konfigurasi nalika ngganti pimpinan ing kluster Patroni. Ora ana jawaban kanggo pitakonan iki ing dokumentasi, amarga. ana, ing asas, karya karo PgBouncer ora diterangake.

Kanggo nggoleki solusi, kita nemokake artikel (aku ora ngelingi judhul) sing ditulis yen Сonsul-template mbantu akeh ing pasangan PgBouncer lan Patroni. Iki nyebabake kita nyelidiki cara kerja template Konsul.

Ternyata Consul-template terus-terusan ngawasi konfigurasi kluster PostgreSQL ing Konsul. Nalika pimpinan ngganti, nganyari konfigurasi PgBouncer lan ngirim printah kanggo reload.

A plus amba saka cithakan iku disimpen minangka kode, supaya nalika nambah shard anyar, iku cukup kanggo nggawe anyar tundhuk lan nganyari cithakan otomatis, ndhukung Infrastruktur minangka prinsip kode.

Arsitektur anyar karo Patroni

Akibaté, kita entuk skema kerja ing ngisor iki:


Kabeh server aplikasi ngakses balancer → ana rong kedadean saka PgBouncer konco → ing saben conto, Consul-template dibukak, kang ngawasi status saben kluster Patroni lan ngawasi relevansi saka config PgBouncer, kang ngirim panjalukan kanggo pimpinan saiki. saka saben klaster.

Tes manual

Kita nglakokake skema iki sadurunge diluncurake ing lingkungan tes cilik lan mriksa operasi ngoper otomatis. Dheweke mbukak papan, mindhah stiker, lan ing wektu kasebut "mateni" pimpinan kluster. Ing AWS, iki gampang kaya mateni conto liwat konsol.

Stiker bali maneh ing 10-20 detik, lan banjur maneh wiwit pindhah normal. Iki tegese kluster Patroni makarya kanthi bener: ngganti pimpinan, ngirim informasi menyang Сonsul, lan Сonsul-template langsung njupuk informasi iki, ngganti konfigurasi PgBouncer lan ngirim printah kanggo reload.

Kepiye carane bisa urip ing beban sing dhuwur lan njaga downtime minimal?

Kabeh dianggo sampurna! Nanging ana pitakonan anyar: Kepiye cara kerjane ing beban dhuwur? Carane cepet lan aman muter kabeh ing produksi?

Lingkungan tes ing ngendi kita nganakake tes beban mbantu kita mangsuli pitakon pisanan. Iki meh padha karo produksi babagan arsitektur lan wis ngasilake data tes sing kira-kira padha karo volume produksi. Kita mutusake mung "mateni" salah sawijining master PostgreSQL sajrone tes lan ndeleng apa sing kedadeyan. Nanging sadurunge iku, penting kanggo mriksa rolling otomatis, amarga ing lingkungan iki kita duwe sawetara pecahan PostgreSQL, supaya kita bakal njaluk testing banget saka skrip konfigurasi sadurunge produksi.

Loro-lorone tugas katon ambisius, nanging kita duwe PostgreSQL 9.6. Apa kita bisa langsung nganyarke menyang 11.2?

Kita mutusake kanggo nindakake ing 2 langkah: upgrade pisanan menyang 11.2, banjur miwiti Patroni.

Nganyari PostgreSQL

Kanggo nganyari versi PostgreSQL kanthi cepet, gunakake pilihan kasebut -k, ing ngendi pranala hard digawe ing disk lan ora perlu nyalin data sampeyan. Ing basis saka 300-400 GB, nganyari njupuk 1 detik.

Kita duwe akeh pecahan, mula nganyari kudu ditindakake kanthi otomatis. Kanggo nindakake iki, kita nulis playbook Ansible sing nangani kabeh proses nganyari kanggo kita:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

Penting kanggo dicathet yen sadurunge miwiti upgrade, sampeyan kudu nindakake kanthi parameter kasebut --mriksokanggo mesthekake yen sampeyan bisa nganyarke. Skrip kita uga nggawe panggantos konfigurasi kanggo durasi upgrade. Skrip kita rampung ing 30 detik, sing minangka asil sing apik banget.

Bukak Patroni

Kanggo ngatasi masalah kapindho, mung katon ing konfigurasi Patroni. Repositori resmi duwe conto konfigurasi karo initdb, sing tanggung jawab kanggo miwiti database anyar nalika sampeyan miwiti Patroni. Nanging amarga kita wis duwe database siap-digawe, kita mung mbusak bagean iki saka konfigurasi.

Nalika kita miwiti nginstal Patroni ing kluster PostgreSQL sing wis ana lan mlaku, kita nemoni masalah anyar: loro server kasebut diwiwiti minangka pimpinan. Patroni ngerti apa-apa bab negara awal kluster lan nyoba kanggo miwiti loro server minangka loro klompok kapisah karo jeneng sing padha. Kanggo ngatasi masalah iki, sampeyan kudu mbusak direktori kanthi data ing budak:

rm -rf /var/lib/postgresql/

Iki kudu rampung mung ing babu!

Nalika tiron resik disambungake, ndadekake Patroni pimpinan basebackup lan mulihake menyang tiron, lan banjur nyekel munggah karo negara saiki miturut wal log.

Kesulitan liyane sing kita alami yaiku kabeh kluster PostgreSQL dijenengi utama kanthi standar. Nalika saben kluster ora ngerti apa-apa bab liyane, iki normal. Nanging yen sampeyan pengin nggunakake Patroni, kabeh klompok kudu duwe jeneng unik. Solusi kanggo ngganti jeneng kluster ing konfigurasi PostgreSQL.

tes beban

Kita wis ngluncurake tes sing simulasi pengalaman pangguna ing papan. Nalika beban tekan nilai rata-rata saben dina, kita mbaleni persis tes sing padha, kita mateni siji conto karo pimpinan PostgreSQL. Failover otomatis makarya minangka kita samesthine: Patroni diganti pimpinan, Konsul-Cithakan nganyari konfigurasi PgBouncer lan dikirim printah kanggo reload. Miturut grafik ing Grafana, jelas yen ana wektu tundha 20-30 detik lan sawetara kesalahan saka server sing ana gandhengane karo sambungan menyang database. Iki minangka kahanan sing normal, nilai kasebut bisa ditampa kanggo failover kita lan mesthi luwih apik tinimbang downtime layanan.

Nggawa Patroni menyang produksi

Akibaté, kita nggawe rencana ing ngisor iki:

• Nyebarake Consul-template menyang server PgBouncer lan diluncurake;
• Nganyari PostgreSQL menyang versi 11.2;
• Ngganti jeneng kluster;
• Miwiti Cluster Patroni.

Ing wektu sing padha, rencana kita ngidini kita nggawe titik pisanan meh sawayah-wayah, kita bisa mbusak saben PgBouncer saka karya ing siji lan masang lan mbukak consul-template ing. Dadi kita nindakake.

Kanggo penyebaran cepet, kita nggunakake Ansible, amarga kita wis nyoba kabeh playbooks ing lingkungan test, lan wektu eksekusi script lengkap saka 1,5 kanggo 2 menit kanggo saben shard. Kita bisa muter kabeh ing saben beling tanpa mungkasi layanan kita, nanging kita kudu mateni saben PostgreSQL kanggo sawetara menit. Ing kasus iki, pangguna sing data ana ing shard iki ora bisa digunakake kanthi lengkap, lan iki ora bisa ditampa kanggo kita.

Cara metu saka kahanan iki yaiku pangopènan sing direncanakake, sing ditindakake saben 3 wulan. Iki minangka jendhela kanggo karya sing dijadwalake, nalika kita mateni layanan lan nganyarke database. Ana siji minggu kiwa nganti jendhela sabanjuré, lan kita mutusaké kanggo mung ngenteni lan nyiapake luwih. Sajrone wektu nunggu, kita uga ngamanake awake dhewe: kanggo saben beling PostgreSQL, kita ngunggahake replika cadangan yen gagal nyimpen data paling anyar, lan nambahake conto anyar kanggo saben beling, sing kudu dadi replika anyar ing kluster Patroni, supaya ora nindakake prentah mbusak data. Kabeh iki mbantu nyuda resiko kesalahan.


Kita miwiti maneh layanan, kabeh bisa digunakake kaya sing dikarepake, pangguna terus kerja, nanging ing grafik kasebut, ana beban sing ora normal ing server Konsul.


Napa kita ora weruh iki ing lingkungan tes? Masalah iki nggambarake kanthi apik yen kudu ngetutake Infrastruktur minangka prinsip kode lan nyaring kabeh infrastruktur, saka lingkungan tes nganti produksi. Yen ora, iku gampang banget kanggo njaluk masalah kita entuk. Ana apa? Konsul pisanan muncul ing produksi, lan banjur ing lingkungan test, minangka asil, ing lingkungan test, versi Konsul luwih dhuwur tinimbang ing produksi. Mung ing salah sawijining rilis, bocor CPU ditanggulangi nalika nggarap template konsul. Mulane, kita mung nganyari Konsul, saéngga ngrampungake masalah kasebut.

Wiwiti maneh kluster Patroni

Nanging, kita entuk masalah anyar, sing ora disangka. Nalika nganyari Konsul, kita mung mbusak simpul Konsul saka kluster nggunakake printah ninggalake konsul → Patroni nyambung menyang server Konsul liyane → kabeh dianggo. Nanging nalika kita tekan conto pungkasan saka kluster Konsul lan ngirim printah cuti konsul, kabeh kluster Patroni mung diwiwiti maneh, lan ing log kita weruh kesalahan ing ngisor iki:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Kluster Patroni ora bisa njupuk informasi babagan kluster lan diwiwiti maneh.

Kanggo nemokake solusi, kita hubungi penulis Patroni liwat masalah ing github. Dheweke menehi saran perbaikan kanggo file konfigurasi:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Kita bisa nurun masalah ing lingkungan test lan dites opsi iki ana, nanging sayangé padha ora bisa.

Masalahe isih durung rampung. Kita rencana kanggo nyoba solusi ing ngisor iki:

• Gunakake Konsul-agen ing saben Kayata cluster Patroni;
• Ndandani masalah ing kode.

Kita mangertos ing ngendi kesalahan kasebut: masalah kasebut mbokmenawa nggunakake wektu entek standar, sing ora ditindhes liwat file konfigurasi. Nalika server Konsul pungkasan dibusak saka kluster, kabeh kluster Konsul macet luwih saka detik, amarga iki, Patroni ora bisa njaluk status kluster lan rampung maneh kabeh kluster.

Untunge, kita ora nemoni kesalahan maneh.

Asil nggunakake Patroni

Sawise sukses sukses Patroni, kita nambah replika tambahan ing saben kluster. Saiki ing saben kluster ana semblance saka kuorum: siji pimpinan lan loro replika, kanggo safety net ing cilik saka pamisah-otak nalika ngoper.


Patroni wis nggarap produksi luwih saka telung sasi. Sajrone wektu iki, dheweke wis bisa nulungi kita. Bubar, pimpinan salah sawijining kluster mati ing AWS, failover otomatis bisa digunakake lan pangguna terus kerja. Patroni ngrampungake tugas utama.

Ringkesan cilik babagan panggunaan Patroni:

• Ease saka owah-owahan konfigurasi. Cukup kanggo ngganti konfigurasi ing siji conto lan bakal ditarik nganti kabeh kluster. Yen urip maneh dibutuhake kanggo ngetrapake konfigurasi anyar, banjur Patroni bakal ngandhani sampeyan. Patroni bisa miwiti maneh kabeh kluster kanthi printah siji, sing uga trep banget.
• Failover otomatis bisa digunakake lan wis bisa nulungi kita.
• Nganyari PostgreSQL tanpa downtime aplikasi. Sampeyan kudu nganyari replika kanggo versi anyar, banjur ngganti pimpinan ing kluster Patroni lan nganyari pimpinan lawas. Ing kasus iki, tes sing dibutuhake saka failover otomatis ditindakake.

Source: www.habr.com