Patroni Failure Stories o Com bloquejar el vostre clúster PostgreSQL. Alexei Lesovski

L'objectiu principal de Patroni és proporcionar alta disponibilitat per a PostgreSQL. Però Patroni és només una plantilla, no una eina ja feta (que, en general, és el que diu la documentació). A primera vista, després d'haver configurat Patroni al laboratori de proves, podeu veure quina meravellosa eina és i amb quina facilitat gestiona els nostres intents de destruir el clúster. No obstant això, a la pràctica en un entorn de producció, no sempre passa tot de manera tan bella i elegant com en un laboratori de proves.

Us parlaré una mica de mi. Vaig començar com a administrador de sistemes. Ha treballat en desenvolupament web. Treballo a Data Egret des del 2014. L'empresa es dedica a la consultoria en el camp de Postgres. I donem servei a Postgres específicament, i treballem amb Postgres cada dia, de manera que tenim una gran varietat d'experiència operativa.

I a finals del 2018, a poc a poc vam començar a utilitzar Patroni. I s'ha acumulat una experiència específica. D'alguna manera el vam diagnosticar, el vam ajustar i vam arribar a les nostres millors pràctiques. I en aquest reportatge en parlaré.

A més de Postgres, m'encanta Linux. M'encanta mirar-ho i explorar-lo, m'encanta recollir nuclis. M'encanta la virtualització, els contenidors, Docker, Kubernetes. Tot això m'interessa, perquè els vells hàbits administratius estan passant factura. M'encanta entendre el seguiment. I m'encanten les coses de postgres relacionades amb l'administració, és a dir, la rèplica, la còpia de seguretat. I en el meu temps lliure escric a Go. No sóc enginyer de programari, només escric a Go per mi mateix. I em dóna plaer.

• Crec que molts de vosaltres sabeu que Postgres no té HA (alta disponibilitat) fora de la caixa. Per obtenir HA, cal posar alguna cosa, configurar-la, esforçar-se i aconseguir-la.
• Hi ha diverses eines i Patroni és una d'elles, que resol l'HA força maco i molt bé. Però posant-ho tot en un laboratori de proves i executant-lo, podem veure que tot funciona, podem reproduir alguns problemes, veure com Patroni els dóna servei. I veurem que tot funciona molt bé.
• Però a la pràctica ens hem trobat amb diferents problemes. I parlaré d'aquests problemes.
• Us explicaré com el vam diagnosticar, què vam modificar, si ens va ajudar o no.

• No us diré com instal·lar Patroni, perquè el podeu buscar a Google a Internet, podeu mirar els fitxers de configuració per entendre com comença tot i com es configura. Podeu entendre els diagrames i les arquitectures trobant informació sobre això a Internet.
• No parlaré de les experiències d'altres persones. Només parlaré dels problemes que hem tingut.
• I no parlaré dels problemes que estan fora de Patroni i PostgreSQL. Si, per exemple, hi ha problemes relacionats amb l'equilibri quan el nostre clúster es va col·lapsar, no en parlaré.

I una petita exempció de responsabilitat abans de començar el nostre informe.

Tots aquests problemes que vam trobar, els vam tenir en els primers 6-7-8 mesos de funcionament. Amb el temps, vam arribar a les nostres pròpies bones pràctiques internes. I els nostres problemes van desaparèixer. Per tant, l'informe es va presentar fa uns sis mesos, quan estava tot fresc al meu cap i ho recordava perfectament.

Durant l'elaboració de l'informe, ja vaig recollir autopsies antigues i vaig mirar els registres. I alguns dels detalls poden haver-se oblidat, o alguns dels detalls no s'han explorat completament durant l'anàlisi dels problemes, de manera que en alguns moments pot semblar que els problemes no s'han considerat del tot, o hi ha algun tipus de manca d'informació. I per això et demano que em perdonis per aquest moment.

Què és Patroni?

• Aquesta és una plantilla per crear HA. Això és el que diu a la documentació. I des del meu punt de vista, aquest és un aclariment molt correcte. Patroni no és una bala de plata que resolgui tots els teus problemes, és a dir, has de fer un esforç perquè comenci a funcionar i sigui útil.
• Aquest és un servei d'agent que s'instal·la a cada servei amb una base de dades, i que és una mena de sistema d'inici per al vostre Postgres. Inicia Postgres, l'atura, el reinicia, canvia la configuració i canvia la topologia del vostre clúster.
• En conseqüència, per emmagatzemar l'estat del clúster, la seva representació actual, com es veu, cal algun tipus d'emmagatzematge. I des d'aquest punt de vista, Patroni va prendre el camí de l'emmagatzematge de l'estat en un sistema extern. És un sistema d'emmagatzematge de configuració distribuït. Això podria ser Etcd, Consul, ZooKeeper o kubernetes Etcd, és a dir, una d'aquestes opcions.
• I una de les característiques de Patroni és que treu el fitxer automàtic de la caixa, només després de configurar-lo. Si prenem Repmgr per comparar, el fitxer s'inclou allà. Amb Repmgr aconseguim la commutació, però si volem un fitxer automàtic, s'ha de configurar més. Patroni ja té un fitxer automàtic fora de la caixa.
• I hi ha moltes altres coses més. Per exemple, mantenir configuracions, afegir noves rèpliques, còpies de seguretat, etc. Però això està fora de l'abast de l'informe, no en parlaré.

I un petit resultat és que la tasca principal de Patroni és fer un autofileover de manera correcta i fiable perquè el nostre clúster continuï operatiu i l'aplicació no noti canvis en la topologia del clúster.

