Tujuan utama Patroni yaiku nyedhiyakake Ketersediaan Tinggi kanggo PostgreSQL. Nanging Patroni mung cithakan, ora alat siap-digawe (kang, ing umum, ngandika ing dokumentasi). Ing kawitan marketing, wis nyiyapake Patroni ing lab test, sampeyan bisa ndeleng apa alat gedhe iku lan carane gampang nangani kita nyoba kanggo break kluster. Nanging, ing praktik, ing lingkungan produksi, kabeh ora mesthi kedadeyan kanthi apik lan elegan kaya ing laboratorium tes.
Aku bakal ngandhani sethithik babagan aku. Aku miwiti dadi administrator sistem. Makarya ing pangembangan web. Aku wis kerja ing Data Egret wiwit 2014. Perusahaan iki melu konsultasi ing bidang Postgres. Lan kita ngawula persis Postgres, lan kita bisa karo Postgres saben dina, supaya kita duwe expertise beda related kanggo operasi.
Lan ing pungkasan 2018, kita wiwit alon-alon nggunakake Patroni. Lan sawetara pengalaman wis dikumpulake. Kita piye wae diagnosa, nyetel, tekan praktik paling apik. Lan ing laporan iki aku bakal ngomong babagan.
Saliyane Postgres, aku seneng Linux. Aku kaya kanggo poke watara ing lan njelajah, Aku ngumpulake intine. Aku seneng virtualisasi, wadhah, docker, Kubernetes. Kabeh iki narik kawigatenku, amarga kebiasaan admin lawas mengaruhi. Aku seneng menehi hasil karo ngawasi. Lan aku seneng babagan postgres sing ana gandhengane karo administrasi, yaiku replikasi, serep. Lan ing kalodhangan aku nulis ing Go. Aku dudu insinyur piranti lunak, aku mung nulis dhewe ing Go. Lan menehi kula kesenengan.
- Aku akeh sing ngerti sing Postgres ora duwe HA (Kasedhiyan High) metu saka kothak. Kanggo njaluk HA, sampeyan kudu nginstal soko, ngatur, gaweyan lan njaluk.
- Ana sawetara alat lan Patroni iku salah siji saka wong-wong mau sing solves HA cantik kelangan lan banget uga. Nanging kanthi nglebokake kabeh ing laboratorium tes lan mlaku, kita bisa ndeleng manawa kabeh bisa digunakake, kita bisa ngasilake sawetara masalah, ndeleng kepiye Patroni ngladeni. Lan kita bakal weruh yen kabeh bisa dianggo kanthi apik.
- Nanging ing laku, kita ngadhepi masalah beda. Lan aku bakal ngomong babagan masalah kasebut.
- Aku bakal pitutur marang kowe carane kita didiagnosis iku, apa kita tweaked - apa iku mbantu kita utawa ora.
- Aku ora bakal pitutur marang kowe carane nginstal Patroni, amarga sampeyan bisa google ing Internet, sampeyan bisa ndeleng ing file konfigurasi kanggo ngerti carane iku kabeh diwiwiti, carane wis diatur. Sampeyan bisa ngerti skema, arsitektur, golek informasi babagan ing Internet.
- Aku ora bakal ngomong babagan pengalaman wong liya. Aku mung bakal ngomong babagan masalah sing diadhepi.
- Lan aku ora bakal ngomong babagan masalah sing ana ing njaba Patroni lan PostgreSQL. Yen, contone, ana masalah sing ana gandhengane karo imbangan, nalika kluster kita ambruk, aku ora bakal ngomong babagan iki.
Lan wewaler cilik sadurunge kita miwiti laporan kita.
Kabeh masalah iki sing kita temokake, kita wis padha ing pisanan 6-7-8 sasi operasi. Swara wektu, kita teka menyang praktik paling apik internal. Lan masalah kita ilang. Mulane, laporan kasebut diumumake kira-kira nem sasi kepungkur, nalika kabeh iku seger ing sirahku lan aku ngelingi kabeh kanthi sampurna.
Nalika nyiapake laporan, aku wis ngunggahake postmortem lawas, ndeleng log. Lan sawetara rincian bisa dilalekake, utawa sawetara rincian ora bisa diselidiki kanthi lengkap sajrone analisis masalah, saengga ing sawetara titik bisa uga masalah kasebut ora dianggep kanthi lengkap, utawa ana kekurangan informasi. Lan aku njaluk ngapura kanggo wektu iki.
Apa Patroni?
- Iki minangka cithakan kanggo bangunan HA. Sing apa ngandika ing dokumentasi. Lan saka sudut pandangku, iki minangka klarifikasi sing bener. Patroni dudu peluru perak sing bakal ngrampungake kabeh masalah sampeyan, yaiku, sampeyan kudu ngupayakake supaya bisa digunakake lan nggawa keuntungan.
- Iki minangka layanan agen sing diinstal ing saben layanan database lan minangka jenis sistem init kanggo Postgres sampeyan. Miwiti Postgres, mandheg, miwiti maneh, ngatur maneh, lan ngganti topologi kluster sampeyan.
- Mulane, kanggo nyimpen kahanan kluster, perwakilan saiki, kaya sing katon, sawetara jinis panyimpenan dibutuhake. Lan saka sudut pandang iki, Patroni njupuk dalan kanggo nyimpen negara ing sistem eksternal. Iku sistem panyimpenan konfigurasi sing disebarake. Bisa uga Etcd, Konsul, ZooKeeper, utawa kubernetes Etcd, yaiku salah sawijining pilihan kasebut.
- Lan salah sawijining fitur saka Patroni yaiku sampeyan entuk autofiler metu saka kothak, mung kanthi nyetel. Yen kita njupuk Repmgr kanggo mbandhingake, mula filer kasebut kalebu ing kana. Kanthi Repmgr, kita entuk switchover, nanging yen kita pengin autofiler, banjur kita kudu ngatur tambahan. Patroni wis duwe autofiler metu saka kothak.
- Lan ana akeh liyane. Contone, pangopènan konfigurasi, pour replika anyar, serep, etc.. Nanging iki ngluwihi orane katrangan saka laporan, Aku ora bakal pirembagan bab iku.
Lan asil cilik iku tugas utama Patroni kanggo nindakake autofile uga lan andal supaya kluster kita tetep operasional lan aplikasi ora sok dong mirsani owah-owahan ing topologi kluster.
Nanging nalika miwiti nggunakake Patroni, sistem kita dadi luwih rumit. Yen sadurunge kita duwe Postgres, banjur nalika nggunakake Patroni kita entuk Patroni dhewe, kita entuk DCS ing ngendi negara disimpen. Lan kabeh kudu bisa piye wae. Dadi apa sing bisa salah?
Bisa pecah:
- Postgres bisa rusak. Bisa dadi master utawa replika, salah sijine bisa gagal.
- Patroni dhewe bisa pecah.
- DCS ing ngendi negara disimpen bisa rusak.
- Lan jaringan bisa rusak.
Kabeh poin kasebut bakal dakanggep ing laporan kasebut.
Aku bakal nimbang kasus amarga dadi luwih rumit, ora saka sudut pandang yen kasus kasebut kalebu akeh komponen. Lan saka sudut pandang perasaan subyektif, yen kasus iki angel kanggo aku, angel dibongkar ... lan kosok balene, sawetara kasus entheng lan gampang dibongkar.
Lan kasus pisanan sing paling gampang. Iki kedadeyan nalika njupuk kluster database lan masang panyimpenan DCS ing kluster sing padha. Iki minangka kesalahan sing paling umum. Iki minangka kesalahan ing arsitektur bangunan, yaiku, nggabungake komponen sing beda ing sak panggonan.
Dadi, ana filer, ayo padha ngatasi kedadeyan kasebut.
Lan kene kita kasengsem ing nalika filer kedaden. Yaiku, kita kasengsem ing wektu iki nalika negara kluster diganti.
Nanging filer ora tansah cepet, yaiku ora njupuk unit wektu, bisa ditundha. Bisa tahan suwe.
Mula, ana wektu wiwitan lan wektu pungkasan, yaiku acara sing terus-terusan. Lan kita dibagi kabeh acara dadi telung interval: kita duwe wektu sadurunge filer, sak filer lan sawise filer. Sing, kita nimbang kabeh acara ing timeline iki.
Lan bab pisanan, nalika filer kedaden, kita nggoleki sabab saka apa kedaden, apa sabab saka apa sing mimpin kanggo filer.
Yen kita ndeleng log, bakal dadi log Patroni klasik. Dheweke ngandhani yen server wis dadi master, lan peran master wis liwati menyang simpul iki. Ing kene disorot.
Sabanjure, kita kudu ngerti sebabe filer kedadeyan, yaiku kedadeyan apa sing nyebabake peran master pindhah saka siji simpul menyang liyane. Lan ing kasus iki, kabeh iku prasaja. Kita duwe kesalahan nalika sesambungan karo sistem panyimpenan. Master nyadari yen dheweke ora bisa nggarap DCS, yaiku, ana sawetara masalah karo interaksi kasebut. Lan dheweke ujar manawa dheweke ora bisa dadi master maneh lan mundur. Iki baris "demoted poto" ngandika persis sing.
Yen kita katon ing acara sing sadurunge filer, kita bisa ndeleng ana alesan banget sing dadi masalah kanggo tutugan saka tuntunan.
Yen kita katon ing log Patroni, kita bakal weruh sing kita duwe akeh kasalahan, wektu entek, IE agen Patroni ora bisa karo DCS. Ing kasus iki, iki agen Konsul, sing komunikasi ing port 8500.
Lan masalah ing kene yaiku Patroni lan database mlaku ing host sing padha. Lan server Konsul diluncurake ing simpul sing padha. Kanthi nggawe beban ing server, kita uga nggawe masalah kanggo server Konsul. Dheweke ora bisa komunikasi kanthi bener.
Sawise sawetara wektu, nalika beban mudhun, Patroni kita bisa komunikasi maneh karo agen. Karya normal diterusake. Lan server Pgdb-2 sing padha dadi master maneh. Sing, ana loncat karo muter awak cilik, amarga simpul mundur saka kakuwasan master, lan banjur njupuk maneh, yaiku, kabeh bali kaya.
Lan iki bisa dianggep minangka weker palsu, utawa bisa dianggep yen Patroni nindakake kabeh kanthi bener. Tegese, dheweke ngerti yen dheweke ora bisa njaga kahanan kluster lan ngilangi wewenange.
Lan ing kene masalah muncul amarga kasunyatane server Konsul ana ing hardware sing padha karo basis. Patut, sembarang mbukak: apa iku mbukak ing disk utawa prosesor, uga mengaruhi interaksi karo kluster Konsul.
Lan kita mutusaké sing ngirim ora manggon bebarengan, kita diparengake cluster kapisah kanggo Konsul. Lan Patroni wis nggarap Konsul sing kapisah, yaiku, ana klompok Postgres sing kapisah, klompok Konsul sing kapisah. Iki minangka pitunjuk dhasar babagan cara nindakake lan nyimpen kabeh barang kasebut supaya ora urip bebarengan.
Minangka pilihan, sampeyan bisa ngowahi paramèter ttl, loop_wait, retry_timeout, yaiku nyoba kanggo urip puncak beban jangka pendek iki kanthi nambah paramèter kasebut. Nanging iki dudu pilihan sing paling cocok, amarga beban iki bisa suwe. Lan kita mung bakal ngluwihi watesan paramèter kasebut. Lan bisa uga ora mbantu.
Masalah pisanan, sing sampeyan ngerti, iku prasaja. We njupuk lan sijine DCS bebarengan karo basa, kita tak masalah.
Masalah kapindho padha karo sing pisanan. Iku padha karo maneh masalah interoperabilitas karo sistem DCS.
Yen kita katon ing log, kita bakal weruh sing maneh duwe kesalahan komunikasi. Lan Patroni ngandika aku ora bisa sesambungan karo DCS supaya master saiki dadi menyang mode tiron.
Guru lawas dadi replika, ing kene Patroni nyambut gawe, kaya sing dikarepake. Mlaku pg_rewind kanggo mbaleni log transaksi banjur nyambung menyang master anyar kanggo nyekel master anyar. Ing kene Patroni nyambut gawe, kaya sing kudune.
Ing kene kita kudu nemokake panggonan sing sadurunge filer, yaiku kesalahan sing nyebabake kita duwe filer. Lan ing babagan iki, log Patroni cukup trep kanggo digarap. Dheweke nulis pesen sing padha ing interval tartamtu. Lan yen kita miwiti nggulung log kasebut kanthi cepet, mula kita bakal weruh saka log yen log wis diganti, tegese sawetara masalah wis diwiwiti. Kita cepet bali menyang papan iki, ndeleng apa sing kedadeyan.
Lan ing kahanan normal, log katon kaya iki. Sing duwe kunci dipriksa. Lan yen pemilik, contone, wis diganti, banjur sawetara acara bisa kelakon sing Pattroni kudu nanggapi. Nanging ing kasus iki, kita apik. We are looking for panggonan ngendi kesalahan diwiwiti.
Lan sawise nggulung menyang titik kesalahan wiwit katon, kita weruh yen kita wis fileover otomatis. Lan wiwit kesalahan kita padha related kanggo interaksi karo DCS lan ing cilik kita digunakake Konsul, kita uga katon ing log Konsul, apa kedaden ana.
Kira-kira mbandhingake wektu filer lan wektu ing log Konsul, kita waca sing tanggi ing kluster Konsul wiwit mangu orane anggota liyane saka kluster Konsul.
Lan yen katon ing log saka agen Konsul liyane, sampeyan uga bisa ndeleng sing ana sawetara jenis jaringan ambruk ana. Lan kabeh anggota kluster Konsul mangu-mangu anane saben liyane. Lan iki minangka impetus kanggo filer.
Yen katon ing apa kedaden sadurunge kasalahan iki, sampeyan bisa ndeleng sing ana kabeh limo kasalahan, contone, deadline, RPC tiba, sing, ana cetha sawetara jenis masalah ing interaksi saka anggota kluster Konsul karo saben liyane. .
Wangsulan sing paling gampang yaiku ndandani jaringan. Nanging kanggo kula, ngadeg ing podium, iku gampang ngomong iki. Nanging kahanan kaya mengkono ora tansah customer saged kanggo ndandani jaringan. Dheweke bisa manggon ing DC lan bisa uga ora bisa kanggo ndandani jaringan, mengaruhi peralatan. Lan sawetara opsi liyane dibutuhake.
Ana pilihan:
- Pilihan sing paling gampang, sing ditulis, miturut pendapatku, sanajan ing dokumentasi, yaiku mateni mriksa Konsul, yaiku, mung ngliwati array kosong. Lan kita ngandhani agen Konsul supaya ora nggunakake cek. Kanthi mriksa iki, kita bisa nglirwakake badai jaringan kasebut lan ora miwiti filer.
- Pilihan liyane kanggo mriksa pindho raft_multiplier. Iki minangka parameter saka server Konsul dhewe. Kanthi gawan, disetel kanggo 5. Nilai iki dianjurake dening dokumentasi kanggo lingkungan pementasan. Nyatane, iki mengaruhi frekuensi olahpesen antarane anggota jaringan Konsul. Ing kasunyatan, parameter iki mengaruhi kacepetan komunikasi layanan antarane anggota kluster Konsul. Lan kanggo produksi, wis dianjurake kanggo nyuda supaya simpul ijol-ijolan pesen luwih asring.
- Pilihan liyane kita wis teka munggah karo kanggo nambah prioritas pangolahan Konsul antarane pangolahan liyane kanggo panjadwal proses sistem operasi kang. Ana parameter "apik", iku mung nemtokake prioritas pangolahan sing dijupuk menyang akun panjadwal OS nalika jadwal. Kita uga wis suda Nilai becik kanggo agen Konsul, i.e. tambah prioritas supaya sistem operasi menehi pangolahan Konsul luwih wektu kanggo bisa lan nglakokaké kode sing. Ing kasus kita, iki ngrampungake masalah kita.
- Pilihan liyane ora nggunakake Konsul. Aku duwe kanca sing supporter amba saka Etcd. Lan kita ajeg argue karo wong sing luwih Etcd utawa Konsul. Nanging babagan sing luwih apik, kita biasane setuju karo dheweke yen Konsul duwe agen sing kudu mlaku ing saben simpul kanthi database. Tegese, interaksi Patroni karo kluster Konsul liwat agen iki. Lan agen iki dadi bottleneck. Yen ana kedadeyan ing agen kasebut, Patroni ora bisa kerja maneh karo kluster Konsul. Lan iki masalah. Ora ana agen ing rencana Etcd. Patroni bisa langsung karo dhaptar server Etcd lan wis komunikasi karo wong-wong mau. Ing babagan iki, yen sampeyan nggunakake Etcd ing perusahaan sampeyan, mula Etcd bakal dadi pilihan sing luwih apik tinimbang Konsul. Nanging kita ing pelanggan kita tansah diwatesi dening apa klien wis milih lan nggunakake. Lan kita duwe Konsul kanggo kabeh klien.
- Lan titik pungkasan yaiku mbenakake nilai parameter. Kita bisa ngunggahake paramèter kasebut kanthi pangarep-arep manawa masalah jaringan jangka pendek bakal cendhak lan ora ana ing njaba paramèter kasebut. Kanthi cara iki, kita bisa nyuda agresivitas Patroni kanggo ngajukake otomatis yen ana masalah jaringan.
Aku akeh sing nggunakake Patroni sing akrab karo printah iki.
Printah iki nuduhake kahanan saiki kluster. Lan ing pandang sepisanan, gambar iki bisa uga katon normal. Kita duwe master, kita duwe replika, ora ana replikasi lag. Nanging gambar iki normal persis nganti kita ngerti yen kluster iki kudu telung kelenjar, ora loro.
Mulane, ana file otomatis. Lan sawise autofile iki, replika kita ilang. Kita kudu ngerteni kenapa dheweke ilang lan nggawa dheweke bali, mulihake dheweke. Lan maneh menyang log lan ndeleng kenapa kita duwe fileover otomatis.
Ing kasus iki, replika kapindho dadi master. Iku kabeh tengen kene.
Lan kita kudu ndeleng replika sing tiba lan ora ana ing kluster. Kita mbukak log Patroni lan ndeleng manawa ana masalah sajrone proses nyambungake menyang kluster ing tahap pg_rewind. Kanggo nyambung menyang kluster, sampeyan kudu mbaleni log transaksi, njaluk log transaksi sing dibutuhake saka master, lan gunakake kanggo nyekel master.
Ing kasus iki, kita ora duwe log transaksi lan replika ora bisa miwiti. Mulane, kita mungkasi Postgres kanthi kesalahan. Lan mulane ora ana ing kluster.
Kita kudu ngerti kenapa ora ana ing kluster lan kenapa ora ana log. Kita menyang master anyar lan ndeleng apa sing ana ing log. Pranyata yen pg_rewind wis rampung, ana checkpoint. Lan sawetara log transaksi lawas mung diganti jeneng. Nalika master lawas nyoba nyambung menyang master anyar lan takon log iki, padha wis diganti jeneng, mung ora ana.
Aku mbandhingake cap wektu nalika kedadeyan kasebut. Lan ana bedane secara harfiah 150 milliseconds, yaiku, checkpoint rampung ing 369 milliseconds, segmen WAL diganti jeneng. Lan secara harfiah ing 517, sawise 150 milidetik, mundur diwiwiti ing replika lawas. Sing, secara harfiah 150 milliseconds cukup kanggo kita supaya tiron ora bisa nyambung lan entuk.
Apa pilihane?
Kita pisanan digunakake slot réplikasi. Kita panginten iku apik. Senajan ing tataran pisanan saka operasi kita mateni slot . Iku ketoke kanggo kita yen slot nglumpukake akeh perangan WAL, kita bisa nyelehake master. Dheweke bakal tiba. We nandhang kanggo sawetara wektu tanpa slot . Lan kita temen maujud sing kita kudu slot , kita bali slot .
Nanging ana masalah kene, yen master dadi kanggo tiron, mbusak slot lan mbusak perangan WAL bebarengan karo slot . Lan kanggo ngilangi masalah iki, kita mutusake kanggo ngunggahake parameter wal_keep_segments. Iku standar kanggo 8 segmen. We mundhakaken kanggo 1 lan katon ing pinten papan free kita duwe. Lan kita nyumbang 000 gigabyte kanggo wal_keep_segments. Sing, nalika ngoper, kita tansah duwe cadangan 16 gigabyte log transaksi ing kabeh simpul.
Lan plus - isih relevan kanggo tugas pangopènan jangka panjang. Ayo dadi ngomong kita kudu nganyari salah siji saka replika. Lan kita pengin mateni. Kita kudu nganyari piranti lunak, bisa uga sistem operasi, liyane. Lan nalika kita mateni tiron, slot kanggo tiron uga dibusak. Lan yen kita nggunakake wal_keep_segments cilik, banjur karo anané dawa replika, log transaksi bakal ilang. Kita bakal mundhakaken tiron, iku bakal njaluk sing log transaksi ngendi mandegake, nanging padha ora bisa ing master. Lan replika uga ora bisa nyambung. Mulane, kita nyimpen akeh majalah.
Kita duwe basis produksi. Wis ana proyek sing lagi ditindakake.
Ana filer. Kita mlebu lan ndeleng - kabeh wis rapi, replika wis ana, ora ana lag replikasi. Ora ana kesalahan ing log, kabeh wis rapi.
Tim produk ngandika sing kudu ana sawetara data, nanging kita ndeleng saka siji sumber, nanging kita ora weruh ing database. Lan kita kudu ngerti apa sing kedadeyan karo dheweke.
Cetha yen pg_rewind ora kejawab. Kita langsung ngerti iki, nanging banjur ndeleng apa sing kedadeyan.
Ing log, kita tansah bisa nemokake nalika filer kedaden, sing dadi master, lan kita bisa nemtokake sing master lawas lan nalika arep dadi replika, IE kita kudu log iki kanggo mangerteni jumlah log transaksi sing. wis ilang.
Master lawas kita wis urip maneh. Lan Patroni kadhaftar ing autorun. Dibukak Patroni. Dheweke banjur miwiti Postgres. Luwih tepate, sadurunge miwiti Postgres lan sadurunge nggawe replika, Patroni ngluncurake proses pg_rewind. Mulane, dheweke mbusak bagean saka log transaksi, ndownload sing anyar lan disambungake. Ing kene Patroni nyambut gawe kanthi pinter, yaiku kaya sing dikarepake. Kluster wis dibalèkaké. Kita duwe 3 kelenjar, sawise filer 3 kelenjar - kabeh kelangan.
Kita wis ilang sawetara data. Lan kita kudu ngerti carane akeh sing wis ilang. We are looking for mung wayahe nalika kita wis mundur. Kita bisa nemokake ing entri jurnal kasebut. Mundur maneh diwiwiti, nindakake apa wae ing kana lan rampung.
Kita kudu nemokake posisi ing log transaksi sing ditinggalake master lawas. Ing kasus iki, iki tandha. Lan kita butuh tandha kapindho, yaiku, jarak sing beda karo master lawas saka sing anyar.
We njupuk pg_wal_lsn_diff biasanipun lan mbandhingaké loro tandha iki. Lan ing kasus iki, kita entuk 17 megabyte. Akeh utawa sethithik, saben wong mutusake dhewe. Amarga kanggo wong 17 megabyte ora akeh, kanggo wong iku akeh lan ora bisa ditampa. Ing kene, saben individu nemtokake dhewe sesuai karo kabutuhan bisnis.
Nanging apa sing wis ditemokake kanggo awake dhewe?
Pisanan, kita kudu mutusake dhewe - apa kita kudu Patroni kanggo miwiti otomatis sawise urip maneh sistem? Asring kedadeyan yen kita kudu menyang master lawas, ndeleng carane adoh wis musna. Mbok mriksa bagean saka log transaksi, ndeleng apa ana. Lan kanggo mangerteni apa kita bisa ilang data iki utawa apa kita kudu mbukak master lawas ing mode dewekan kanggo narik data iki metu.
Lan mung sawise kita kudu mutusake manawa kita bisa mbuwang data iki utawa bisa mulihake, nyambungake simpul iki minangka replika menyang kluster.
Kajaba iku, ana parameter "maximum_lag_on_failover". Kanthi gawan, yen memori sandi serves kula, parameter iki nduweni nilai 1 megabyte.
Piye cara kerjane? Yen tiron kita ketinggalan 1 megabyte data ing replikasi lag, banjur replika iki ora melu ing pemilihan. Lan yen dumadakan ana fileover, Patroni katon ing replika sing ketinggalan. Yen padha konco dening nomer akeh log transaksi, padha ora bisa dadi master. Iki minangka fitur keamanan sing apik banget sing nyegah sampeyan kelangan akeh data.
Nanging ana masalah ing kene yen replikasi lag ing kluster Patroni lan DCS dianyari ing interval tartamtu. Aku 30 detik minangka nilai ttl standar.
Patut, ana uga kahanan sing ana siji replikasi lag kanggo replika ing DCS, nanging nyatane bisa uga ana lag temen beda utawa ora ana lag ing kabeh, IE bab iki ora realtime. Lan ora tansah nggambarake gambar nyata. Lan iku ora worth nindakake logika apik ing.
Lan risiko mundhut tansah tetep. Lan ing kasus paling awon, siji rumus, lan ing kasus rata-rata, rumus liyane. Yaiku, nalika kita ngrancang implementasine Patroni lan ngevaluasi jumlah data sing bisa ilang, kita kudu ngandelake rumus kasebut lan kira-kira mbayangno jumlah data sing bisa ilang.
Lan ana kabar apik. Yen master lawas wis maju, dheweke bisa maju amarga sawetara proses latar mburi. Yaiku, ana sawetara jinis autovacuum, dheweke nulis data kasebut, disimpen ing log transaksi. Lan kita bisa gampang nglirwakake lan ilang data iki. Ora ana masalah ing babagan iki.
Lan iki carane log katon yen maximum_lag_on_failover disetel lan filer wis kedaden, lan sampeyan kudu milih master anyar. Replika kasebut nganggep awake dhewe ora bisa melu pemilu. Lan dheweke ora gelem melu lomba kanggo pimpinan. Lan dheweke ngenteni master anyar sing dipilih, supaya dheweke bisa nyambung. Iki minangka langkah tambahan marang mundhut data.
Ing kene kita duwe tim produk sing nulis manawa produke duwe masalah karo Postgres. Ing wektu sing padha, master dhewe ora bisa diakses, amarga ora kasedhiya liwat SSH. Lan autofile uga ora kelakon.
Host iki dipeksa kanggo urip maneh. Amarga urip maneh, file otomatis kedadeyan, sanajan bisa nindakake file otomatis manual, kaya sing aku ngerti saiki. Lan sawise urip maneh, kita wis arep ndeleng apa sing kita duwe karo master saiki.
Ing wektu sing padha, kita ngerti luwih dhisik yen kita duwe masalah karo disk, yaiku, kita wis ngerti saka ngawasi ngendi kanggo digali lan apa sing kudu digoleki.
Kita mlebu log postgres, wiwit ndeleng apa sing kedadeyan ing kana. Kita ndeleng komitmen sing ana sajrone siji, loro, telung detik, sing ora normal. Kita weruh yen autovacuum kita wiwit alon banget lan aneh. Lan kita weruh file sauntara ing disk. Sing, iki kabeh pratondho masalah karo disk.
We katon menyang sistem dmesg (kernel log). Lan kita weruh yen kita duwe masalah karo salah siji saka disk. Subsistem disk yaiku Raid piranti lunak. Kita ndeleng / proc / mdstat lan weruh yen kita ilang siji drive. Sing, ana Raid saka 8 disk, kita ilang siji. Yen kasebut kanthi teliti, katon ing geser, banjur ing output sampeyan bisa ndeleng sing kita ora duwe sde ana. Ing kita, kanthi kondisional, disk wis ilang. Iki nyebabake masalah disk, lan aplikasi uga ngalami masalah nalika nggarap kluster Postgres.
Lan ing kasus iki, Patroni ora bakal nulungi kita kanthi cara apa wae, amarga Patroni ora duwe tugas ngawasi kahanan server, kahanan disk. Lan kita kudu ngawasi kahanan kasebut kanthi ngawasi eksternal. Kita kanthi cepet nambah ngawasi disk menyang ngawasi eksternal.
Lan ana pikirane - apa piranti lunak anggar utawa pengawas bisa mbantu kita? Kita panginten sing bakal meh ora wis mbantu kita ing kasus iki, amarga sak masalah Patroni terus sesambungan karo kluster DCS lan ora weruh masalah. Yaiku, saka sudut pandang DCS lan Patroni, kabeh kluster kasebut apik, sanajan ana masalah karo disk, ana masalah karo kasedhiyan database.
Ing mratelakake panemume, iki salah siji saka masalah strangest aku wis riset kanggo dangu banget, Aku wis maca akèh log, milih maneh lan disebut simulator cluster.
Masalahe yaiku master lawas ora bisa dadi replika normal, yaiku Patroni miwiti, Patroni nuduhake yen simpul iki ana minangka replika, nanging ing wektu sing padha dudu replika normal. Saiki sampeyan bakal weruh apa. Iki sing daksimpen saka analisis masalah kasebut.
Lan kepiye kabeh diwiwiti? Diwiwiti, kaya ing masalah sadurunge, karo rem cakram. Kita duwe komitmen sedhela, loro.
Ana breaks ing sambungan, IE, klien padha ambruk.
Ana blockages saka macem-macem keruwetan.
Lan, miturut, subsistem disk ora responsif banget.
Lan sing paling misterius kanggo aku yaiku panjaluk mati langsung sing teka. Postgres duwe telung mode mati:
- Anggun nalika ngenteni kabeh klien medhot sambungan dhewe.
- Ana cepet nalika kita meksa klien kanggo medhot sambungan amarga kita arep mati.
- Lan langsung. Ing kasus iki, langsung ora ngandhani klien supaya mateni, mung mateni tanpa peringatan. Lan kanggo kabeh klien, sistem operasi wis ngirim pesen RST (pesen TCP sing sambungan diselani lan klien ora ana liyane kanggo nyekel).
Sapa sing ngirim sinyal iki? Proses latar mburi Postgres ora ngirim sinyal kasebut menyang saben liyane, yaiku mateni-9. Dheweke ora ngirim barang-barang kasebut, mung nanggepi perkara kasebut, yaiku iki minangka wiwitan darurat Postgres. Sapa sing ngirim, aku ora ngerti.
Aku katon ing "pungkasan" printah lan aku weruh siji wong sing uga mlebu ing server iki karo kita, nanging aku banget isin kanggo takon. Mbok iku matèni -9. Aku bakal weruh matèni -9 ing log, amarga Postgres ngandika iku njupuk matèni -9, nanging aku ora weruh ing log.
Nggoleki luwih, aku weruh yen Patroni ora nulis menyang log kanggo dangu - 54 detik. Lan yen kita mbandhingake rong cap wektu, ora ana pesen sajrone 54 detik.
Lan ing wektu iki ana autofile. Patroni nindakake pakaryan sing apik ing kene maneh. Guru lawas kita ora kasedhiya, ana kedadeyan. Lan pemilihan master anyar diwiwiti. Kabeh bisa metu uga kene. pgsql01 kita wis dadi pimpinan anyar.
Kita duwe replika sing wis dadi master. Lan ana respon kapindho. Lan ana masalah karo replika kapindho. Dheweke nyoba ngatur maneh. Nalika aku ngerti, dheweke nyoba ngganti recovery.conf, miwiti maneh Postgres lan nyambung menyang master anyar. Dheweke nulis pesen saben 10 detik sing dicoba, nanging ora sukses.
Lan sajrone upaya kasebut, sinyal mati langsung teka ing master lawas. Master diwiwiti maneh. Lan uga Recovery mandheg amarga master lawas dadi menyang urip maneh. Tegese, replika ora bisa nyambung, amarga ana ing mode mati.
Ing sawetara titik, bisa, nanging replikasi ora diwiwiti.
Kula mung guess iku ana alamat master lawas ing recovery.conf. Lan nalika master anyar muncul, replika kapindho isih nyoba nyambung menyang master lawas.
Nalika Patroni miwiti replika kapindho, simpul kasebut diwiwiti nanging ora bisa ditiru. Lan lag réplikasi dibentuk, sing katon kaya iki. Tegese, kabeh telung simpul ana ing papan, nanging simpul kapindho ketinggalan.
Ing wektu sing padha, yen sampeyan ndeleng log sing ditulis, sampeyan bisa ndeleng manawa replikasi ora bisa diwiwiti amarga log transaksi beda. Lan log transaksi sing ditawakake master, sing ditemtokake ing recovery.conf, mung ora cocog karo simpul saiki.
Lan ing kene aku nggawe kesalahan. Aku kudu teka lan ndeleng apa ana ing Recovery.conf kanggo nyoba hipotesis sing kita nyambung menyang master salah. Nanging banjur aku iki mung dealing with iki lan ora kelakon kanggo kula, utawa aku weruh sing tiron wis lagging konco lan kudu refilled, iku, aku piye wae makarya carelessly. Iki gabunganku.
Sawise 30 menit, admin wis teka, yaiku aku miwiti maneh Patroni ing replika. Aku wis mungkasi, aku mikir yen kudu diisi maneh. Lan aku mikir - aku bakal miwiti maneh Patroni, bisa uga ana sing apik. Recovery diwiwiti. Lan pangkalan malah dibukak, iku siap kanggo nampa sambungan.
Replikasi wis diwiwiti. Nanging sawetara menit mengko, dheweke tiba kanthi kesalahan yen log transaksi ora cocog kanggo dheweke.
Aku panginten aku bakal miwiti maneh. Aku miwiti maneh Patroni, lan aku ora miwiti maneh Postgres, nanging miwiti maneh Patroni ing pangarep-arep sing gaib bakal miwiti database.
Replikasi diwiwiti maneh, nanging tandha ing log transaksi beda-beda, ora padha karo nyoba wiwitan sadurunge. Replikasi mandheg maneh. Lan pesen wis rada beda. Lan iku ora banget informatif kanggo kula.
Lan banjur ana kanggo kula - apa yen aku miwiti maneh Postgres, ing wektu iki aku nggawe checkpoint ing master saiki kanggo mindhah titik ing log transaksi maju sethitik supaya Recovery diwiwiti saka wayahe liyane? Kajaba iku, kita isih duwe saham WAL.
Aku miwiti maneh Patroni, nindakake saperangan saka checkpoints ing master, saperangan saka TCTerms miwiti maneh ing tiron nalika dibukak. Lan mbantu. Aku mikir kanggo dangu kok mbantu lan carane iku bisa. Lan replika diwiwiti. Lan replikasi ora suwe maneh.
Masalah kaya ngono kanggoku minangka salah sawijining masalah sing luwih misterius, sing aku isih teka-teki babagan apa sing kedadeyan ing kana.
Apa implikasi ing kene? Patroni bisa mlaku kaya sing dikarepake lan tanpa kesalahan. Nanging ing wektu sing padha, iki ora njamin 100% yen kabeh apik karo kita. Replika bisa diwiwiti, nanging bisa uga ana ing negara semi-makarya, lan aplikasi kasebut ora bisa digunakake karo replika kasebut, amarga bakal ana data lawas.
Lan sawise filer, sampeyan kudu tansah mriksa sing kabeh iku supaya karo kluster, yaiku, ana jumlah replika sing dibutuhake, ora ana replikasi lag.
Lan nalika ngatasi masalah kasebut, aku bakal menehi saran. Aku nyoba gabungke dadi rong slide. Mbokmenawa, kabeh crita bisa digabung dadi rong slide lan mung dicritakake.
Nalika sampeyan nggunakake Patroni, sampeyan kudu ngawasi. Sampeyan kudu tansah ngerti nalika ana autofileover, amarga yen sampeyan ora ngerti sampeyan duwe autofileover, sampeyan ora duwe kontrol liwat kluster. Lan sing ala.
Sawise saben filer, kita kudu mriksa kluster kanthi manual. Kita kudu mesthekake yen kita tansah duwe nomer up-to-date replika, ora ana replikasi lag, ora ana kasalahan ing log related kanggo streaming réplikasi, karo Patroni, karo sistem DCS.
Otomasi bisa sukses, Patroni minangka alat sing apik banget. Bisa, nanging iki ora bakal nggawa kluster menyang negara sing dikarepake. Lan yen kita ora ngerti babagan iki, kita bakal ngalami alangan.
Lan Patroni dudu peluru perak. Kita isih kudu ngerti cara kerja Postgres, cara replikasi lan cara kerjane Patroni karo Postgres, lan kepiye komunikasi antarane simpul diwenehake. Iki perlu supaya bisa ndandani masalah karo tangan.
Kepiye cara nyedhaki masalah diagnosis? Iku kedadeyan yen kita kerja karo klien sing beda-beda lan ora ana sing duwe tumpukan ELK, lan kita kudu ngurutake log kanthi mbukak 6 konsol lan 2 tab. Ing siji tab, iki minangka log Patroni kanggo saben simpul, ing tab liyane, iki minangka log Konsul, utawa Postgres yen perlu. Iku angel banget kanggo diagnosa iki.
Apa pendekatan sing wis dakkembangake? Pisanan, aku tansah katon nalika filer wis teka. Lan kanggo kula iki minangka watershed. Aku ndeleng apa sing kedadeyan sadurunge filer, sajrone filer lan sawise filer. Fileover duwe rong tandha: iki wektu wiwitan lan pungkasan.
Sabanjure, aku katon ing log kanggo acara sadurunge filer, sing ndhisiki filer, yaiku aku nggoleki alasan kenapa filer kedadeyan.
Lan iki menehi gambaran kanggo mangerteni apa sing kedadeyan lan apa sing bisa ditindakake ing mangsa ngarep supaya kahanan kasebut ora kedadeyan (lan minangka asil, ora ana filer).
Lan ing ngendi kita biasane katon? Aku katon:
- Kaping pisanan, menyang log Patroni.
- Sabanjure, aku ndeleng log Postgres, utawa log DCS, gumantung saka apa sing ditemokake ing log Patroni.
- Lan log sistem uga kadhangkala menehi pangerten apa sing nyebabake filer.
Piye perasaanku marang Patroni? Aku duwe hubungan apik banget karo Patroni. Miturut pendapatku, iki sing paling apik saiki. Aku ngerti akeh produk liyane. Iki Stolon, Repmgr, Pg_auto_failover, PAF. 4 piranti. Aku nyoba kabeh. Patroni iku favoritku.
Yen padha takon kula: "Apa aku nyaranake Patroni?". Aku bakal ngomong ya, amarga aku seneng karo Patroni. Lan aku rumangsa sinau carane masak.
Yen sampeyan kepengin weruh apa masalah liyane sing ana karo Patroni saliyane masalah sing dakkandhakake, sampeyan bisa mriksa kaca kasebut. ing GitHub. Ana macem-macem crita lan akeh masalah menarik sing dibahas ing kana. Lan minangka asil, sawetara kewan omo dikenalake lan ditanggulangi, yaiku, iki minangka maca sing menarik.
Ana sawetara crita sing menarik babagan wong sing nembak awake dhewe ing sikil. informatif banget. Sampeyan maca lan ngerti yen ora perlu nglakoni. Aku ticked dhewe.
Lan aku seneng ngucapake matur nuwun kanggo Zalando kanggo ngembangake proyek iki, yaiku Alexander Kukushkin lan Alexey Klyukin. Aleksey Klyukin minangka salah sawijining panulis, dheweke ora kerja maneh ing Zalando, nanging iki wong loro sing miwiti nggarap produk iki.
Lan aku mikir yen Patroni pancen keren banget. Aku seneng yen dheweke ana, menarik karo dheweke. Lan matur nuwun banget kanggo kabeh kontributor sing nulis patch kanggo Patroni. Muga-muga Patroni dadi luwih dewasa, keren lan efisien kanthi umur. Wis fungsional, nanging muga-muga bisa luwih apik. Mulane, yen sampeyan arep nggunakake Patroni, aja wedi. Iki minangka solusi sing apik, bisa ditindakake lan digunakake.
Mekaten. Yen sampeyan duwe pitakon, takon.
Pitakonan
Matur nuwun kanggo laporan! Yen sawise filer sampeyan isih kudu katon kanthi ati-ati, banjur kenapa kita butuh filer otomatis?
Amarga iku barang anyar. Kita mung karo dheweke kanggo setahun. Luwih becik aman. Kita pengin mlebu lan ndeleng manawa kabeh wis rampung kanthi bener. Iki minangka tingkat ora percaya wong diwasa - luwih becik mriksa maneh lan ndeleng.
Contone, kita lunga ing wayah esuk lan katon, ta?
Ora esuk, kita biasane sinau babagan autofile meh langsung. Kita nampa kabar, kita weruh sing autofile wis kedaden. Kita meh langsung lunga lan ndeleng. Nanging kabeh mriksa iki kudu digawa menyang tingkat ngawasi. Yen sampeyan ngakses Patroni liwat REST API, ana sajarah. Miturut sejarah sampeyan bisa ndeleng cap wektu nalika filer kedadeyan. Adhedhasar iki, pemantauan bisa ditindakake. Sampeyan bisa ndeleng sajarah, carane akeh acara ana. Yen kita duwe acara liyane, banjur file otomatis wis kedaden. Sampeyan bisa pindhah lan ndeleng. Utawa otomatisasi ngawasi kita mriksa manawa kita duwe kabeh replika, ora ana lag lan kabeh apik.
Matur suwun!
Matur nuwun kanthi sanget kanggo crita sing apik! Yen kita pindhah kluster DCS nang endi wae adoh saka kluster Postgres, kluster iki uga kudu dilayani sacara periodik? Apa sing paling laku sing sawetara bêsik kluster DCS kudu dipateni, soko apa karo, etc. Kepiye struktur iki bisa urip? Lan kepiye carane nindakake perkara kasebut?
Kanggo siji perusahaan, sampeyan kudu nggawe matriks masalah, apa sing kedadeyan yen salah siji komponen utawa sawetara komponen gagal. Miturut matriks iki, kita terus-terusan ngliwati kabeh komponen lan nggawe skenario yen gagal komponen kasebut. Mulane, kanggo saben skenario kegagalan, sampeyan bisa duwe rencana tumindak kanggo pemulihan. Lan ing kasus DCS, iki minangka bagéan saka infrastruktur standar. Lan admin ngatur, lan kita wis gumantung ing admin sing ngatur lan kemampuan kanggo ndandani iku ing cilik saka kacilakan. Yen ora ana DCS ing kabeh, banjur kita masang, nanging ing wektu sing padha ora utamané ngawasi, amarga kita ora tanggung jawab kanggo infrastruktur, nanging kita menehi Rekomendasi carane lan apa kanggo ngawasi.
Yaiku, apa aku ngerti yen aku kudu mateni Patroni, mateni filer, mateni kabeh sadurunge nindakake apa wae karo host?
Iku gumantung carane akeh kelenjar kita duwe ing kluster DCS. Yen ana akeh kelenjar lan yen kita mateni mung siji saka kelenjar (replika), banjur kluster njaga kuorum. Lan Patroni tetep operasional. Lan ora ana sing dipicu. Yen kita duwe sawetara operasi Komplek sing mengaruhi kelenjar liyane, anané kang bisa ngrusak kuorum, banjur - ya, iku bisa kanggo sijine Patroni ing ngaso. Wis printah sing cocog - patronictl pause, patronictl resume. Kita mung ngaso lan autofiler ora bisa digunakake ing wektu kasebut. Kita nindakake pangopènan ing kluster DCS, banjur kita njupuk ngaso lan terus urip.
Matur nuwun sanget!
Matur nuwun kanthi sanget kanggo laporan sampeyan! Piye rasane tim produk babagan data sing ilang?
Tim produk ora peduli, lan pimpinan tim kuwatir.
Apa jaminan sing ana?
Njamin angel banget. Alexander Kukushkin duwe laporan "Carane ngetung RPO lan RTO", yaiku wektu pemulihan lan jumlah data sing bisa ilang. Aku mikir kita kudu nemokake slide kasebut lan sinau. Minangka adoh aku ngelingi, ana langkah-langkah khusus babagan cara ngetung barang kasebut. Carane akeh transaksi kita bisa ilang, carane akeh data kita bisa ilang. Minangka pilihan, kita bisa nggunakake réplikasi sinkron ing tingkat Patroni, nanging iki pedhang pindho edged: kita duwe linuwih data, utawa kita ilang kacepetan. Ana replikasi sinkron, nanging uga ora njamin pangayoman 100% marang mundhut data.
Alexey, matur nuwun kanggo laporan sing apik! Apa pengalaman nggunakake Patroni kanggo pangayoman tingkat nul? Sing, magepokan karo siyaga sinkron? Iki pitakonan pisanan. Lan pitakonan kapindho. Sampeyan wis nggunakake solusi sing beda. Kita digunakake Repmgr, nanging tanpa autofiler, lan saiki kita planning kanggo kalebu autofiler. Lan kita nganggep Patroni minangka solusi alternatif. Apa sampeyan bisa ngomong minangka kaluwihan dibandhingake Repmgr?
Pitakonan pisanan yaiku babagan replika sinkron. Ora ana sing nggunakake replikasi sinkron ing kene, amarga kabeh wong wedi (Saperangan klien wis nggunakake, ing asas, padha ora weruh masalah kinerja - Cathetan speaker). Nanging kita wis nggawe aturan kanggo awake dhewe sing kudu paling sethithik telung simpul ing kluster replikasi sinkron, amarga yen kita duwe rong simpul lan yen master utawa replika gagal, banjur Patroni ngalih simpul iki menyang mode Standalone supaya aplikasi kasebut terus. kerja. Ing kasus iki, ana risiko mundhut data.
Babagan pitakonan kapindho, kita wis nggunakake Repmgr lan isih nindakake karo sawetara klien amarga alasan historis. Apa sing bisa dikandhakake? Patroni dilengkapi autofiler metu saka kothak, Repmgr dilengkapi autofiler minangka fitur tambahan sing kudu diaktifake. Kita kudu mbukak daemon Repmgr ing saben simpul banjur bisa ngatur autofiler.
Repmgr mriksa yen simpul Postgres isih urip. Proses Repmgr mriksa anane saben liyane, iki dudu pendekatan sing efisien banget. bisa uga ana kasus kompleks isolasi jaringan ing ngendi kluster Repmgr sing gedhe bisa pecah dadi sawetara sing luwih cilik lan terus digunakake. Aku wis suwe ora ngetutake Repmgr, mungkin wis didandani ... utawa ora. Nanging mbusak informasi bab negara kluster ing DCS, minangka Stolon, Patroni, iku pilihan paling sregep.
Alexey, Aku duwe pitakonan, Mungkin sing lamer. Ing salah siji conto pisanan, sampeyan dipindhah DCS saka mesin lokal menyang host remot. Kita ngerti yen jaringan minangka barang sing nduweni ciri dhewe, urip dhewe. Lan apa mengkono yen sakperangan alesan kluster DCS dadi kasedhiya? Aku ora bakal ngomong alasan, bisa uga akeh: saka tangan bengkong saka jaringan menyang masalah nyata.
Aku ora ngandika banter, nanging kluster DCS uga kudu failover, IE iku nomer ganjil saka kelenjar, supaya kuorum ketemu. Apa mengkono yen kluster DCS dadi kasedhiya, utawa kuorum ora bisa ketemu, IE sawetara jinis pamisah jaringan utawa Gagal simpul? Ing kasus iki, kluster Patroni dadi mode mung diwaca. Kluster Patroni ora bisa nemtokake kahanan kluster lan apa sing kudu ditindakake. Ora bisa hubungi DCS lan nyimpen negara kluster anyar ana, supaya kabeh kluster dadi mung diwaca. Lan ngenteni intervensi manual saka operator utawa DCS pulih.
Kira-kira, DCS dadi layanan kanggo kita minangka penting minangka basis dhewe?
Ya wis. Ing akeh perusahaan modern, Service Discovery minangka bagean integral saka infrastruktur kasebut. Iki ditindakake sanajan sadurunge ana database ing infrastruktur kasebut. Relatif ngandika, infrastruktur diluncurake, disebarake ing DC, lan kita langsung duwe Service Discovery. Yen iku Konsul, banjur DNS bisa dibangun ing. Yen iki Etcd, bisa uga ana bagean saka kluster Kubernetes, sing kabeh liyane bakal disebarake. Kayane aku Service Discovery wis dadi bagean integral saka infrastruktur modern. Lan dheweke mikir babagan iki luwih awal tinimbang babagan database.
Matur suwun!
Source: www.habr.com