Dem Patroni säin Haaptziel ass héich Disponibilitéit fir PostgreSQL ze bidden. Awer Patroni ass just eng Schabloun, net e fäerdegt Tool (wat am Allgemengen ass wat d'Dokumentatioun seet). Op den éischte Bléck, nodeems Dir Patroni am Testlabor konfiguréiert hutt, kënnt Dir gesinn wat e wonnerschéint Tool et ass a wéi einfach et eis Versuche behandelt fir de Stärekoup ze zerstéieren. Mä an der Praxis an engem Produktiounsëmfeld geschitt net ëmmer alles esou schéin an elegant wéi an engem Testlabo.
Ech soen Iech e bëssen iwwer mech selwer. Ech ugefaang als System Administrateur. Am Webentwécklung geschafft. Ech schaffen zënter 2014 bei Data Egret. D'Firma beschäftegt sech mat Berodung am Beräich Postgres. A mir Service Postgres speziell, a mir schaffen all Dag mat Postgres, also mir hunn eng Rei vun operationell Expertise.
An um Enn vum 2018 hu mir ugefaang Patroni lues a lues ze benotzen. An e puer spezifesch Erfahrung ass gesammelt. Mir hunn et iergendwéi diagnostizéiert, ofgestëmmt an op eis bescht Praktiken komm. An an dësem Bericht wäert ech iwwer si schwätzen.
Nieft Postgres hunn ech Linux gär. Ech hu gär ronderëm ze pochen an ze entdecken, ech hu gär Käre sammelen. Ech Léift Virtualiséierung, Container, Docker, Kubernetes. All dat interesséiert mech, well al Admin Gewunnechten huelen hir Maut. Ech hu gär d'Iwwerwaachung ze verstoen. An ech hunn Postgres Saachen am Zesummenhang mat Administratioun gär, dh Replikatioun, Backup. A menger Fräizäit schreiwen ech am Go. Ech si kee Softwareingenieur, ech schreiwen just a Go fir mech selwer. An et mécht mech Freed.
- Ech mengen vill vun iech wëssen datt Postgres keen HA (High Availability) aus der Këscht huet. Fir HA ze kréien, musst Dir eppes setzen, konfiguréieren, den Effort maachen an et kréien.
- Et gi verschidde Tools a Patroni ass ee vun hinnen, wat HA ganz cool a ganz gutt léist. Awer andeems Dir alles an engem Testlabo setzt an et leeft, kënne mir gesinn datt alles funktionnéiert, mir kënnen e puer Probleemer reproduzéieren, kucken wéi Patroni se servéiert. A mir wäerte gesinn datt alles super funktionnéiert.
- Mä an der Praxis hu mir verschidde Problemer begéint. An ech wäert iwwer dës Problemer schwätzen.
- Ech soen Iech wéi mir et diagnostizéiert hunn, wat mir ugepasst hunn - ob et eis gehollef huet oder net gehollef huet.
- Ech soen Iech net wéi Dir Patroni installéiere kënnt, well Dir kënnt et um Internet google, Dir kënnt d'Konfiguratiounsdateien kucken fir ze verstoen wéi et alles ufänkt a wéi et konfiguréiert ass. Dir kënnt d'Diagrammer an d'Architekturen verstoen andeems Dir Informatioun doriwwer um Internet fannt.
- Ech wäert net iwwer aner Leit hir Erfahrungen schwätzen. Ech wäert nëmmen iwwer d'Problemer schwätzen, déi mir konfrontéiert hunn.
- An ech wäert net iwwer Probleemer schwätzen déi ausserhalb vu Patroni a PostgreSQL sinn. Wann et zum Beispill Problemer am Zesummenhang mam Balance gëtt, wann eise Stärekoup zesummegefall ass, wäert ech net doriwwer schwätzen.
An e klenge Verzichterklärung ier mer eise Bericht ufänken.
All dës Problemer, déi mir begéint hunn, hu mir se an den éischte 6-7-8 Méint vun der Operatioun. Mat der Zäit si mir op eis eegen intern Best Practices komm. An eis Problemer sinn verschwonnen. Dofir gouf de Rapport viru ronn sechs Méint agereecht, wéi et alles frësch a mengem Kapp war an ech mech alles perfekt erënnert hunn.
Bei der Preparatioun vum Bericht hunn ech schonn al Postmortem opgeholl an d'Logbicher gekuckt. An e puer vun den Detailer si vläicht vergiess ginn, oder e puer vun den Detailer si vläicht net voll exploréiert wärend der Analyse vun de Probleemer, also op e puer Punkte kann et schéngen datt d'Problemer net ganz berücksichtegt goufen, oder et gëtt eng Aart vun Mangel un Informatioun. An dofir bieden ech Iech fir mech fir dëse Moment ze verzeien.
Wat ass Patroni?
- Dëst ass eng Schabloun fir HA ze bauen. Dat steet an der Dokumentatioun. A vu menger Siicht ass dat eng ganz korrekt Opklärung. Patroni ass keng Sëlwerkugel déi all Är Probleemer léist, dh Dir musst en Effort maachen fir datt se ufänken ze schaffen an nëtzlech sinn.
- Dëst ass en Agent Service deen op all Service mat enger Datebank installéiert ass, an deen eng Aart Init System fir Är Postgres ass. Et fänkt Postgres un, stoppt et, start et nei, ännert d'Konfiguratioun an ännert d'Topologie vun Ärem Cluster.
- Deementspriechend, fir den Zoustand vum Stärekoup ze späicheren, ass seng aktuell Representatioun, wéi et ausgesäit, eng Aart vu Späichere gebraucht. An aus dëser Siicht huet Patroni de Wee geholl fir Staat an engem externen System ze späicheren. Et ass e verdeelt Konfiguratiounsspeichersystem. Dëst kéint Etcd, Consul, ZooKeeper oder kubernetes Etcd sinn, dh eng vun dësen Optiounen.
- An ee vun de Feature vu Patroni ass datt Dir den Autofileover aus der Këscht kritt, nëmmen nodeems Dir se opgeriicht hutt. Wa mir Repmgr zum Verglach huelen, ass de Filer do abegraff. Mat Repmgr kréie mir Iwwerschaltung, awer wa mir Autofileover wëllen, da muss et weider konfiguréiert ginn. Patroni huet schonn en Autofileover aus der Këscht.
- An et gi vill aner Saachen. Zum Beispill, Konfiguratiounen erhalen, nei Repliken addéieren, Backups, etc.. Awer dëst ass iwwer den Ëmfang vum Bericht, ech wäert net doriwwer schwätzen.
An e klengt Resultat ass datt d'Haaptaufgab vum Patroni ass en Autofileover gutt an zouverlässeg ze maachen, sou datt eise Cluster operationell bleift an d'Applikatioun keng Ännerungen an der Clustertopologie bemierkt.
Awer wa mir Patroni benotzen, gëtt eise System e bësse méi komplex. Wa mir fréier Postgres haten, da wa mir Patroni benotze kréie mir Patroni selwer, mir kréien DCS, wou de Staat gespäichert ass. An et muss alles iergendwéi funktionnéieren. Dofir, wat kann briechen?
Kann briechen:
- Postgres kann briechen. Et kéint e Meeschter oder eng Replik sinn, ee vun hinnen kéint versoen.
- De Patroni selwer kann briechen.
- Den DCS, wou de Staat gespäichert ass, kann briechen.
- An d'Netz kann briechen.
Ech wäert all dës Punkten am Rapport betruecht.
Ech wäert Fäll betruecht wéi se méi komplex ginn, net aus der Siicht, datt e Fall vill Komponente ëmfaasst. A aus der Siicht vu subjektiv Gefiller war dëse Fall fir mech komplex, et war schwéier ze demontéieren ... a vice versa, e puer Fall war liicht an einfach ze demontéieren.
An den éischte Fall ass am einfachsten. Dëst ass de Fall wa mir en Datebankcluster geholl hunn an eis DCS-Späichere um selwechte Cluster ofgesat hunn. Dëst ass deen heefegste Feeler. Dëst ass e Feeler beim Bau vun Architekturen, dh verschidde Komponenten op enger Plaz ze kombinéieren.
Also, e Filer ass geschitt, loosst eis erausfannen wat geschitt ass.
An hei si mir interesséiert wéini de Filer geschitt ass. Dat heescht, mir sinn interesséiert an dësem Moment an der Zäit wou den Zoustand vum Stärekoup geännert huet.
Awer de Filer ass net ëmmer direkt, dh et hëlt keng gewëssen Zäitunitéit, et ka weider zéien. Et kann laang dauerhafter ginn.
Dofir huet et eng Startzäit an eng Ennzäit, dat heescht et ass e kontinuéierlechen Event. A mir deelen all Eventer an dräi Intervalle op: mir hunn Zäit virum Filer, während dem Filer an nom Filer. Dat ass, mir betruechten all Eventer an dëser Timeline.
An als éischt, wann e Filer geschitt ass, kucke mir no de Grond, wat geschitt ass, wat verursaacht huet wat zu de Filer gefouert huet.
Wa mir d'Logbicher kucken, dat sinn déi klassesch Patroni Logbicher. An hinnen seet hien eis datt de Server e Meeschter ginn ass, an d'Roll vum Meeschter ass op dësen Node passéiert. Et ass hei beliicht.
Als nächst musse mir verstoen firwat de Filer geschitt ass, dat heescht, wéi eng Eventer opgetruede sinn, déi d'Meeschterroll vun engem Node an en anert geplënnert hunn. An an dësem Fall ass alles einfach. Mir hunn e Feeler beim Interaktioun mam Späichersystem. De Meeschter huet gemierkt datt hien net mat DCS ka schaffen, dh et war e Problem mat der Interaktioun. An hie seet, datt hie kee Meeschter méi ka sinn an demissionéiert. Dës Linn "demotéiert selwer" seet genee dat.
Wa mir d'Evenementer kucken, déi de Filer viru gaangen sinn, kënne mir do déi ganz Grënn gesinn, déi als Problem fir d'Fortsetzung vun der Meeschtesch Aarbecht gedéngt hunn.
Wa mir d'Patroni Logbicher kucken, wäerte mir gesinn datt mir vill vun all Zorte vu Feeler an Timeouts hunn, dh de Patroni Agent kann net mat DCS schaffen. An dësem Fall ass dëst de Consul Agent, mat deem d'Kommunikatioun um Hafen 8500 stattfënnt.
An de Problem hei ass datt Patroni an d'Datebank um selwechten Host lafen. A Consul Server goufen um selwechten Node lancéiert. Andeems Dir eng Laascht op de Server erstellt, hu mir Problemer fir d'Konsul-Server erstallt. Si konnten net normal kommunizéieren.
No enger Zäit, wéi d'Laascht ofgeholl huet, konnt eise Patroni erëm mat den Agenten kommunizéieren. Normal Aarbecht ass erëm opgaang. An dee selwechte Pgdb-2 Server gouf erëm de Meeschter. Dat heescht, et gouf e klenge Flip, wéinst deem den Node seng Muechten als Meeschter ofginn huet, an dann erëm iwwerholl huet, dat heescht, alles ass zréck wéi et war.
An dëst kann als falsch Positiv ugesi ginn, oder et kann ugesi ginn datt de Patroni alles richteg gemaach huet. Dat heescht, hien huet gemierkt datt hien den Zoustand vum Stärekoup net konnt erhalen an huet seng Autoritéit ewechgeholl.
An hei ass de Problem entstanen wéinst der Tatsaach, datt d'Konsul-Server op derselwechter Ausrüstung wéi d'Datebanke sinn. Deementspriechend all Laascht: sief et d'Laascht op Disken oder Prozessoren, et beaflosst och d'Interaktioun mam Consul Cluster.
A mir hunn décidéiert datt dëst net soll zesumme liewen, mir hunn e separaten Cluster fir de Consul zougewisen. An de Patroni huet scho mat engem separaten Consul geschafft, dat heescht et gouf e separaten Postgres-Cluster, e separaten Consul-Cluster. Dëst ass eng Basisinstruktioun fir all dës Saachen ze trennen an ze halen fir datt se net zesumme liewen.
Alternativ kënnt Dir d'Parameteren ttl, loop_wait, retry_timeout upassen, dh probéiert dës kuerzfristeg Belaaschtungspeaks ze iwwerliewen andeems Dir dës Parameteren erhéicht. Awer dëst ass net déi gëeegent Optioun, well dës Laascht ka laang dauerhaft sinn. A mir wäerten einfach iwwer dës Grenze vun dëse Parameteren goen. An dat kann net wierklech hëllefen.
Den éischte Problem, wéi Dir verstitt, ass einfach. Mir hunn den DCS geholl an et mat der Basis zesummegesat, a mir hunn e Problem.
Déi zweet Problem ass ähnlech wéi déi éischt. Et ass ähnlech datt mir erëm Probleemer hunn mam DCS System ze interagéieren.
Wa mir d'Logbicher kucken, wäerte mir gesinn datt mir erëm e Kommunikatiounsfehler hunn. A Patroni seet, ech kann net mat DCS interagéieren, sou datt den aktuelle Master an de Replika-Modus geet.
Den ale Meeschter gëtt eng Replik, hei funktionnéiert de Patroni wéi et soll. Et leeft pg_rewind fir den Transaktiounsprotokoll zréckzekréien an dann un den neie Meeschter ze verbannen, an dann mam neie Meeschter opzehuelen. Hei funktionnéiert de Patroni wéi et soll.
Hei musse mir d'Plaz fannen, déi dem Filer virugaang ass, dh déi Feeler, déi de Filer verursaacht hunn. An an dëser Hisiicht sinn Patroni Logbicher ganz bequem fir mat ze schaffen. Hie schreift déiselwecht Messagen a bestëmmten Intervalle. A wa mir ufänken séier duerch dës Logbicher ze scrollen, da wäerte mir aus de Logbicher gesinn datt d'Logbicher geännert hunn, dat heescht datt e puer Probleemer ugefaang hunn. Mir kommen séier op dës Plaz zréck a kucke wat geschitt.
An an enger normaler Situatioun kucken d'Logbicher sou eppes aus. De Besëtzer vun der Spär gëtt iwwerpréift. A wann de Besëtzer, soen, ännert, da kënnen e puer Eventer geschéien, op déi Patroni reagéiere muss. Awer an dësem Fall si mir alles richteg. Mir sichen no der Plaz wou d'Feeler ugefaang hunn.
A wann Dir op de Punkt scrollen wou Feeler ugefaang ze erschéngen, gesi mir datt mir en Autofileover hunn. A well eis Feeler mat der Interaktioun mat DCS verbonne sinn an an eisem Fall mir Consul benotzt hunn, kucke mir och d'Consul Logbicher fir ze kucken wat do geschitt ass.
Nodeems mir d'Zäit vum Filer an d'Zäit an de Consul Logbicher ongeféier verglach hunn, gesi mir datt eis Noperen am Consul Cluster ugefaang hunn d'Existenz vun anere Membere vum Consul Cluster ze zweifelen.
A wann Dir d'Logbicher vun anere Consul Agenten kuckt, kënnt Dir och gesinn datt do eng Zort Netzwierkkollaps geschitt. An all Membere vum Konsul-Cluster bezweifelen sech un d'Existenz vuneneen. An dat war den Impuls fir de Filier.
Wann Dir kuckt wat virun dëse Feeler geschitt ass, kënnt Dir gesinn, datt et all Zorte vu Feeler sinn, zum Beispill, Frist, RPC gefall, dh et ass kloer e Problem an der Interaktioun vun Consul Cluster Memberen mat all aner.
Déi einfachst Äntwert ass d'Netzwierk ze fixéieren. Awer um Podium stoen, ass et einfach fir mech dëst ze soen. Awer Ëmstänn sinn esou datt de Client net ëmmer leeschte kann d'Netz ze reparéieren. Hien kann am DC liewen a kann net d'Fäegkeet hunn d'Netzwierk ze reparéieren oder d'Ausrüstung ze beaflossen. An dofir sinn e puer aner Optiounen néideg.
Et gi Optiounen:
- Déi einfachst Optioun, déi geschriwwen ass, menger Meenung no, och an der Dokumentatioun, ass d'Konsulschecken auszeschalten, dat heescht einfach eng eidel Array passéieren. A mir soen dem Consul Agent keng Schecken ze benotzen. Duerch dës Kontrollen kënne mir dës Netzwierkstuerm ignoréieren an net e Filer initiéieren.
- Eng aner Optioun ass fir raft_multiplier ze duebel ze kontrolléieren. Dëst ass e Parameter vum Consul Server selwer. Par défaut ass et op 5 gesat. Dëse Wäert gëtt no der Dokumentatioun fir Staging-Ëmfeld recommandéiert. Wesentlech beaflosst dëst d'Frequenz vum Messageaustausch tëscht Membere vum Consul-Netz. Wesentlech beaflosst dëse Parameter d'Geschwindegkeet vun der offizieller Kommunikatioun tëscht Membere vum Consul-Cluster. A fir d'Produktioun ass et scho recommandéiert ze reduzéieren sou datt d'Noden méi dacks Messagen austauschen.
- Eng aner Optioun, déi mir ugefaang hunn ze benotzen, war d'Prioritéit vu Consul-Prozesser ënner anerem Prozesser fir de Betribssystem Prozessplaner ze erhéijen. Et gëtt sou e Parameter "schéin", et bestëmmt just d'Prioritéit vu Prozesser, déi vum OS Scheduler beim Planung berücksichtegt ginn. Mir hunn och de flotte Wäert fir Consul Agenten reduzéiert, d.h. erhéicht d'Prioritéit sou datt de Betribssystem Consul Prozesser méi Zäit gëtt fir ze schaffen an hire Code auszeféieren. An eisem Fall huet dëst eise Problem geléist.
- Eng aner Optioun ass de Consul net ze benotzen. Ech hunn e Frënd deen e grousse Supporter vun Etcd ass. An hien an ech streiden regelméisseg wat besser ass, Etcd oder Consul. Awer wat et besser ass, sinn hien an ech allgemeng d'accord datt de Consul en Agent huet deen op all Datebankknuet muss lafen. Dat ass, dem Patroni seng Interaktioun mam Consul-Cluster geschitt duerch dësen Agent. An dësen Agent gëtt e Flaschenhals. Wann eppes mam Agent geschitt, da kann de Patroni net méi mam Consul-Cluster schaffen. An dëst ass e Problem. Et gëtt keen Agent am Etcd Plang. Patroni kann direkt mat enger Lëscht vun Etcd Serveren Aarbecht a scho mat hinnen kommunizéieren. An dëser Hisiicht, wann Dir Etcd an Ärer Firma benotzt, da wäert Etcd wahrscheinlech eng besser Wiel sinn wéi Consul. Awer mat eise Clienten si mir ëmmer limitéiert duerch wat de Client gewielt huet a benotzt. A fir de gréissten Deel hunn all eis Clienten Consul.
- An de leschte Punkt ass d'Parameterwäerter ze iwwerdenken. Mir kënnen dës Parameteren méi héich erhéijen an der Hoffnung datt eis kuerzfristeg Netzwierkproblemer kuerz sinn an net am Beräich vun dëse Parameteren falen. Op dës Manéier kënne mir d'Agressivitéit vum Patroni reduzéieren fir en Autofileover auszeféieren wann Netzwierkproblemer entstinn.
Ech denken, datt vill, déi Patroni benotzen, si mat dësem Kommando vertraut.
Dëse Kommando weist den aktuellen Zoustand vum Cluster. An op den éischte Bléck kann dëst Bild normal schéngen. Mir hunn e Master, mir hunn eng Replik, et gëtt keng Replikatiounslag. Awer dëst Bild ass normal bis mir wëssen datt dëse Stärekoup dräi Wirbelen soll hunn, net zwee.
Deementspriechend ass en Autofileover geschitt. An no dësem Autofileover ass eis Replik verschwonnen. Mir mussen erausfannen firwat si verschwonnen ass an hir zréck bréngen, hir restauréieren. A mir ginn erëm an d'Logbicher a kucke firwat den Autofileover geschitt ass.
An dësem Fall gouf déi zweet Replica de Meeschter. Hei ass alles gutt.
A mir mussen d'Replique kucken, déi ofgefall ass an net am Cluster ass. Mir öffnen d'Patroni-Logbicher a gesinn datt mir e Problem op der pg_rewind-Bühn haten beim Uschloss un de Cluster. Fir un de Stärekoup ze verbannen, musst Dir den Transaktiounsprotokoll zréckrollen, den erfuerderleche Transaktiounsprotokoll vum Master ufroen a benotzt se fir de Master z'erreechen.
An dësem Fall hu mir keen Transaktiounsprotokoll an d'Replika kann net starten. Deementspriechend stoppen mir Postgres mat engem Feeler. An dofir ass et net am Cluster.
Mir mussen verstoen firwat et net am Stärekoup ass a firwat et keng Logbicher waren. Mir ginn op den neie Meeschter a kucke wat et a senge Logbicher huet. Et stellt sech eraus datt wann pg_rewind gemaach gouf, e Kontrollpunkt geschitt ass. An e puer vun den alen Transaktiounsprotokoller goufen einfach ëmbenannt. Wéi den alen Meeschter probéiert huet mat dem neie Meeschter ze verbannen an dës Logbicher ze froen, si si schonn ëmbenannt ginn, si sinn einfach net existéiert.
Ech hunn Zäitstempel verglach wann dës Evenementer geschitt sinn. An do ass den Ënnerscheed wuertwiertlech 150 Millisekonnen, dat heescht an 369 Millisekonnen war de Kontrollpunkt fäerdeg, d'WAL Segmenter goufen ëmbenannt. A wuertwiertlech um 517, 150 Millisekonnen méi spéit, Rewind ugefaangen op déi al Replica. Dat ass, wuertwiertlech 150 Millisekonnen war genuch fir eis ze verhënneren datt d'Replique verbënnt a funktionnéiert.
Wat sinn d'Optiounen?
Mir hunn am Ufank Replikatiounsslots benotzt. Mir hu geduecht et wier gutt. Obwuel an der éischter Etapp vun Operatioun mir de Plaze behënnert. Et huet eis geschéngt datt wann d'Plaze vill WAL Segmenter accumuléiert hunn, kënne mir de Meeschter falen. Hie wäert falen. Mir leiden fir eng Zäit ouni Plaze . A mir hu gemierkt datt mir Plaze brauchen, mir hunn d'Plazen zréckginn.
Mä et gëtt e Problem hei, datt wann de Meeschter op eng Replica plënnert, et läscht Plaze an, zesumme mat de Plaze läscht WAL Segmenter. A fir dëse Problem ze eliminéieren, hu mir décidéiert de wal_keep_segments Parameter ze erhéijen. Et ass Standard op 8 Segmenter. Mir hunn et op 1 erhéicht a gekuckt wéi vill fräi Plaz mir haten. A mir hunn 000 gigabytes un wal_keep_segments gespent. Dat ass, wann Dir wiesselt, hu mir ëmmer eng Reserve vu 16 Gigabytes Transaktiounsprotokoller op all Noden.
A plus - dat ass och relevant fir laangfristeg Ënnerhaltsaufgaben. Loosst eis soen datt mir ee vun de Repliken musse aktualiséieren. A mir wëllen et ausschalten. Mir mussen d'Software aktualiséieren, vläicht de Betribssystem, soss eppes. A wa mir eng Replica ausschalten, gëtt de Slot fir dës Replika och ewechgeholl. A wa mir kleng wal_keep_segments benotzen, dann, wann et e laange Fehlen vun enger Replik ass, ginn d'Transaktiounsprotokoller verluer. Mir wäerten eng Replica ophuelen, et wäert dës Transaktiounsprotokoller ufroen, wou se gestoppt hunn, awer si kënnen net um Master sinn. An d'Replique wäert och net fäeg sinn ze verbannen. Dofir halen mir e grousse Stock un Zäitschrëften.
Mir hunn eng Produktioun Basis. Projete schaffen do schonn.
E Filer ass geschitt. Mir sinn eragaangen a kucken - alles ass an der Rei, d'Repliken sinn op der Plaz, et gëtt keng Replikatiounslag. Et gi keng Feeler an de Logbicher, alles ass an der Rei.
D'Produktteam seet datt et schéngt wéi wann et e puer Donnéeën sollt sinn, awer mir gesinn et aus enger Quell, awer mir gesinn et net an der Datebank. A mir musse verstoen wat mat hinnen geschitt ass.
Et ass kloer datt pg_rewind se geläscht huet. Mir hunn dat direkt gemierkt, awer si sinn gaang fir ze kucken wat geschitt.
An de Logbicher kënne mir ëmmer fannen wéini de Filer geschitt ass, wien de Meeschter gouf, a mir kënne bestëmmen wien den ale Meeschter war a wéini hie wollt eng Replika ginn, dat heescht mir brauchen dës Logbicher fir de Volume vun Transaktiounsprotokoller erauszefannen déi war verluer.
Eisen ale Meeschter ass nei gestart. An de Patroni gouf am Autostart ugemellt. Patroni lancéiert. Hien huet dunn Postgres ugefaangen. Méi präzis, ier Dir Postgres ufänkt a ier et eng Replica gemaach huet, huet Patroni de pg_rewind Prozess gestart. Deementspriechend huet hien e puer vun den Transaktiounsprotokoller geläscht, nei erofgelueden a verbonnen. Hei huet de Patroni eng gutt Aarbecht gemaach, also wéi et soll sinn. Eise Cluster gouf restauréiert. Mir haten 3 Wirbelen, no der Filer waren et 3 Wirbelen - alles war cool.
Mir hunn e puer Daten verluer. A mir musse verstoen wéi vill mir verluer hunn. Mir sichen genau dee Moment wou mer e Rewind haten. Mir kënnen dat erausfannen aus dësen Journalen. rewind ugefaangen, eppes do gemaach an opgehalen.
Mir mussen d'Positioun am Transaktiounsprotokoll fannen, wou den ale Meeschter opgehalen huet. An dësem Fall ass et dës Mark. A mir brauchen eng zweet Mark, dh d'Distanz, duerch déi den alen Meeschter vun der neier ënnerscheet.
Mir huelen déi üblech pg_wal_lsn_diff a vergläichen dës zwee Marken. An an dësem Fall kréie mir 17 megabytes. Ob dat vill oder wéineg ass, entscheet jidderee fir sech. Well fir e puer sinn 17 Megabytes net vill, fir anerer ass et vill an inakzeptabel. Hei entscheet jidderee fir sech individuell no de Besoine vum Geschäft.
Awer wat hu mir selwer erausfonnt?
Als éischt musse mir fir eis selwer entscheeden - brauche mir ëmmer Patroni Autostart no engem System Neistart? Méi dacks geschitt et, datt mir bei den ale Meeschter musse goen, kucke wéi wäit hien fort ass. Kontrolléiert vläicht d'Transaktiounslog Segmenter, kuckt wat do ass. A verstitt ob mir dës Donnéeën verléieren kënnen oder ob mir den ale Meeschter am Standalone-Modus musse lafen fir dës Donnéeën ze recuperéieren.
An nëmmen duerno musse mir entscheeden ob mir dës Donnéeën ofginn oder mir kënnen se restauréieren, verbannen dësen Node als Replik un eise Stärekoup.
Zousätzlech gëtt et e Parameter "maximum_lag_on_failover". Par défaut, wann meng Erënnerung mech richteg déngt, huet dëse Parameter e Wäert vun 1 megabyte.
Wéi funktionéiert hien? Wann eis Replik 1 Megabyte vun Daten hannert der Replikatiounslag ass, da hëlt dës Replik net un de Wahlen deel. A wann op eemol e Filer geschitt, kuckt de Patroni op wéi eng Repliken hannendru sinn. Wann se hannert enger grousser Zuel vun Transaktioun Logbicher, si kënnen net Meeschtesch ginn. Dëst ass eng ganz gutt Sécherheetsfunktioun déi Iech verhënnert datt Dir vill Daten verléiert.
Awer et gëtt e Problem datt d'Replikatiounslag am Patroni an DCS Cluster mat engem gewëssen Intervall aktualiséiert gëtt. Ech mengen 30 Sekonnen ass de Standard ttl Wäert.
Deementspriechend kann et eng Situatioun sinn wou d'Replikatiounslag fir Repliken an DCS d'selwecht ass, awer tatsächlech kann et eng komplett aner Lag sinn oder et ka guer keng Lag sinn, dat heescht dës Saach ass net Echtzäit. An et reflektéiert net ëmmer dat richtegt Bild. An et ass net derwäert eng ausgefalene Logik doriwwer ze maachen.
An de Risiko vu Verloscht bleift ëmmer. An am schlëmmste Fall gëtt et eng Formel, an am Duerchschnëtt gëtt et eng aner Formel. Dat ass, wa mir d'Ëmsetzung vun Patroni plangen an schätzen wéi vill Donnéeën kënne mir verléieren, mir mussen op dës Formelen vertrauen an ongeféier virstellen wéi vill Donnéeën kënne mir verléieren.
An et gëtt gutt Noriicht. Wann den ale Meeschter virugaang ass, kann hien duerch e puer Hannergrondprozesser virugoen. Dat ass, et war eng Zort Autovakuum, et huet d'Donnéeën geschriwwen an se an den Transaktiounsprotokoll gespäichert. A mir kënnen dës Donnéeën einfach ignoréieren a verléieren. Et gëtt kee Problem mat dëser.
An dëst ass wéi d'Logbicher ausgesinn wann maximum_lag_on_failover agestallt ass an e Fileover geschitt, an Dir musst en neie Master auswielen. D'Replique bewäert sech als net fäeg un de Wahlen deelzehuelen. A si refuséiert un der Course fir d'Leedung deelzehuelen. A si waart op en neie Meeschter fir ausgewielt ze ginn, fir datt se dann mat him konnektéieren. Dëst ass eng zousätzlech Moossnam géint Dateverloscht.
Hei huet eis Produktteam geschriwwen datt hiert Produkt Probleemer erliewt wann se mat Postgres schaffen. Zur selwechter Zäit kënnt Dir net op de Master selwer kommen, well et net iwwer SSH zougänglech ass. An autofileover geschitt och net.
Dëse Host gouf zu engem Neistart gezwongen. Wéinst dem Neistart ass en Autofileover geschitt, obwuel et och méiglech war e manuellen Autofileover ze maachen, wéi ech elo verstinn. An nom Restart gi mir kucken wat mir mam aktuelle Master haten.
Zur selwechter Zäit woussten mir am Viraus datt mir Probleemer mat den Disken haten, dat heescht, mir woussten scho vun der Iwwerwaachung wou mir graven a wat mir sichen.
Mir koumen an de Postgres Logbuch an hunn ugefaang ze kucken wat do geschitt ass. Mir hunn Verpflichtungen gesinn déi eng, zwou oder dräi Sekonnen gedauert hunn, wat guer net normal ass. Mir hunn gesinn datt eisen Autovakuum eng ganz laang a komesch Zäit dauert fir opzemaachen. A mir hunn temporär Dateien op der Disk gesinn. Dat ass, dëst sinn all Indikatoren fir Probleemer mat Disken.
Mir hunn an de System dmesg (Nuklear Message Log) gekuckt. A mir hu gesinn, datt mir Problemer mat engem vun de Scheiwen haten. D'Disk Subsystem war eng Software Razzia. Mir hunn op /proc/mdstat gekuckt a gesinn datt mir eng Scheif fehlen. Dat ass, et gëtt e Razzia vun 8 Scheiwen, mir fehlen een. Wann Dir no der Rutsch kuckt, kënnt Dir am Ausgang gesinn datt mir do net sde hunn. Eis Scheif, relativ gesinn, ass erausgefall. Dëst huet Diskproblemer ausgeléist, an Uwendungen hunn och Probleemer erlieft wann Dir mam Postgres-Cluster geschafft hutt.
An an dësem Fall géif Patroni eis op keng Manéier hëllefen, well Patroni net d'Aufgab huet den Zoustand vum Server, den Zoustand vun der Disk ze iwwerwaachen. A mir mussen esou Situatiounen mat externen Iwwerwaachung iwwerwaachen. Mir hunn operationell Disk Iwwerwachung op extern Iwwerwaachung bäigefüügt.
An et war dëse Gedanken - kéint Fechter oder Iwwerwaachungssoftware eis hëllefen? Mir hu geduecht datt et onwahrscheinlech wier datt hien eis an dësem Fall gehollef hätt, well während de Probleemer de Patroni weider mam DCS-Cluster interagéiert huet an kee Problem gesinn huet. Dat ass, aus der Siicht vun DCS a Patroni, alles war gutt mam Cluster, obwuel et tatsächlech Probleemer mat der Disk waren, et waren Probleemer mat der Disponibilitéit vun der Datebank.
Menger Meenung no ass dëst ee vun de komeschste Probleemer, déi ech fir eng ganz laang Zäit recherchéiert hunn, vill Logbicher nei gelies hunn, domat geschwat hunn an et e Clustersimulator genannt hunn.
De Problem war, datt den ale Meeschter net eng normal Replica ginn kéint, dh Patroni lancéiert et, Patroni gewisen, datt dëst Node als Replica präsent war, mä an der selwechter Zäit war et net eng normal Replica. Elo wäert Dir gesinn firwat. Ech hunn dat behalen fir dee Problem ze analyséieren.
A wou huet dat alles ugefaang? Et huet ugefaang, wéi am virege Problem, mat Scheibenbremsen. Mir haten eng Sekonn gläichzäiteg engagéiert, zwee gläichzäiteg.
Et goufe Verbindungspaus, dh Cliente goufen ofgeschalt.
Et goufen Blockaden vu variéierter Gravitéit.
An deementspriechend ass den Disk Subsystem net ganz reaktiounsfäeger.
An déi mysteriéisst Saach fir mech ass déi direkt Ofschlossufro déi ukomm ass. Postgres huet dräi Shutdown Modi:
- Et ass graziéis wa mir op all Client waarden fir eleng ze trennen.
- Et gëtt séier, wa mir Clienten forcéieren ze trennen well mir ausschalten.
- An direkt. An dësem Fall seet direkt de Clienten net emol auszeschléissen, et schléisst just ouni Warnung aus. An de Betribssystem schéckt e RST Message un all Clienten (TCP Message datt d'Verbindung ënnerbrach ass an de Client näischt méi ze fangen huet).
Wien huet dëst Signal geschéckt? Hannergrond Postgres Prozesser schécken net sou Signaler uneneen, dh dëst ass e Kill-9. Si schécken dat net géigesäiteg, si reagéieren nëmmen op dëst, dat heescht dat ass en Nout-Restart vu Postgres. Ech weess net wien hien geschéckt huet.
Ech hunn de "leschte" Kommando gekuckt an ech hunn eng Persoun gesinn, déi och bei eis op dëse Server ageloggt ass, awer ech war ongenéiert fir eng Fro ze stellen. Vläicht war et ëmbréngen -9. Ech géif Kill -9 an de Logbicher gesinn, well ... Postgres seet et akzeptéiert ëmbréngen -9, mee ech hunn et net an de Logbicher gesinn.
Wann ech weider kucken, hunn ech gesinn datt de Patroni net laang an de Logbuch geschriwwen huet - 54 Sekonnen. A wann Dir déi zwee Zäitstempel vergläicht, goufen et ongeféier 54 Sekonnen keng Messagen.
A während dëser Zäit ass en Autofileover geschitt. Patroni huet hei erëm super geschafft. Eisen ale Meeschter war net erreechbar, him ass eppes geschitt. An d'Wiel vun engem neie Meeschter huet ugefaang. Hei huet alles gutt geklappt. Eis pgsql01 ass eisen neie Leader ginn.
Mir hunn eng Replica déi e Meeschter ginn ass. An et gëtt eng zweet Replica. An et goufe Problemer mat der zweeter Remarque. Si huet probéiert nei ze konfiguréieren. Wéi ech et verstinn, huet si probéiert d'Erhuelung.conf z'änneren, Postgres nei ze starten a mam neie Meeschter ze verbannen. Si SMSen all 10 Sekonnen datt si probéiert, awer hatt ass net erfollegräich.
A während dëse Versuche kënnt en direkt-Shutdown-Signal op den ale Meeschter. De Meeschter fänkt nei un. An och d'Erhuelung stoppt well den ale Meeschter an d'Restart geet. Dat ass, d'Replika kann net mat him verbannen, well et am Shutdown-Modus ass.
Irgendwann huet et geschafft, awer d'Replikatioun huet net ugefaang.
Déi eenzeg Hypothes déi ech hunn ass datt d'Erhuelung.conf d'Adress vum ale Meeschter enthält. A wann en neie Meeschter erschéngt, huet déi zweet Replik nach ëmmer probéiert mat dem ale Meeschter ze verbannen.
Wéi de Patroni op der zweeter Replika ugefaang huet, huet de Node ugefaang, awer konnt net iwwer Replikatioun verbannen. An eng Replikatiounslag ass geformt, déi sou eppes ausgesinn huet. Dat ass, all dräi Node waren op der Plaz, awer den zweeten Node war hannendrun.
Zur selwechter Zäit, wann Dir d'Logbicher kuckt, déi geschriwwe goufen, kënnt Dir gesinn datt d'Replikatioun net konnt starten, well d'Transaktiounsprotokoller anescht waren. An d'Transaktiounsprotokoller déi de Wizard ubitt, déi an recovery.conf opgelëscht sinn, sinn einfach net gëeegent fir eisen aktuellen Node.
An hei hunn ech e Feeler gemaach. Ech hu misse kucke kommen, wat do an der Erhuelung.conf fir meng Hypothes ze testen, datt mir un de falsche Meeschter verbonne sinn. Awer ech hunn et deemools just erausfonnt an et ass mir net opgetrueden, oder ech hunn gesinn datt d'Replique hannendrun war a misst erëm gefëllt ginn, dat heescht ech hunn et iergendwéi suergfälteg ausgeschafft. Dëst war meng Këscht.
No 30 Minutten ass den Admin ukomm, dh ech hunn de Patroni op der Replica nei gestart. Ech hat et schonn opginn, ech hu geduecht, et misst nach opfëllen. An ech hu geduecht, ech wäert de Patroni nei starten, vläicht kënnt eppes Gutt eraus. Erhuelung ugefaang. An d'Basis souguer opgemaach, et war prett Verbindungen ze akzeptéieren.
Replikatioun huet ugefaang. Awer eng Minutt méi spéit ass et mat engem Feeler erofgefall datt Transaktiounsprotokoller net passend waren.
Ech hu geduecht, ech géif erëm nei starten. Ech hunn Patroni nei gestart, an ech hunn Postgres net nei gestart, awer Patroni nei gestart an der Hoffnung datt et d'Datebank magesch lancéiert.
D'Replikatioun huet erëm ugefaang, awer d'Noten am Transaktiounsprotokoll waren anescht, si waren net déiselwecht wéi déi, déi am virege Versuch waren ze starten. D'Replikatioun ass erëm gestoppt. An de Message war liicht anescht. An et war net besonnesch informativ fir mech.
An da geschitt et mir - wat wann ech Postgres nei starten, zu dëser Zäit maachen ech e Checkpoint op den aktuelle Master fir de Punkt am Transaktiounsprotokoll e bëssen no vir ze réckelen, sou datt d'Erhuelung vun engem anere Moment ufänkt? Plus hu mir nach WAL Reserven do.
Ech hunn Patroni nei gestart, e puer Kontrollpunkten op de Meeschter gemaach, e puer Restartpunkten op der Replica wann et opgemaach gouf. An et huet gehollef. Ech hu laang an haart geduecht firwat et gehollef huet a wéi et funktionnéiert. An d'Replique huet ugefaang. An d'Replikatioun ass net méi gescheitert.
Dëse Problem ass ee vun de méi mysteriéise fir mech, iwwer déi ech nach ëmmer iwwerraschen iwwer wat eigentlech do geschitt ass.
Wat sinn d'Conclusiounen hei? Patroni ka funktionnéieren wéi virgesinn an ouni Feeler. Awer gläichzäiteg ass dëst keng 100% Garantie datt alles gutt ass mat eis. D'Replique kann ufänken, awer et kann an engem semi-schaffen Zoustand sinn, an d'Applikatioun kann net mat esou enger Replica funktionnéieren, well et al Donnéeën do gëtt.
An nom Fileover musse mir ëmmer kucken ob alles gutt ass mam Cluster, dh mir hunn déi erfuerderlech Unzuel u Repliken an et gëtt keng Replikatiounslag.
A wéi mir dës Problemer betruechten, wäert ech Empfehlungen formuléieren. Ech hu probéiert se an zwee Rutschen ze kombinéieren. Wahrscheinlech hätten all d'Geschichten an zwee Rutschen kombinéiert an nëmmen erzielt.
Wann Dir Patroni benotzt, musst Dir Iwwerwaachung hunn. Dir sollt ëmmer wëssen wéini en Autofileover geschitt ass, well wann Dir net wësst datt Dir en Autofileover hat, sidd Dir net an der Kontroll vum Cluster. An dat ass schlecht.
No all Classeuren, mir sollen ëmmer manuell de Stärekoup kontrolléieren. Mir musse sécherstellen datt mir ëmmer eng aktuell Zuel vu Repliken hunn, et gëtt keng Replikatiounslag, an et gi keng Feeler an de Logbicher am Zesummenhang mat Streaming Replikatioun, Patroni oder dem DCS System.
Automatioun kann erfollegräich funktionnéieren, Patroni ass e ganz gutt Tool. Et kann funktionnéieren, awer et bréngt de Stärekoup net an de gewënschten Zoustand. A wa mir et net wëssen, da wäerte mir Problemer hunn.
A Patroni ass keng Sëlwerkugel. Mir mussen nach ëmmer e Verständnis hunn wéi Postgres funktionnéiert, wéi Replikatioun funktionnéiert a wéi Patroni mat Postgres funktionnéiert a wéi d'Kommunikatioun tëscht Noden erreecht gëtt. Dëst ass néideg fir Problemer mat Ären Hänn ze fixéieren.
Wéi kommen ech d'Thema vun der Diagnostik un? Et ass geschitt, datt mir mat verschiddene Clienten schaffen a keen huet en ELK Stack, a mir mussen d'Logbicher verstoen andeems Dir 6 Konsolen an 2 Tabs opmaacht. An engem Tab sinn et Patroni Logbicher fir all Node, an der anerer Tab sinn et Consul Logbicher, oder Postgres Logbicher wann néideg. Et ass ganz schwéier ze diagnostizéieren.
Wéi eng Approche hunn ech entwéckelt? Als éischt kucken ech ëmmer wann de Filer ukomm ass. A fir mech ass dëst eng Zort Waasserdeel. Ech kucken op wat virum Filer geschitt ass, während dem Filer, an nom Filer. De Fileover huet zwee Marken: dëst ass d'Start- an d'Ennzäit.
Als nächst kucken ech an de Logbicher op d'Evenementer virum Filer, deen dem Filer virugaang ass, dh ech kucken no de Grënn firwat de Filer geschitt ass.
An dëst gëtt e Bild fir ze verstoen wat geschitt ass a wat an Zukunft ka gemaach ginn fir esou Ëmstänn ze verhënneren (an als Resultat ass e Fileover net geschitt).
A wou kucke mer normalerweis? Ech kucken:
- Éischt an de Patroni Logbicher.
- Als nächst kucken ech op d'Postgres Logbicher oder d'DCS Logbicher, jee no deem wat an de Patroni Logbicher fonnt gouf.
- An de System Logbicher ginn och heiansdo e Verständnis vu wat de Filer verursaacht huet.
Wéi fille mech iwwer Patroni? Ech fille mech ganz gutt iwwer Patroni. Menger Meenung no ass dat dat Bescht wat et haut gëtt. Ech kennen vill aner Produkter. Dëst sinn Stolon, Repmgr, Pg_auto_failover, PAF. 4 Tools. Ech hunn se all probéiert. Ech hunn de Patroni am meeschte gär.
Wa se mech froen: "Recommandéieren ech Patroni?" Ech soen jo, well ech Patroni gär hunn. An ech mengen ech geléiert wéi et ze kachen.
Wann Dir interesséiert sidd ze kucken wat fir aner Probleemer et mam Patroni sinn, nieft de Problemer déi ech gesot hunn, kënnt Dir ëmmer op d'Säit goen op GitHub. Et gi vill verschidde Geschichten a vill interessant Problemer ginn do diskutéiert. An als Resultat goufen e puer Bugs agefouert a geléist, dat heescht dat ass eng interessant Liesung.
Et ginn interessant Geschichten do iwwer Leit, déi sech selwer an de Fouss schéisse kënnen. Ganz informativ. Dir liest a verstitt datt Dir dëst net maache musst. Ech hu mech gekickt.
An ech géif gären e grousse Merci un d'Zalando Firma fir d'Entwécklung vun dësem Projet soen, nämlech dem Alexander Kukushkin an Alexey Klyukin. Den Alexey Klyukin ass ee vun de Co-Auteuren; hien schafft net méi bei Zalando, awer dëst sinn zwee Leit, déi mat dësem Produkt ugefaang hunn.
An ech mengen Patroni ass eng ganz cool Saach. Ech si frou datt hatt existéiert, et ass interessant mat hatt ze sinn. A villmools Merci un all d'Bäiträg, déi Patches op Patroni schreiwen. Ech hoffen, datt de Patroni mat Alter méi reift, cool a kapabel gëtt. Et ass schonn efficace, mee ech hoffen, datt et nach besser gëtt. Also wann Dir plangt Patroni an Ärem Heem ze benotzen, fäert net. Dëst ass eng gutt Léisung, et kann ëmgesat a benotzt ginn.
Dat ass alles. Wann Dir Froen hutt, frot w.e.g.
Är Froen
Merci fir de Bericht! Wann Dir nom Filer nach ëmmer ganz virsiichteg muss kucken, firwat brauche mir dann en automateschen Filer?
Well et ass eng nei Saach. Mir schaffe just zënter engem Joer mat hatt. Besser et sécher ze spillen. Mir wëllen eran kommen a kucken datt alles wierklech funktionnéiert wéi et soll. Dëst ass den Niveau vum Mësstrauen fir Erwuessener - et ass besser ze kontrolléieren a kucken.
Zum Beispill si mir de Moien era komm a gekuckt, oder?
Net moies gewuer mir normalerweis iwwer autofileover bal direkt. Mir kréien Notifikatiounen, mir gesinn datt en Autofileover geschitt ass. Mir gi bal direkt eran a kucke mer. Awer all dës Kontrollen mussen op den Iwwerwaachungsniveau bruecht ginn. Wann Dir op Patroni iwwer de REST API zougitt, gëtt et Geschicht. Mat der Geschicht kënnt Dir d'Zäitstempel kucken wéi d'Datei erofgeluede gouf. Baséierend op deem kann Iwwerwaachung gemaach ginn. Dir kënnt d'Geschicht kucken fir ze kucken wéi vill Eventer et waren. Wa mir méi Eventer hunn, heescht et datt en Autofileover geschitt ass. Dir kënnt goen a kucken. Oder eis Iwwerwaachungsautomatioun huet gepréift datt mir all Repliken op der Plaz hunn, et gëtt keng Lag an alles ass gutt.
Merci!
Villmols Merci fir eng flott Geschicht! Wa mir den DCS Cluster iergendwou wäit ewech vum Postgres Cluster geplënnert hunn, muss dëse Cluster och periodesch servéiert ginn? Wat sinn déi bescht Praktiken an datt e puer Deeler vum DCS Stärekoup musse ausgeschalt ginn, eppes soll mat hinnen gemaach ginn, etc.? Wéi leeft dës ganz Struktur? A wéi dës Saachen ze maachen?
Fir eng Firma war et néideg eng Problemmatrix ze kreéieren wat geschitt wann een oder méi Komponenten ausfalen. Mat dëser Matrix gi mir sequenziell duerch all d'Komponenten a bauen Szenarien am Fall vun engem Ausfall vun dëse Komponenten. Deementspriechend, fir all Echec Szenario, kënnt Dir en Aktiounsplang fir Erhuelung hunn. An am Fall vun DCS kënnt dëst als Deel vun der Standardinfrastruktur. An den Administrateur verwalt et, a mir vertrauen schonn op d'Administrateuren, déi et verwalten an op seng Fäegkeet et am Fall vun Katastrophen ze fixéieren. Wann et guer keen DCS ass, da setze mir et aus, awer mir iwwerwaachen et net besonnesch, well mir sinn net verantwortlech fir d'Infrastruktur, awer mir ginn Empfehlungen wéi a wat ze iwwerwaachen.
Dat ass, hunn ech richteg verstanen datt ech Patroni auszeschalten muss, de Filer auszeschalten, alles deaktivéieren ier ech eppes mat de Hosten maachen?
Et hänkt dovun of wéivill Noden mir am DCS-Cluster hunn. Wann et vill Wirbelen sinn a wa mir nëmmen ee vun de Wirbelen ausschalten (d'Replika), da gëtt e Quorum am Cluster erhale gelooss. A Patroni bleift operationell. An näischt gëtt ausgeléist. Wa mir e puer komplex Operatiounen hunn, déi méi Wirbelen beaflossen, d'Feele vun deenen de Quorum zerstéieren kéint, da jo, vläicht mécht et Sënn fir Patroni ze pausen. Et huet en entspriechend Kommando - patronictl Paus, patronictl resume. Mir pausen et einfach, an den Autofileover funktionnéiert net zu dëser Zäit. Mir maachen Ënnerhalt op der DCS Stärekoup, dann ewechzehuelen der Paus a weider mat Liewen.
Villmols Merci!
Villmols Merci fir de Bericht! Wéi fillt d'Produktteam iwwer d'Verléierer vun Daten?
Produit Équipë ginn net e Verdammt, mee Equipe féiert si besuergt.
Wéi eng Garantien ginn et?
Et ass ganz schwéier mat Garantien. Den Alexander Kukushkin huet e Bericht "Wéi Berechent RPO an RTO", dh Erhuelung Zäit a wéi vill Daten kënne mir verléieren. Ech mengen, mir mussen dës Rutschen fannen an se studéieren. Sou wäit wéi ech mech erënneren, ginn et spezifesch Schrëtt op wéi dës Saachen ze berechnen. Wéi vill Transaktioune kënne mir verléieren, wéi vill Daten kënne mir verléieren. Als Optioun kënne mir synchron Replikatioun um Patroni Niveau benotzen, awer dëst ass en duebelschneidegt Schwert: mir hunn entweder Datenverlässegkeet oder verléieren Geschwindegkeet. Et gëtt synchron Replikatioun, awer et garantéiert och net 100% Schutz géint Dateverloscht.
Alexey, Merci fir dee wonnerbare Bericht! All Erfahrung mat Patroni fir null Niveau Schutz? Dat ass, a Kombinatioun mat Synchron-Standby? Dëst ass déi éischt Fro. An déi zweet Fro. Dir hutt verschidde Léisunge benotzt. Mir hunn Repmgr benotzt, awer ouni Autofileover a plangen elo en Autofileover z'aktivéieren. A mir betruechten Patroni als alternativ Léisung. Wat kënnt Dir soen, sinn d'Virdeeler am Verglach mat Repmgr?
Déi éischt Fro war iwwer Synchron Repliken. Keen benotzt hei Synchron Replikatioun, well jidderee Angscht huet (Verschidde Cliente benotzen et scho, si hu guer keng Leeschtungsproblemer gemierkt - Speaker's Note). Awer mir hunn eng Regel fir eis selwer entwéckelt datt an engem synchrone Replikatiounscluster op d'mannst dräi Wirbelen musse sinn, well wa mir zwee Wirbelen hunn a wann de Master oder d'Replique feelt, da schalt de Patroni dësen Node op de Standalone Modus sou datt d'Applikatioun weider geet schaffen. An dësem Fall besteet e Risiko fir Datenverloscht.
Wat déi zweet Fro ugeet, hu mir Repmgr benotzt a maachen nach ëmmer fir e puer Clienten aus historesche Grënn. Wat kënne mir soen? Am Patroni kënnt Autofileover aus der Këscht; am Repmgr kënnt Autofileover als zousätzlech Feature déi aktivéiert muss ginn. Mir mussen Repmgr Daemon op all Node lafen an da kënne mir den Autofileover konfiguréieren.
Repmgr kontrolléiert ob Postgres Noden lieweg sinn. Repmgr Prozesser kontrolléieren d'Existenz vuneneen, dëst ass net eng ganz effizient Approche well Et kënne komplexe Fäll vun der Netzisolatioun sinn, an deenen e grousse Repmgr-Cluster an e puer kleng briechen kann a weider schaffen. Ech hunn Repmgr net laang gefollegt, vläicht ass dëst fixéiert ... oder vläicht net. Awer Informatioun iwwer den Zoustand vum Stärekoup op DCS iwwerdroen, wéi Stolon a Patroni maachen, ass déi liewensfäegst Optioun.
Alexey, ech hunn eng Fro déi lächerlech ka sinn. An engem vun den éischte Beispiller hutt Dir DCS vun der lokaler Maschinn op e Remote Node geplënnert. Mir verstinn datt d'Netz eng Saach ass déi seng eege Charakteristiken huet; et lieft eleng. A wat geschitt wann aus iergendengem Grond den DCS-Cluster net verfügbar ass? Ech wäert d'Grënn net soen, et ka vill vun hinnen sinn: vun de kromme Hänn vun Netzwierker bis zu echte Probleemer.
Ech hunn et net haart gesot, awer den DCS-Cluster muss och Feelertolerant sinn, dat heescht datt et eng komesch Zuel vu Wirbelen huet fir datt e Quorum geschitt. Wat geschitt wann den DCS Stärekoup net erreechbar gëtt oder e Quorum net erreecht ka ginn, dat heescht eng Zort Netzwierksplit oder Node Echec? An dësem Fall geet de Patroni-Cluster an de Liesmodus. De Patroni-Cluster kann den Zoustand vum Stärekoup net bestëmmen a wat ze maachen. Et kann net DCS kontaktéieren an den neie Stärekoup Staat do späicheren, sou datt de ganze Stärekoup an de Liesmodus geet. A waart entweder op manuell Interventioun vum Bedreiwer oder op DCS restauréiert.
Grof geschwat gëtt DCS fir eis e sou wichtege Service wéi d'Datebank selwer?
Jo Jo. A ville modernen Firmen ass Service Discovery en integralen Deel vun der Infrastruktur. Et gëtt ëmgesat och ier et iwwerhaapt eng Datebank an der Infrastruktur gouf. Relativ gesinn hu mir d'Infrastruktur lancéiert, se op den DC ofgesat, a mir hunn direkt Service Discovery. Wann dëst Consul ass, da kann DNS drop gebaut ginn. Wann dëst Etcd ass, da kann et en Deel vum Kubernetes Cluster sinn, an deem alles anescht agesat gëtt. Et schéngt mir datt Service Discovery schonn en integralen Deel vun modernen Infrastrukturen ass. A si denken doriwwer vill méi fréi wéi Datenbanken.
Merci!
Source: will.com