Però quan comencem a utilitzar Patroni, el nostre sistema es torna una mica més complex. Si abans teníem Postgres, quan utilitzem Patroni obtenim el propi Patroni, obtenim DCS, on s'emmagatzema l'estat. I tot ha de funcionar d'alguna manera. Per tant, què es pot trencar?

Trencament de maig:

• Postgres pot trencar-se. Podria ser un mestre o una rèplica, un d'ells podria fallar.
• El propi Patroni pot trencar-se.
• El DCS, on s'emmagatzema l'estat, pot trencar-se.
• I la xarxa pot trencar-se.

Tindré en compte tots aquests punts a l'informe.

Consideraré els casos a mesura que es facin més complexos, no des del punt de vista que un cas impliqui molts components. I des del punt de vista dels sentiments subjectius, aquest cas era complex per a mi, costava desmuntar... i viceversa, algun cas era lleuger i fàcil de desmuntar.

I el primer cas és el més senzill. Aquest és el cas quan vam agafar un clúster de bases de dades i vam desplegar el nostre emmagatzematge DCS al mateix clúster. Aquest és l'error més comú. Aquest és un error a l'hora de construir arquitectures, és a dir, combinar diferents components en un sol lloc.

Així que, va passar un fitxer, anem a esbrinar què va passar.

I aquí ens interessa quan es va produir el fitxer. És a dir, ens interessa aquest moment en el temps en què l'estat del clúster va canviar.

Però el fitxer no sempre és instantani, és a dir, no necessita una determinada unitat de temps, pot allargar-se. Pot ser de llarga durada.

Per tant, té una hora d'inici i una de finalització, és a dir, és un esdeveniment continu. I dividim tots els esdeveniments en tres intervals: tenim temps abans del fitxer, durant el fitxer i després del fitxer. És a dir, tenim en compte tots els esdeveniments d'aquesta línia de temps.

I, en primer lloc, quan es va produir un fitxer, busquem el motiu, què va passar, què va provocar el que va conduir al fitxer.

Si mirem els registres, aquests són els clàssics registres de Patroni. En elles ens diu que el servidor s'ha convertit en mestre, i el paper del mestre ha passat a aquest node. Es destaca aquí.

A continuació, hem d'entendre per què es va produir el fitxer, és a dir, quins esdeveniments es van produir que van fer que el rol mestre es mogués d'un node a un altre. I en aquest cas tot és senzill. Tenim un error en interactuar amb el sistema d'emmagatzematge. El mestre es va adonar que no podia treballar amb DCS, és a dir, hi havia algun problema amb la interacció. I diu que ja no pot ser mestre i dimiteix. Aquesta línia "jo degradat" diu exactament això.

Si ens fixem en els esdeveniments que van precedir el fitxer, podem veure-hi els mateixos motius que van servir de problema per a la continuació del treball del màster.

Si mirem els registres de Patroni, veurem que tenim molts errors i temps d'espera, és a dir, l'agent de Patroni no pot treballar amb DCS. En aquest cas, es tracta de l'agent Cònsol, amb el qual es comunica al port 8500.

I el problema aquí és que Patroni i la base de dades s'executen al mateix host. I els servidors Cònsol es van llançar al mateix node. En crear una càrrega al servidor, vam crear problemes per als servidors de Cònsol. No podien comunicar-se amb normalitat.

Al cap d'un temps, quan la càrrega va disminuir, el nostre Patroni va poder tornar a comunicar-se amb els agents. S'ha reprès la feina normal. I el mateix servidor Pgdb-2 va tornar a ser el mestre. És a dir, hi va haver un petit flip, a causa del qual el node va renunciar als seus poders com a mestre i després els va agafar de nou, és a dir, tot va tornar com estava.

I això es pot considerar com un fals positiu, o es pot considerar que Patroni ho va fer tot bé. És a dir, es va adonar que no podia mantenir l'estat del clúster i va treure la seva autoritat.

I aquí el problema va sorgir pel fet que els servidors Cònsol es troben al mateix equip que les bases de dades. En conseqüència, qualsevol càrrega: sigui la càrrega en discs o processadors, també afecta la interacció amb el clúster Consul.

I vam decidir que això no hauria de conviure, vam assignar un clúster separat per al cònsol. I Patroni ja treballava amb un cònsol separat, és a dir, hi havia un clúster de Postgres separat, un clúster de cònsol separat. Aquesta és una instrucció bàsica sobre com separar i subjectar totes aquestes coses perquè no visquin juntes.

Alternativament, podeu modificar els paràmetres ttl, loop_wait, retry_timeout, és a dir, intentar sobreviure a aquests pics de càrrega a curt termini augmentant aquests paràmetres. Però aquesta no és l'opció més adequada, perquè aquesta càrrega pot ser de llarga durada. I simplement anirem més enllà d'aquests límits d'aquests paràmetres. I això potser no ajuda realment.

El primer problema, com enteneu, és senzill. Vam agafar el DCS i el vam muntar amb la base, i vam tenir un problema.

El segon problema és semblant al primer. És semblant perquè tornem a tenir problemes per interactuar amb el sistema DCS.

Si mirem els registres, veurem que tornem a tenir un error de comunicació. I Patroni diu que no puc interactuar amb DCS, de manera que el mestre actual passa al mode de rèplica.

L'antic mestre es converteix en una rèplica, aquí Patroni funciona com cal. Executa pg_rewind per rebobinar el registre de transaccions i després connectar-se al nou mestre, i després posar-se al dia amb el nou mestre. Aquí Patroni funciona com cal.

