Dina tulisan kuring bakal nyarioskeun ka anjeun kumaha urang ngadeukeutan masalah kasabaran kasalahan PostgreSQL, naha éta janten penting pikeun urang sareng naon anu kajantenan dina tungtungna.
Kami ngagaduhan jasa anu sarat pisan: 2,5 juta pangguna sadunya, 50K+ pangguna aktip unggal dinten. Serverna aya di Amazone di hiji daérah Irlandia: 100+ server anu béda-béda terus beroperasi, anu ampir 50 nganggo database.
Sakabéh backend mangrupakeun aplikasi Java stateful monolithic badag nu ngajaga sambungan websocket konstan kalawan klien nu. Nalika sababaraha pangguna dianggo dina papan anu sami dina waktos anu sami, aranjeunna sadayana ningali parobihan sacara real waktos, sabab kami nyerat unggal parobihan kana pangkalan data. Simkuring gaduh ngeunaan 10K requests per detik ka database urang. Dina beban puncak di Redis, urang nyerat 80-100K pamundut per detik.
Naha urang ngalih ti Redis ka PostgreSQL
Mimitina, jasa kami damel sareng Redis, toko nilai konci anu nyimpen sadaya data dina RAM server.
Keunggulan Redis:
- speed respon tinggi, sabab sagalana disimpen dina mémori;
- Gampang cadangan sareng réplikasi.
Kontra Redis pikeun urang:
- Henteu aya transaksi nyata. Urang nyoba simulate aranjeunna dina tingkat aplikasi urang. Hanjakal, ieu teu salawasna dianggo ogé sarta diperlukeun nulis kode pisan kompléks.
- Jumlah data diwatesan ku jumlah memori. Nalika jumlah data nambahan, mémori bakal ningkat, sareng, dina tungtungna, urang bakal ngajalankeun kana karakteristik conto anu dipilih, anu dina AWS meryogikeun ngeureunkeun jasa kami pikeun ngarobih jinis conto.
- Ieu diperlukeun pikeun terus ngajaga tingkat latency low, sabab. urang boga angka pisan badag tina requests. Tingkat reureuh optimal pikeun urang nyaéta 17-20 mdet. Dina tingkat 30-40 mdet, kami nampi réspon anu panjang pikeun pamundut ti aplikasi kami sareng degradasi jasa. Hanjakalna, ieu kajantenan ka urang dina Séptémber 2018, nalika salah sahiji instansi sareng Redis pikeun sababaraha alesan nampi latency 2 kali langkung seueur tibatan biasana. Pikeun ngabéréskeun masalah éta, kami ngeureunkeun jasa tengah dinten pikeun pangropéa anu teu dijadwalkeun sareng ngagentos conto Redis anu bermasalah.
- Ieu gampang pikeun meunangkeun inconsistency data sanajan kalawan kasalahan minor dina kode lajeng méakkeun loba waktu nulis kode pikeun ngabenerkeun data ieu.
Urang tumut kana akun kontra jeung sadar yen urang kudu pindah ka hal leuwih merenah, kalawan transaksi normal sarta kirang gumantungna on latency. Ngalaksanakeun panalungtikan, nganalisis seueur pilihan sareng milih PostgreSQL.
Kami parantos ngalih ka database énggal salami 1,5 taun sareng parantos ngalihkeun sabagian leutik data, janten ayeuna urang damel sakaligus sareng Redis sareng PostgreSQL. Langkung seueur inpormasi ngeunaan tahapan mindahkeun sareng ngalihkeun data antara pangkalan data ditulis dina .
Nalika urang mimiti pindah, aplikasi urang damel langsung sareng pangkalan data sareng ngaksés master Redis sareng PostgreSQL. Kluster PostgreSQL diwangun ku master sareng réplika kalayan réplikasi asinkron. Ieu kumaha skéma database sapertos kieu:
Ngalaksanakeun PgBouncer
Nalika kami ngalih, produk ogé ngembang: jumlah pangguna sareng jumlah server anu damel sareng PostgreSQL ningkat, sareng urang mimiti kakurangan sambungan. PostgreSQL nyiptakeun prosés anu misah pikeun unggal sambungan sareng ngabutuhkeun sumber daya. Anjeun tiasa ningkatkeun jumlah sambungan nepi ka titik nu tangtu, disebutkeun aya kasempetan pikeun meunangkeun kinerja database suboptimal. Pilihan anu idéal dina kaayaan sapertos kitu nyaéta milih manajer sambungan anu bakal nangtung di payuneun dasarna.
Kami ngagaduhan dua pilihan pikeun manajer sambungan: Pgpool sareng PgBouncer. Tapi anu kahiji henteu ngadukung modeu transaksional damel sareng pangkalan data, janten kami milih PgBouncer.
Kami parantos nyetél skéma padamelan di handap ieu: aplikasi kami ngaksés hiji PgBouncer, tukangeunna aya master PostgreSQL, sareng di tukangeun unggal master aya hiji réplika sareng réplikasi asinkron.
Dina waktu nu sarua, urang teu bisa nyimpen sakabéh jumlah data dina PostgreSQL jeung speed gawé bareng database éta penting pikeun kami, jadi urang mimitian sharding PostgreSQL di tingkat aplikasi. Skéma anu ditétélakeun di luhur rélatif merenah pikeun ieu: nalika nambahkeun beling PostgreSQL anyar, cukup pikeun ngapdet konfigurasi PgBouncer sareng aplikasina tiasa langsung dianggo sareng beling énggal.
PgBouncer failover
Skéma ieu jalan dugi ka momen nalika hiji-hijina conto PgBouncer maot. Kami di AWS, dimana sadaya instansi dijalankeun dina hardware anu maot sacara périodik. Dina kasus sapertos kitu, conto ngan ukur ngalih ka hardware énggal sareng tiasa dianggo deui. Ieu lumangsung kalawan PgBouncer, tapi janten sadia. Hasil tina ragrag ieu nya éta unavailability tina jasa kami pikeun 25 menit. AWS nyarankeun ngagunakeun redundansi sisi-pamaké pikeun kaayaan sapertos kitu, anu henteu dilaksanakeun di nagara urang dina waktos éta.
Saatos éta, kami sacara serius panginten ngeunaan kasabaran kasalahan tina klaster PgBouncer sareng PostgreSQL, sabab kaayaan anu sami tiasa kajantenan sareng conto naon waé dina akun AWS kami.
Kami ngawangun skéma kasabaran kasalahan PgBouncer sapertos kieu: sadaya server aplikasi ngakses Network Load Balancer, anu aya di tukangeun dua PgBouncers. Unggal PgBouncer ningali master PostgreSQL anu sami dina unggal beling. Upami kacilakaan AWS kajantenan deui, sadaya lalu lintas dialihkeun ngalangkungan PgBouncer anu sanés. Network Load Balancer failover disadiakeun ku AWS.
Skéma ieu ngagampangkeun pikeun nambihan server PgBouncer énggal.
Jieun Kluster Failover PostgreSQL
Nalika ngarengsekeun masalah ieu, urang dianggap pilihan béda: failover timer ditulis, repmgr, AWS RDS, Patroni.
Skrip tulisan sorangan
Aranjeunna tiasa ngawas karya master sareng, upami gagal, promosikeun réplika ka master sareng ngapdet konfigurasi PgBouncer.
Kaunggulan tina pendekatan ieu kesederhanaan maksimum, sabab nulis Aksara sorangan tur ngartos persis kumaha aranjeunna jalan.
kontra:
- Master panginten henteu maot, tibatan gagal jaringan tiasa kajantenan. Failover, teu sadar ieu, bakal ngamajukeun replika ka master, sedengkeun master heubeul bakal neruskeun jalan. Hasilna, urang bakal nampi dua server dina peran master sareng urang moal terang mana di antarana anu gaduh data pangénggalna. kaayaan ieu disebut ogé pamisah-otak;
- Kami ditinggalkeun tanpa respon. Dina konfigurasi urang, master na hiji replica, sanggeus switching, replica nu ngalir nepi ka master sarta kami euweuh boga réplika, jadi urang kudu sacara manual nambahkeun réplika anyar;
- Urang kudu ngawas tambahan tina operasi failover, bari urang boga 12 beling PostgreSQL, nu hartina urang kudu ngawas 12 klaster. Kalayan paningkatan dina jumlah beling, anjeun ogé kedah émut pikeun ngapdet failover.
Failover anu ditulis sorangan katingalina rumit pisan sareng ngabutuhkeun dukungan anu teu penting. Kalayan klaster PostgreSQL tunggal, ieu bakal janten pilihan panggampangna, tapi henteu skala, janten henteu cocog pikeun urang.
Repmgr
Manajer réplikasi pikeun klaster PostgreSQL, anu tiasa ngatur operasi klaster PostgreSQL. Dina waktos anu sami, éta henteu ngagaduhan failover otomatis tina kotak, janten pikeun damel anjeun kedah nyerat "wrapper" anjeun nyalira dina luhureun solusi anu réngsé. Janten sadayana tiasa janten langkung rumit tibatan naskah anu ditulis nyalira, janten kami henteu nyobian Repmgr.
AWS RDS
Ngarojong sadayana anu urang peryogikeun, terang kumaha ngadamel cadangan sareng ngajaga kolam renang sambungan. Cai mibanda switching otomatis: lamun master maot, replica nu jadi master anyar, sarta AWS robah rékaman dns ka master anyar, bari réplika bisa lokasina di AZs béda.
Kakurangan kalebet kurangna panyesuaian anu saé. Salaku conto fine tuning: instansi kami boga larangan pikeun sambungan tcp, nu, hanjakalna, teu bisa dipigawé di RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Salaku tambahan, AWS RDS ampir dua kali langkung mahal tibatan harga conto biasa, anu mangrupikeun alesan utama pikeun ngantunkeun solusi ieu.
Patroni
Ieu mangrupikeun template python pikeun ngatur PostgreSQL kalayan dokuméntasi anu saé, failover otomatis sareng kode sumber dina github.
Keunggulan Patroni:
- Unggal parameter konfigurasi digambarkeun, éta jelas kumaha gawéna;
- Failover otomatis jalan kaluar tina kotak;
- Ditulis dina python, sarta saprak urang sorangan nulis loba di python, eta bakal leuwih gampang pikeun urang nungkulan masalah na, meureun, malah mantuan ngembangkeun proyék;
- Pinuh ngatur PostgreSQL, ngamungkinkeun anjeun ngarobih konfigurasi dina sadaya titik kluster sakaligus, sareng upami kluster kedah di-restart pikeun nerapkeun konfigurasi énggal, maka ieu tiasa dilakukeun deui nganggo Patroni.
kontra:
- Henteu écés tina dokuméntasi kumaha cara damel sareng PgBouncer kalayan leres. Sanaos sesah nyebatna dikurangan, sabab tugas Patroni nyaéta ngatur PostgreSQL, sareng kumaha sambungan ka Patroni bakal janten masalah urang;
- Aya sababaraha conto palaksanaan Patroni on volume badag, bari aya loba conto palaksanaan ti scratch.
Hasilna, urang milih Patroni pikeun nyieun klaster failover.
Prosés Palaksanaan Patroni
Sateuacan Patroni, urang ngagaduhan 12 PostgreSQL shards dina konfigurasi hiji master sareng hiji réplika sareng réplikasi asinkron. Pangladén aplikasi ngaksés pangkalan data ngaliwatan Network Load Balancer, di tukangeunana aya dua instansi sareng PgBouncer, sareng di tukangeun éta sadayana server PostgreSQL.
Pikeun ngalaksanakeun Patroni, urang kedah milih konfigurasi klaster gudang anu disebarkeun. Patroni jalan kalawan sistem gudang konfigurasi disebarkeun kayaning etcd, Zookeeper, Konsul. Urang ngan boga klaster Konsul full-fledged dina pasaran, nu gawéna ditéang jeung Kolong jeung urang teu make eta deui. Alesan anu hadé pikeun ngamimitian nganggo Konsul pikeun tujuan anu dimaksud.
Kumaha Patroni damel sareng Konsul
Simkuring boga klaster Konsul, nu diwangun ku tilu titik, sarta klaster Patroni, nu diwangun ku pamingpin jeung réplika (dina Patroni, master disebut pamingpin klaster, jeung budak disebut réplika). Unggal conto tina klaster Patroni terus ngirimkeun informasi ngeunaan kaayaan klaster ka Konsul. Ku alatan éta, ti Konsul anjeun salawasna bisa manggihan konfigurasi ayeuna tina klaster Patroni jeung saha pamimpin di momen.
Pikeun nyambungkeun Patroni ka Konsul, cukup pikeun diajar dokuméntasi resmi, nu nyebutkeun yén anjeun kudu nangtukeun host dina format http atawa HTTPS, gumantung kana kumaha urang gawé bareng Konsul, sarta skéma sambungan, optionally:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpSigana basajan, tapi di dieu pitfalls dimimitian. Kalayan Konsul, kami damel sambungan anu aman via https sareng konfigurasi sambungan kami bakal sapertos kieu:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Tapi éta henteu jalan. Dina ngamimitian, Patroni teu bisa nyambung ka Konsul, sabab nyoba ngaliwatan http atoh.
Kodeu sumber Patroni ngabantosan masalah éta. Hal alus éta ditulis dina python. Tétéla yén parameter host teu parsed sagala cara, sarta protokol kudu dieusian dina skéma. Ieu kumaha blok konfigurasi anu dianggo pikeun damel sareng Konsul katingalina pikeun urang:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul-témplat
Janten, kami parantos milih panyimpenan pikeun konfigurasi. Ayeuna urang kudu ngarti kumaha PgBouncer bakal pindah konfigurasi na nalika ngarobah pamimpin di klaster Patroni. Henteu aya jawaban kana patarosan ieu dina dokuméntasi, sabab. aya, prinsipna mah, gawé bareng PgBouncer teu digambarkeun.
Dina pilarian sahiji solusi, urang kapanggih hiji artikel (Kuring hanjakalna teu apal judulna) dimana ieu ditulis yén Сonsul-témplat mantuan pisan dina pasangan PgBouncer na Patroni. Ieu ngajurung urang pikeun nalungtik kumaha Consul-template jalanna.
Tétéla yén Consul-template terus ngawas konfigurasi tina klaster PostgreSQL di Konsul. Nalika pamimpin robah, ngamutahirkeun konfigurasi PgBouncer sarta ngirimkeun paréntah pikeun ngamuat deui.
A tambah badag tina template téh nya éta disimpen salaku kode, jadi lamun nambahkeun beling anyar, éta cukup pikeun nyieun komitmen anyar jeung ngamutahirkeun template otomatis, ngarojong Infrastruktur salaku prinsip kode.
Arsitéktur anyar sareng Patroni
Hasilna, urang ngagaduhan skéma padamelan di handap ieu:
Sadaya server aplikasi ngakses balancer nu → aya dua instansi PgBouncer tukangeun eta → dina unggal conto, Konsul-template dibuka, nu ngawas status unggal klaster Patroni jeung monitor relevansi tina config PgBouncer, nu ngirim requests ka pamingpin ayeuna. unggal klaster.
Tés manual
Kami ngajalankeun skéma ieu sateuacan ngaluncurkeunana dina lingkungan tés leutik sareng pariksa operasi switching otomatis. Aranjeunna muka dewan, mindahkeun stiker, sarta dina momen anu aranjeunna "maéhan" pamimpin klaster. Dina AWS, ieu saderhana sapertos mareuman conto liwat konsol.
Stiker balik deui dina 10-20 detik, lajeng deui mimiti mindahkeun normal. Ieu ngandung harti yén klaster Patroni digawé neuleu: eta robah pamimpin, dikirim informasi ka Сonsul, sarta Сonsul-template geuwat ngangkat informasi ieu, ngaganti konfigurasi PgBouncer sarta ngirimkeun paréntah pikeun ngamuat ulang.
Kumaha salamet dina beban anu luhur sareng ngajaga downtime minimal?
Sagalana jalan sampurna! Tapi aya patarosan anyar: Kumaha éta tiasa dianggo dina beban anu luhur? Kumaha gancang tur aman gulung kaluar sagalana dina produksi?
Lingkungan tés dimana urang ngalaksanakeun tés beban ngabantosan urang ngajawab patarosan anu munggaran. Éta sami sareng produksi dina hal arsitéktur sareng parantos ngahasilkeun data tés anu kirang langkung sami sareng volume produksi. Kami mutuskeun ngan "maéhan" salah sahiji master PostgreSQL salami tés sareng ningali naon anu lumangsung. Tapi saméméh éta, hal anu penting pikeun pariksa rolling otomatis, sabab dina lingkungan ieu kami boga sababaraha shards PostgreSQL, jadi urang bakal meunang nguji alus teuing tina Aksara konfigurasi saméméh produksi.
Duanana tugas katingali ambisius, tapi urang gaduh PostgreSQL 9.6. Naha urang tiasa langsung ningkatkeun ka 11.2?
Urang mutuskeun pikeun ngalakukeunana dina 2 léngkah: mimiti ningkatkeun ka 11.2, teras ngajalankeun Patroni.
Pembaruan PostgreSQL
Pikeun gancang ngapdet versi PostgreSQL, paké pilihan -k, dimana tautan keras didamel dina disk sareng henteu kedah nyalin data anjeun. Dina dasar 300-400 GB, updatena butuh 1 detik.
Kami ngagaduhan seueur beling, janten pembaruan kedah dilakukeun sacara otomatis. Jang ngalampahkeun ieu, urang nulis hiji playbook Ansible nu handles sakabéh prosés update pikeun urang:
/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 pikeun dicatet di dieu yén sateuacan ngamimitian pamutahiran, anjeun kedah ngalaksanakeunana sareng parameter --cekpikeun mastikeun Anjeun tiasa ningkatkeun. Aksara urang ogé ngajadikeun substitusi of configs pikeun durasi pamutahiran éta. Skrip kami réngsé dina 30 detik, anu mangrupikeun hasil anu saé.
Ngajalankeun Patroni
Pikeun ngajawab masalah kadua, ngan kasampak dina konfigurasi Patroni. Repository resmi ngagaduhan conto konfigurasi sareng initdb, anu tanggung jawab pikeun ngamimitian database énggal nalika anjeun mimiti ngamimitian Patroni. Tapi saprak urang geus boga database siap-dijieun, urang saukur dipiceun bagian ieu tina konfigurasi nu.
Nalika kami ngamimitian masang Patroni dina klaster PostgreSQL anu parantos aya sareng ngajalankeunana, kami ngagaduhan masalah énggal: duanana server dimimitian salaku pamimpin. Patroni teu terang nanaon ngeunaan kaayaan awal kluster sareng nyobian ngamimitian duanana server salaku dua klaster anu misah sareng nami anu sami. Pikeun ngabéréskeun masalah ieu, anjeun kedah ngahapus diréktori sareng data dina budak:
rm -rf /var/lib/postgresql/Ieu perlu dipigawé ngan dina budak!
Lamun replica bersih disambungkeun, ngajadikeun Patroni pamimpin basebackup na restores ka replica nu, lajeng nyekel up kalawan kaayaan ayeuna nurutkeun wal log.
Kasusah sanésna anu kami tepang nyaéta yén sadaya klaster PostgreSQL dingaranan utama sacara standar. Nalika unggal klaster terang nanaon ngeunaan séjén, ieu téh normal. Tapi nalika anjeun hoyong nganggo Patroni, maka sadaya klaster kedah gaduh nami anu unik. Solusina nyaéta ngarobih nami klaster dina konfigurasi PostgreSQL.
tés beban
Kami parantos ngaluncurkeun tés anu nyontokeun pangalaman pangguna dina papan. Nalika beban ngahontal nilai rata-rata poean urang, urang ngulang persis test sarua, urang mareuman hiji conto jeung pamimpin PostgreSQL. The failover otomatis digawé salaku urang diperkirakeun: Patroni robah pamimpin, Konsul-template diropéa konfigurasi PgBouncer sarta dikirim paréntah pikeun ngamuat ulang. Numutkeun kana grafik kami di Grafana, jelas yén aya telat 20-30 detik sareng sajumlah leutik kasalahan tina server anu aya hubunganana sareng sambungan kana pangkalan data. Ieu mangrupikeun kaayaan normal, nilai-nilai sapertos kitu tiasa ditampi pikeun failover urang sareng pasti langkung saé tibatan waktos jasa.
Bringing Patroni ka produksi
Hasilna, urang datang nepi ka rencana handap:
- Nyebarkeun Konsul-témplat ka server PgBouncer sareng peluncuran;
- Apdet PostgreSQL kana versi 11.2;
- Ganti ngaran klaster;
- Ngamimitian Kluster Patroni.
Dina waktu nu sarua, skéma kami ngamungkinkeun urang pikeun nyieun titik kahiji ampir iraha wae, urang tiasa miceun unggal PgBouncer tina karya dina gilirannana sarta nyebarkeun tur ngajalankeun konsul-template di dinya. Kitu we.
Pikeun panyebaran gancang, kami nganggo Ansible, sabab kami parantos nguji sadaya playbooks dina lingkungan uji, sareng waktos palaksanaan naskah lengkep ti 1,5 ka 2 menit pikeun tiap beling. Urang tiasa ngagulungkeun sadayana kana unggal beling tanpa ngeureunkeun jasa kami, tapi urang kedah mareuman unggal PostgreSQL sababaraha menit. Dina hal ieu, pamaké anu data dina beling ieu teu bisa pinuh dianggo dina waktos ieu, sarta ieu unacceptable keur urang.
Jalan kaluar tina kaayaan ieu nyaéta pangropéa anu direncanakeun, anu lumangsung unggal 3 bulan. Ieu mangrupikeun jandela pikeun padamelan anu dijadwalkeun, nalika urang pareum lengkep jasa sareng ningkatkeun instansi database urang. Aya hiji minggu ditinggalkeun nepi ka jandela hareup, sarta kami mutuskeun ngan antosan sarta nyiapkeun salajengna. Dina waktos ngantosan, kami ogé ngamankeun diri: pikeun unggal beling PostgreSQL, urang ngangkat réplika cadang upami gagal ngajaga data pangénggalna, sareng nambihan conto énggal pikeun unggal beling, anu kedah janten réplika énggal dina klaster Patroni, supados henteu ngalaksanakeun paréntah pikeun mupus data. Sadaya ieu ngabantosan ngirangan résiko kasalahan.
Urang restarted jasa kami, sagalana digawé sakumaha sakuduna, pamaké terus digawé, tapi dina grafik kami noticed beban abnormally tinggi dina server Konsul.
Naha urang henteu ningali ieu dina lingkungan tés? Masalah ieu ngagambarkeun kacida alusna yén perlu nuturkeun Infrastruktur salaku prinsip kode jeung nyaring sakabéh infrastruktur, ti lingkungan test ka produksi. Upami teu kitu, éta pisan gampang pikeun meunangkeun masalah urang ngagaduhan. Aya naon? Konsul mimiti muncul dina produksi, teras dina lingkungan uji, salaku hasilna, dina lingkungan uji, versi Konsul langkung luhur tibatan produksi. Ngan dina salah sahiji sékrési, bocor CPU direngsekeun nalika damel sareng konsul-templat. Ku alatan éta, urang saukur diropéa Konsul, sahingga ngarengsekeun masalah.
Balikan deui klaster Patroni
Najan kitu, urang meunang masalah anyar, nu urang malah teu curiga. Nalika ngamutahirkeun Konsul, urang saukur nyabut titik Konsul ti kluster ngagunakeun paréntah cuti konsul → Patroni nyambung ka server Konsul sejen → sagalana jalan. Tapi nalika kami ngahontal conto terakhir tina kluster Konsul sareng ngintunkeun paréntah cuti konsul ka dinya, sadaya kluster Patroni ngan saukur dibalikan deui, sareng dina log kami ningali kasalahan ieu:
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 henteu tiasa nyandak inpormasi ngeunaan klusterna sareng ngamimitian deui.
Pikeun milarian solusi, kami ngahubungi panulis Patroni ngalangkungan masalah dina github. Aranjeunna nyarankeun perbaikan kana file konfigurasi kami:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Kami tiasa ngayakeun réplikasi masalah dina lingkungan tés sareng nguji pilihan ieu di dinya, tapi hanjakalna henteu jalan.
Masalahna masih tetep teu diréngsékeun. Kami ngarencanakeun pikeun nyobian solusi ieu:
- Paké Konsul-agén dina unggal conto klaster Patroni;
- Ngalereskeun masalah dina kode.
Urang ngarti dimana kasalahan lumangsung: masalahna meureun pamakéan timeout standar, nu teu overridden ngaliwatan file konfigurasi. Nalika server Konsul panungtungan dikaluarkeun tina kluster, sakabéh kluster Konsul ngagantung pikeun leuwih ti sadetik, kusabab ieu, Patroni teu bisa meunang status kluster tur lengkep restarts sakabéh kluster.
Untungna, urang teu sapatemon deui kasalahan.
Hasil tina ngagunakeun Patroni
Saatos peluncuran suksés Patroni, kami nambihan réplika tambahan dina unggal klaster. Ayeuna dina unggal klaster aya semblance of a quorum: hiji pamimpin jeung dua réplika, pikeun jaring kaamanan bisi pamisah-otak nalika pindah.
Patroni parantos ngusahakeun produksi langkung ti tilu bulan. Salila ieu, anjeunna parantos tiasa ngabantosan urang. Anyar-anyar ieu, pamimpin salah sahiji klaster maot dina AWS, failover otomatis digarap sareng pangguna terus damel. Patroni ngalaksanakeun tugas utami.
Ringkesan leutik ngeunaan panggunaan Patroni:
- Gampang parobahan konfigurasi. Cukup pikeun ngarobih konfigurasi dina hiji conto sareng éta bakal ditarik ka sadayana kluster. Upami reboot diperyogikeun pikeun nerapkeun konfigurasi énggal, maka Patroni bakal ngantep anjeun terang. Patroni tiasa ngabalikan deui sadayana klaster kalayan paréntah tunggal, anu ogé saé pisan.
- Failover otomatis jalan na geus junun mantuan kami kaluar.
- Update PostgreSQL tanpa downtime aplikasi. Anjeun mimitina kudu ngamutahirkeun réplika ka versi anyar, lajeng ngarobah pamimpin dina klaster Patroni tur ngamutahirkeun pamimpin heubeul. Dina hal ieu, tés perlu pikeun failover otomatis lumangsung.
sumber: www.habr.com