Aquí hem de trobar el lloc que va precedir el fitxer, és a dir, aquells errors que van fer que es produís el fitxer. I en aquest sentit, els registres de Patroni són força còmodes per treballar. Escriu els mateixos missatges a determinats intervals. I si comencem a desplaçar-nos ràpidament per aquests registres, veurem a partir dels registres que els registres han canviat, la qual cosa significa que han començat alguns problemes. Tornem ràpidament a aquest lloc i veiem què passa.

I en una situació normal, els registres semblen una cosa així. Es comprova el propietari del pany. I si el propietari, per exemple, canvia, es poden produir alguns esdeveniments als quals Patroni ha de respondre. Però en aquest cas estem bé. Estem buscant el lloc on van començar els errors.

I havent desplaçat fins al punt on van començar a aparèixer errors, veiem que tenim un fitxer automàtic. I com que els nostres errors estaven relacionats amb la interacció amb DCS i en el nostre cas vam utilitzar Cònsol, també mirem els registres de Cònsol per veure què hi passava.

Després d'haver comparat aproximadament l'hora de l'expedient i l'hora dels registres del cònsol, veiem que els nostres veïns del clúster del cònsol van començar a dubtar de l'existència d'altres membres del clúster del cònsol.

I si mireu els registres d'altres agents del Cònsol, també podeu veure que allà s'està produint algun tipus de col·lapse de la xarxa. I tots els membres del grup Cònsol dubten de l'existència dels altres. I aquest va ser l'impuls per al filer.

Si mireu el que va passar abans d'aquests errors, podeu veure que hi ha tot tipus d'errors, per exemple, data límit, RPC va caure, és a dir, hi ha clarament algun problema en la interacció dels membres del clúster Cònsol entre ells.

La resposta més senzilla és arreglar la xarxa. Però dempeus al podi, és fàcil per a mi dir això. Però les circumstàncies són tals que el client no sempre es pot permetre el luxe de reparar la xarxa. Pot ser que visqui a la DC i no tingui la capacitat de reparar la xarxa o influir en l'equip. I, per tant, calen altres opcions.

Hi ha opcions:

• L'opció més senzilla, que està escrita, al meu entendre, fins i tot a la documentació, és desactivar les comprovacions de Cònsol, és a dir, simplement passar una matriu buida. I li diem a l'agent del cònsol que no faci servir cap xec. A causa d'aquestes comprovacions, podem ignorar aquestes tempestes de xarxa i no iniciar un fitxer.
• Una altra opció és tornar a comprovar raft_multiplier. Aquest és un paràmetre del propi servidor Cònsol. De manera predeterminada, s'estableix en 5. Aquest valor es recomana segons la documentació dels entorns de prova. Bàsicament, això afecta la freqüència d'intercanvi de missatges entre membres de la xarxa Cònsol. Bàsicament, aquest paràmetre afecta la velocitat de comunicació oficial entre els membres del clúster Cònsol. I per a la producció ja es recomana reduir-lo perquè els nodes intercanviïn missatges més sovint.
• Una altra opció que vam començar a utilitzar va ser augmentar la prioritat dels processos Consul entre altres processos per al planificador de processos del sistema operatiu. Hi ha un paràmetre "bonic", només determina la prioritat dels processos que el planificador del sistema operatiu té en compte a l'hora de planificar. També vam reduir el valor agradable per als agents cònsols, és a dir. va augmentar la prioritat perquè el sistema operatiu doni als processos Consul més temps per treballar i executar el seu codi. En el nostre cas, això va resoldre el nostre problema.
• Una altra opció és no utilitzar Cònsol. Tinc un amic que és un gran defensor de Etcd. I ell i jo discutim regularment quin és millor, Etcd o Cònsol. Però pel que fa a què és millor, ell i jo en general estem d'acord que Consul té un agent que s'hauria d'executar a cada node amb una base de dades. És a dir, la interacció de Patroni amb el clúster Cònsol es produeix a través d'aquest agent. I aquest agent es converteix en un coll d'ampolla. Si li passa alguna cosa a l'agent, Patroni ja no pot treballar amb el clúster Cònsol. I això és un problema. No hi ha cap agent al pla Etcd. Patroni pot treballar directament amb una llista de servidors Etcd i ja comunicar-se amb ells. En aquest sentit, si utilitzeu Etcd a la vostra empresa, probablement Etcd serà una millor opció que Consul. Però amb els nostres clients, sempre estem limitats pel que el client ha escollit i utilitza. I en la seva majoria, tenim Cònsol per a tots els clients.
• I l'últim punt és reconsiderar els valors dels paràmetres. Podem augmentar aquests paràmetres amb l'esperança que els nostres problemes de xarxa a curt termini siguin curts i no entren dins del rang d'aquests paràmetres. D'aquesta manera podem reduir l'agressivitat de Patroni per realitzar un autofileover si sorgeix algun problema de xarxa.

Crec que molts dels que utilitzen Patroni estan familiaritzats amb aquesta ordre.

Aquesta ordre mostra l'estat actual del clúster. I a primera vista aquesta imatge pot semblar normal. Tenim un mestre, tenim una rèplica, no hi ha retard de replicació. Però aquesta imatge és normal fins que sabem que aquest clúster hauria de tenir tres nodes, no dos.

En conseqüència, es va produir un fitxer automàtic. I després d'aquest fitxer automàtic, la nostra rèplica va desaparèixer. Hem d'esbrinar per què va desaparèixer i tornar-la, restaurar-la. I tornem als registres i mirem per què es va produir l'autofileover.

En aquest cas, la segona rèplica es va convertir en el mestre. Aquí tot està bé.

I hem de mirar la rèplica que s'ha caigut i no està al clúster. Obrim els registres de Patroni i veiem que vam tenir un problema a l'etapa pg_wind mentre ens connectàvem al clúster. Per connectar-vos al clúster, heu de rebobinar el registre de transaccions, sol·licitar el registre de transaccions necessari al mestre i utilitzar-lo per posar-vos al dia amb el mestre.

En aquest cas, no tenim un registre de transaccions i la rèplica no pot començar. En conseqüència, aturem Postgres amb un error. I per això no està al clúster.

Hem d'entendre per què no està al clúster i per què no hi havia registres. Anem al nou mestre i mirem què té als seus registres. Resulta que quan es va fer pg_rewind, es va produir un punt de control. I alguns dels antics registres de transaccions simplement es van canviar de nom. Quan l'antic mestre va intentar connectar-se al nou mestre i sol·licitar aquests registres, ja s'havien canviat de nom, simplement no existien.

Vaig comparar les marques de temps quan es van produir aquests esdeveniments. I allà la diferència és literalment de 150 mil·lisegons, és a dir, en 369 mil·lisegons es va completar el punt de control, els segments WAL van ser rebatejats. I, literalment, a 517, 150 mil·lisegons després, va començar el rebobinat a l'antiga rèplica. És a dir, literalment 150 mil·lisegons van ser suficients per evitar que la rèplica es connectés i funcionés.

Quines són les opcions?

Al principi vam utilitzar ranures de rèplica. Vam pensar que era bo. Encara que en la primera etapa de funcionament vam desactivar les ranures. Ens va semblar que si les ranures acumulaven molts segments WAL, podríem deixar caure el mestre. Ell caurà. Vam patir una estona sense ranures. I ens vam adonar que necessitàvem slots, vam tornar les ranures.

Però aquí hi ha un problema que quan el mestre es mou a una rèplica, elimina les ranures i, juntament amb les ranures, elimina els segments WAL. I per eliminar aquest problema, vam decidir augmentar el paràmetre wal_keep_segments. Per defecte, 8 segments. El vam pujar a 1 i vam mirar quant d'espai lliure teníem. I hem donat 000 gigabytes a wal_keep_segments. És a dir, quan canviem, sempre tenim una reserva de 16 gigabytes de registres de transaccions a tots els nodes.

I més: això també és rellevant per a tasques de manteniment a llarg termini. Suposem que hem d'actualitzar una de les rèpliques. I volem apagar-lo. Hem d'actualitzar el programari, potser el sistema operatiu, una altra cosa. I quan desactivem una rèplica, també s'elimina la ranura d'aquesta rèplica. I si fem servir wal_keep_segments petits, si hi ha una llarga absència de rèplica, es perdran els registres de transaccions. Recollirem una rèplica, demanarà aquells registres de transaccions on s'ha aturat, però és possible que no estiguin al mestre. I la rèplica tampoc es podrà connectar. Per això tenim un gran estoc de revistes.

Tenim una base de producció. Els projectes ja hi funcionen.

S'ha produït un fitxer. Vam entrar i vam mirar: tot està en ordre, les rèpliques estan al seu lloc, no hi ha cap retard de rèplica. Tampoc hi ha errors als registres, tot està en ordre.

L'equip del producte diu que sembla que hi hauria d'haver algunes dades, però les veiem des d'una font, però no les veiem a la base de dades. I hem d'entendre què els va passar.

Està clar que pg_wind els va esborrar. De seguida ens vam adonar d'això, però vam anar a veure què passava.

Als registres sempre podem trobar quan es va produir el fitxer, qui es va convertir en el mestre, i podem determinar qui era l'antic mestre i quan volia convertir-se en una rèplica, és a dir, necessitem aquests registres per esbrinar el volum de registres de transaccions que hi havia. perdut.

El nostre vell mestre s'ha reiniciat. I Patroni estava registrat a l'autostart. Patroni llançat. Després va iniciar Postgres. Més precisament, abans d'iniciar Postgres i abans de fer-ne una rèplica, Patroni va llançar el procés pg_wind. En conseqüència, va esborrar alguns dels registres de transaccions, en va descarregar de nous i es va connectar. Aquí el Patroni va fer una gran feina, és a dir, com hauria de ser. El nostre clúster s'ha restaurat. Teníem 3 nodes, després del fitxer hi havia 3 nodes: tot era genial.

Hem perdut algunes dades. I hem d'entendre quant hem perdut. Estem buscant exactament el moment en què vam tenir un rebobinat. Ho podem esbrinar a partir d'aquestes entrades de diari. va començar el rebobinat, va fer alguna cosa allà i va acabar.

Hem de trobar la posició al registre de transaccions on es va aturar l'antic mestre. En aquest cas, és aquesta marca. I necessitem una segona marca, és a dir, la distància en què el mestre antic es diferencia del nou.

Agafem el pg_wal_lsn_diff habitual i comparem aquestes dues marques. I en aquest cas obtenim 17 megabytes. Si això és molt o poc, cadascú decideix per si mateix. Perquè per a uns 17 megabytes no és molt, per a altres és molt i inacceptable. Aquí, cadascú decideix per si mateix d'acord amb les necessitats de l'empresa.

Però què hem descobert per nosaltres mateixos?

En primer lloc, hem de decidir per nosaltres mateixos: sempre necessitem l'inici automàtic de Patroni després d'un reinici del sistema? Més sovint passa que hem d'anar al vell mestre, a veure fins on ha arribat. Potser inspeccioneu els segments del registre de transaccions, vegeu què hi ha. I entendre si podem perdre aquestes dades o si necessitem executar l'antic mestre en mode autònom per recuperar aquestes dades.

I només després d'això hem de decidir si podem descartar aquestes dades o les podem restaurar, connectar aquest node com a rèplica al nostre clúster.

A més, hi ha un paràmetre "maximum_lag_on_failover". Per defecte, si la meva memòria funciona correctament, aquest paràmetre té un valor d'1 megabyte.

Com treballa? Si la nostra rèplica està endarrerida amb 1 megabyte de dades en el retard de rèplica, aquesta rèplica no participa a les eleccions. I si de sobte es produeix un fitxer, Patroni mira quines rèpliques estan endarrerides. Si estan enrere per un gran nombre de registres de transaccions, no poden convertir-se en mestres. Aquesta és una característica de seguretat molt bona que evita que perdis moltes dades.

Però hi ha un problema que el retard de replicació al clúster Patroni i DCS s'actualitza a un interval determinat. Crec que 30 segons és el valor ttl predeterminat.

En conseqüència, pot haver-hi una situació en què el retard de replicació de les rèpliques a DCS sigui el mateix, però de fet pot haver-hi un retard completament diferent o no hi ha cap retard, és a dir, això no és en temps real. I no sempre reflecteix la imatge real. I no val la pena fer-hi una lògica fantàstica.

I el risc de pèrdua sempre es manté. I en el pitjor dels casos hi ha una fórmula, i en el cas mitjà hi ha una altra fórmula. És a dir, quan planifiquem la implantació de Patroni i estimem quantes dades podem perdre, ens hem de basar en aquestes fórmules i imaginar aproximadament quantes dades podem perdre.

I hi ha bones notícies. Quan l'antic mestre ha avançat, pot avançar a causa d'alguns processos de fons. És a dir, hi va haver algun tipus d'autobuit, va escriure les dades i les va desar al registre de transaccions. I fàcilment podem ignorar i perdre aquestes dades. No hi ha cap problema amb això.

I així són els registres si s'estableix maximum_lag_on_failover i es produeix una superació de fitxers i cal seleccionar un nou mestre. La rèplica es valora com a incapaç de participar a les eleccions. I ella es nega a participar en la carrera pel lideratge. I ella espera que s'esculli un nou mestre, per poder connectar-se amb ell. Aquesta és una mesura addicional contra la pèrdua de dades.

Aquí el nostre equip de productes va escriure que el seu producte està experimentant problemes quan treballa amb Postgres. Al mateix temps, no podeu accedir al propi mestre, perquè no és accessible mitjançant SSH. I l'autofileover tampoc passa.

Aquest amfitrió s'ha obligat a reiniciar. A causa del reinici, es va produir un autofileover, tot i que també era possible fer un autofileover manual, com ara entenc. I després del reinici, anem a veure què teníem amb el mestre actual.

Al mateix temps, sabíem per endavant que teníem problemes amb els discos, és a dir, ja sabíem per monitoratge on excavar i què buscar.

Vam entrar al registre de postgres i vam començar a mirar què hi passava. Vam veure commits que van durar un, dos o tres segons, cosa que no és gens normal. Vam veure que el nostre autoaspirador trigava molt i estrany a posar-se en marxa. I vam veure fitxers temporals al disc. És a dir, tots aquests són indicadors de problemes amb els discs.

Hem mirat el sistema dmesg (registre de missatges nuclears). I vam veure que teníem problemes amb un dels discos. El subsistema de disc era un programari Raid. Vam mirar /proc/mdstat i vam veure que ens faltava un disc. És a dir, hi ha un Raid de 8 discos, ens falta un. Si mireu de prop la diapositiva, podeu veure a la sortida que no hi tenim sde. El nostre disc, relativament parlant, es va caure. Això va provocar problemes de disc i les aplicacions també van experimentar problemes quan es treballava amb el clúster Postgres.

I en aquest cas, Patroni no ens ajudaria de cap manera, perquè Patroni no té la tasca de controlar l'estat del servidor, l'estat del disc. I hem de controlar aquestes situacions amb un seguiment extern. Hem afegit la supervisió del disc operatiu a la monitorització externa.

I hi havia aquest pensament: ens podria ajudar el programari d'esgrima o de control? Vam pensar que era poc probable que ens hagués ajudat en aquest cas, perquè durant els problemes Patroni va continuar interactuant amb el clúster DCS i no va veure cap problema. És a dir, des del punt de vista de DCS i Patroni, tot anava bé amb el clúster, encara que de fet hi havia problemes amb el disc, hi havia problemes amb la disponibilitat de la base de dades.

En la meva opinió, aquest és un dels problemes més estranys que vaig investigar durant molt de temps, vaig tornar a llegir molts registres, vaig jugar amb ell i el vaig anomenar simulador de clúster.

El problema era que l'antic mestre no podia convertir-se en una rèplica normal, és a dir, Patroni la va llançar, Patroni va demostrar que aquest node estava present com a rèplica, però al mateix temps no era una rèplica normal. Ara veuràs per què. Vaig evitar que això analitzés aquest problema.

I on va començar tot? Va començar, com en el problema anterior, amb frens de disc. Teníem commits un segon a la vegada, dos a la vegada.

Hi va haver interrupcions de connexió, és a dir, els clients estaven desconnectats.

Hi va haver bloquejos de diferent severitat.

I, en conseqüència, el subsistema de disc no respon molt.

I el més misteriós per a mi és la sol·licitud de tancament immediat que va arribar. Postgres té tres modes de tancament:

• És agraciat quan esperem que tots els clients es desconnectin pel seu compte.
• Hi ha ràpid, quan obliguem els clients a desconnectar perquè anem a tancar.
• I immediata. En aquest cas, immediat ni tan sols diu als clients que tanquin, només s'apaga sense previ avís. I el sistema operatiu envia un missatge RST a tots els clients (missatge TCP que la connexió s'ha interromput i el client no té res més a captar).

Qui va enviar aquest senyal? Els processos de Postgres de fons no s'envien aquests senyals entre si, és a dir, això és un kill-9. No s'envien entre ells, només reaccionen a això, és a dir, es tracta d'un reinici d'emergència de Postgres. No sé qui l'ha enviat.

Vaig mirar l'ordre "última" i vaig veure una persona que també va iniciar sessió en aquest servidor amb nosaltres, però em va fer vergonya fer una pregunta. Potser va ser kill -9. Jo veuria matar -9 als registres, perquè... Postgres diu que va acceptar kill -9, però no ho vaig veure als registres.

Mirant més enllà, vaig veure que Patroni no va escriure al registre durant molt de temps: 54 segons. I si compares les dues marques de temps, no hi havia missatges durant uns 54 segons.

I durant aquest temps es va produir un fitxer automàtic. Patroni va tornar a treballar molt bé aquí. El nostre vell mestre no estava disponible, li passava alguna cosa. I va començar l'elecció d'un nou mestre. Aquí tot va sortir bé. El nostre pgsql01 s'ha convertit en el nostre nou líder.

Tenim una rèplica que s'ha convertit en un mestre. I hi ha una segona rèplica. I hi va haver problemes amb la segona observació. Ella va intentar reconfigurar-se. Segons tinc entès, va intentar canviar recovery.conf, reiniciar Postgres i connectar-se al nou mestre. Ella envia missatges de text cada 10 segons que ho està intentant, però no ho aconsegueix.

I durant aquests intents, arriba un senyal d'apagada immediata a l'antic mestre. El mestre es reinicia. I també la recuperació s'atura perquè l'antic mestre es reinicia. És a dir, la rèplica no pot connectar-s'hi perquè està en mode d'apagada.

En algun moment va funcionar, però la replicació no va començar.

L'única hipòtesi que tinc és que recovery.conf contenia l'adreça de l'antic mestre. I quan va aparèixer un nou mestre, la segona rèplica encara intentava connectar-se amb l'antic mestre.

Quan Patroni va començar a la segona rèplica, el node va començar, però no es va poder connectar mitjançant la rèplica. I es va formar un retard de replicació, que semblava una cosa així. És a dir, els tres nodes estaven al seu lloc, però el segon node estava endarrerit.

Al mateix temps, si observeu els registres que s'han escrit, podeu veure que la rèplica no s'ha pogut iniciar perquè els registres de transaccions eren diferents. I els registres de transaccions que ofereix l'assistent, que es mostren a recovery.conf, simplement no són adequats per al nostre node actual.

I aquí m'he equivocat. Vaig haver de venir a veure què hi havia a recovery.conf per provar la meva hipòtesi que estàvem connectant amb el mestre equivocat. Però en aquell moment només ho estava esbrinant i no se'm va passar pel cap, o vaig veure que la rèplica es quedava endarrerida i s'hauria d'omplir, és a dir, d'alguna manera la vaig resoldre descuidament. Aquest era el meu brancal.

Al cap de 30 minuts va arribar l'administrador, és a dir, vaig reiniciar Patroni a la rèplica. Ja hi havia renunciat, pensava que s'hauria de tornar a omplir. I vaig pensar, reiniciaré Patroni, potser sortirà alguna cosa bona. La recuperació va començar. I fins i tot es va obrir la base, estava preparada per acceptar connexions.

La replicació ha començat. Però un minut després es va estavellar amb un error que els registres de transaccions no eren adequats per a això.

Vaig pensar que tornaria a començar. Vaig reiniciar Patroni de nou i no vaig reiniciar Postgres, sinó que vaig reiniciar Patroni amb l'esperança que iniciés màgicament la base de dades.

La replicació va començar de nou, però les notes del registre de transaccions eren diferents, no eren les mateixes que les que hi havia en l'intent d'inici anterior. La replicació s'ha aturat de nou. I el missatge era una mica diferent. I no va ser especialment informatiu per a mi.

I llavors se m'ocorre: què passa si reinicio Postgres, en aquest moment faig un punt de control al mestre actual per tal de moure el punt del registre de transaccions una mica endavant perquè la recuperació comenci des d'un moment diferent? A més, encara hi teníem reserves de WAL.

Vaig reiniciar Patroni, vaig fer un parell de punts de control al mestre, un parell de punts de reinici a la rèplica quan es va obrir. I va ajudar. Vaig pensar molt i molt sobre per què ajudava i com funcionava. I la rèplica va començar. I la replicació ja no va fallar.

Aquest problema és un dels més misteriosos per a mi, sobre el qual encara estic desconcertant el que realment va passar allà.

Quines són les conclusions aquí? Patroni pot funcionar com es pretén i sense cap error. Però, al mateix temps, això no és una garantia del 100% que tot està bé amb nosaltres. La rèplica pot començar, però pot estar en un estat semi-funcionant i l'aplicació no pot funcionar amb aquesta rèplica, perquè hi haurà dades antigues.

I després del fitxer, sempre hem de comprovar que tot està bé amb el clúster, és a dir, tenim el nombre de rèpliques necessaris i no hi ha cap retard de rèplica.

I a mesura que considerem aquests problemes, formularé recomanacions. Vaig intentar combinar-los en dues diapositives. Probablement, totes les històries es podrien haver combinat en dues diapositives i només explicar-les.

Quan utilitzeu Patroni, heu de tenir un seguiment. Sempre hauríeu de saber quan s'ha produït una superació automàtica de fitxers, perquè si no sabeu que heu tingut una superació automàtica de fitxers, no teniu el control del clúster. I això és dolent.

Després de cada fitxer, sempre hauríem de comprovar manualment el clúster. Hem d'assegurar-nos que sempre tenim un nombre de rèpliques actualitzat, no hi ha cap retard de rèplica i no hi ha errors en els registres relacionats amb la replicació en streaming, Patroni o el sistema DCS.

L'automatització pot funcionar amb èxit, Patroni és una molt bona eina. Pot ser que funcioni, però no portarà el clúster a l'estat desitjat. I si no ho sabem, tindrem problemes.

I Patroni no és una bala de plata. Encara hem d'entendre com funciona Postgres, com funciona la rèplica i com funciona Patroni amb Postgres i com s'aconsegueix la comunicació entre nodes. Això és necessari per poder solucionar els problemes amb les mans.

Com abordo el tema del diagnòstic? Va passar que treballem amb diferents clients i ningú no té una pila ELK, i hem d'entendre els registres obrint 6 consoles i 2 pestanyes. En una pestanya hi ha registres de Patroni per a cada node, a l'altra pestanya hi ha registres de Consul, o registres de Postgres si cal. És molt difícil de diagnosticar.

Quins enfocaments he desenvolupat? En primer lloc, sempre miro quan arriba el fitxer. I per a mi això és una mena de conca. Miro el que va passar abans del fitxer, durant el fitxer i després del fitxer. El fitxer over té dues marques: aquesta és l'hora d'inici i de finalització.

A continuació, miro als registres els esdeveniments anteriors al fitxer, que van precedir el fitxer, és a dir, busco els motius pels quals s'ha produït el fitxer.

I això dóna una imatge de la comprensió del que va passar i què es pot fer en el futur per evitar que es produeixin aquestes circumstàncies (i, com a resultat, no es produeix un fitxer).

I on busquem habitualment? miro:

• Primer als registres del Patroni.
• A continuació, miro els registres de Postgres o els registres de DCS, depenent del que s'ha trobat als registres de Patroni.
• I els registres del sistema de vegades també donen una comprensió del que va causar el fitxer.

Què sento per Patroni? Em sento molt bé amb Patroni. Al meu entendre, això és el millor que hi ha avui. Conec molts altres productes. Aquests són Stolon, Repmgr, Pg_auto_failover, PAF. 4 eines. Les he provat totes. Patroni em va agradar més.

Si em pregunten: "Recomano Patroni?" Diré que sí, perquè el Patroni m'agrada. I crec que vaig aprendre a cuinar-lo.

Si us interessa veure quins altres problemes hi ha amb Patroni, a més dels problemes que vaig expressar, sempre podeu anar a la pàgina problemes a GitHub. Hi ha moltes històries diferents i s'hi discuteixen molts problemes interessants. I com a resultat, es van introduir i resoldre alguns errors, és a dir, aquesta és una lectura interessant.

Hi ha històries interessants sobre gent que es dispara al peu. Molt informatiu. Llegiu i enteneu que no cal que feu això. Em vaig marcar.

I m'agradaria donar un gran agraïment a l'empresa Zalando per desenvolupar aquest projecte, és a dir, a Alexander Kukushkin i Alexey Klyukin. Alexey Klyukin és un dels coautors que ja no treballa a Zalando, però es tracta de dues persones que van començar a treballar amb aquest producte.

I crec que Patroni és una cosa molt xula. M'alegro que existeixi, és interessant estar amb ella. I moltes gràcies a tots els col·laboradors que escriuen pedaços a Patroni. Espero que el Patroni sigui més madur, fresc i capaç amb l'edat. Ja és eficient, però espero que sigui encara millor. Així que si teniu previst utilitzar Patroni a casa vostra, no tingueu por. Aquesta és una bona solució, es pot implementar i utilitzar.

Això és tot. Si teniu preguntes, pregunteu.

Les vostres preguntes

Gràcies pel reportatge! Si després del fitxer encara heu de mirar-hi amb molta cura, per què necessitem un fitxer automàtic?

Perquè és una cosa nova. Només fa un any que treballem amb ella. Millor jugar amb seguretat. Volem entrar i veure que tot ha funcionat realment com calia. Aquest és el nivell de desconfiança dels adults: és millor comprovar-ho i veure.

Per exemple, hem entrat aquest matí i hem mirat, oi?

No al matí, normalment ens assabentem de l'autofileover gairebé immediatament. Rebem notificacions, veiem que s'ha produït un fitxer automàtic. Gairebé de seguida entrem i fem una ullada. Però totes aquestes comprovacions s'han de portar al nivell de seguiment. Si accediu a Patroni mitjançant l'API REST, hi ha un historial. Mitjançant l'historial, podeu consultar les marques de temps quan es va descarregar el fitxer. A partir d'això, es pot fer un seguiment. Podeu mirar la història per veure quants esdeveniments hi va haver. Si tenim més esdeveniments, vol dir que s'ha produït un fitxer automàtic. Pots anar a fer-hi una ullada. O la nostra automatització de monitorització ha comprovat que tenim totes les rèpliques al seu lloc, no hi ha cap retard i tot està bé.

Gràcies!

Moltes gràcies per una gran història! Si hem traslladat el clúster DCS a algun lloc lluny del clúster Postgres, aquest clúster també s'ha de fer servir periòdicament? Quines són les millors pràctiques perquè algunes parts del clúster DCS s'han d'apagar, s'ha de fer alguna cosa amb elles, etc.? Com viu tota aquesta estructura? I com fer aquestes coses?

Per a una empresa, va ser necessari crear una matriu de problemes del que passa si un o més components fallaven. Utilitzant aquesta matriu, passem seqüencialment per tots els components i construïm escenaris en cas de fallada d'aquests components. En conseqüència, per a cada escenari de fallada, podeu tenir un pla d'acció per a la recuperació. I en el cas de DCS, això forma part de la infraestructura estàndard. I l'administrador ho administra, i ja confiem en els administradors que l'administren i en la seva capacitat per solucionar-ho en cas de desastres. Si no hi ha cap DCS, el despleguem, però no el monitoritzem especialment, perquè no som responsables de la infraestructura, però donem recomanacions sobre com i què controlar.

És a dir, he entès correctament que he de desactivar Patroni, desactivar el fitxer, desactivar-ho tot abans de fer res amb els amfitrions?

Depèn de quants nodes tinguem al clúster DCS. Si hi ha molts nodes i si només desactivem un dels nodes (la rèplica), es manté un quòrum al clúster. I Patroni continua operatiu. I no s'activa res. Si tenim algunes operacions complexes que afecten més nodes, l'absència de les quals podria destruir el quòrum, llavors sí, potser té sentit posar en pausa Patroni. Té una ordre corresponent: patronictl pause, patronictl resume. Simplement ho posem en pausa i el fitxer automàtic no funciona en aquest moment. Fem manteniment al clúster DCS, després eliminem la pausa i continuem amb vida.

Moltes gràcies!

Moltes gràcies pel reportatge! Com se sent l'equip de producte sobre la pèrdua de dades?

Els equips de producte no els importen, però els líders d'equip estan preocupats.

Quines garanties hi ha?

És molt difícil amb garanties. Alexander Kukushkin té un informe "Com calcular RPO i RTO", és a dir, el temps de recuperació i quantes dades podem perdre. Crec que hem de trobar aquestes diapositives i estudiar-les. Pel que recordo, hi ha passos específics sobre com calcular aquestes coses. Quantes transaccions podem perdre, quantes dades podem perdre. Com a opció, podem utilitzar la replicació síncrona a nivell de Patroni, però aquesta és una arma de doble tall: o tenim fiabilitat de les dades o perdem velocitat. Hi ha replicació síncrona, però tampoc garanteix una protecció del 100% contra la pèrdua de dades.

Alexey, gràcies pel meravellós informe! Alguna experiència utilitzant Patroni per a una protecció de nivell zero? És a dir, en combinació amb el mode d'espera sincrònic? Aquesta és la primera pregunta. I la segona pregunta. Heu utilitzat diferents solucions. Hem utilitzat Repmgr, però sense un fitxer automàtic i ara estem planejant habilitar un fitxer automàtic. I considerem Patroni com una solució alternativa. Quins avantatges pots dir en comparació amb Repmgr?

La primera pregunta era sobre rèpliques sincròniques. Ningú fa servir aquí la replicació síncrona, perquè tothom té por (hi ha diversos clients que ja l'utilitzen, no han notat cap problema de rendiment - Nota del ponent). Però hem desenvolupat una regla per a nosaltres mateixos que en un clúster de replicació síncrona hi ha d'haver almenys tres nodes, perquè si tenim dos nodes i si falla el mestre o la rèplica, llavors Patroni canvia aquest node al mode Autònom perquè l'aplicació continuï funcionant. treball. En aquest cas, hi ha un risc de pèrdua de dades.

Pel que fa a la segona pregunta, hem utilitzat Repmgr i encara ho fem per a alguns clients per motius històrics. Què podem dir? A Patroni, l'autofileover surt de la caixa a Repmgr, l'autofileover ve com una funció addicional que s'ha d'habilitar. Hem d'executar el dimoni Repmgr a cada node i després podem configurar l'autofileover.

Repmgr comprova si els nodes Postgres estan vius. Els processos de repmgr comproven l'existència dels altres, això no és un enfocament molt eficient perquè Pot haver-hi casos complexos d'aïllament de la xarxa en què un gran clúster de Repmgr pot trencar-se en diversos petits i continuar funcionant. Fa temps que no segueixo Repmgr, potser això s'ha solucionat... o potser no. Però transferir informació sobre l'estat del clúster a DCS, com fan Stolon i Patroni, és l'opció més viable.

Alexey, tinc una pregunta que pot ser coixa. En un dels primers exemples, heu mogut DCS de la màquina local a un node remot. Entenem que la xarxa és una cosa que té les seves pròpies característiques; I què passa si per algun motiu el clúster DCS no està disponible? No diré els motius, n'hi poden haver molts: des de les mans tortes dels networkers fins a problemes reals.

No ho he dit en veu alta, però el clúster DCS també ha de ser tolerant a errors, és a dir, té un nombre imparell de nodes per tal que es produeixi un quòrum. Què passa si el clúster DCS no està disponible o no es pot assolir un quòrum, és a dir, algun tipus de fracció de xarxa o fallada del node? En aquest cas, el clúster Patroni entra en mode de només lectura. El clúster Patroni no pot determinar l'estat del clúster i què cal fer. No pot contactar amb DCS i desar-hi el nou estat del clúster, de manera que tot el clúster passa al mode de només lectura. I s'espera la intervenció manual de l'operador o el DCS que es restableixi.

A grans trets, DCS s'està convertint en un servei tan important per a nosaltres com la pròpia base de dades?

Sí sí. En moltes empreses modernes, Service Discovery és una part integral de la infraestructura. S'està implementant fins i tot abans que hi hagués una base de dades a la infraestructura. Relativament parlant, vam llançar la infraestructura, la vam desplegar al DC i de seguida tenim Service Discovery. Si això és Cònsol, es pot crear DNS a partir d'ell. Si això és Etcd, pot ser que hi hagi una part del clúster de Kubernetes en què es desplegarà tota la resta. Em sembla que Service Discovery ja és una part integral de les infraestructures modernes. I hi pensen molt abans que les bases de dades.

Gràcies!

Font: www.habr.com