O obxectivo principal de Patroni é proporcionar alta dispoñibilidade para PostgreSQL. Pero Patroni é só un modelo, non unha ferramenta preparada (que, en xeral, dise na documentación). A primeira vista, despois de configurar Patroni no laboratorio de probas, podes ver que gran ferramenta é e con que facilidade xestiona os nosos intentos de romper o clúster. Non obstante, na práctica, nun ambiente de produción, todo non sempre ocorre tan fermoso e elegante como nun laboratorio de probas.
Vouche falar un pouco de min. Comecei como administrador de sistemas. Traballou no desenvolvemento web. Traballo en Data Egret desde 2014. A empresa dedícase á consultoría no campo de Postgres. E servimos exactamente a Postgres, e traballamos con Postgres todos os días, polo que temos diferentes coñecementos relacionados coa operación.
E a finais de 2018, comezamos a usar Patroni aos poucos. E algo de experiencia foi acumulada. Dalgunha maneira diagnosticámolo, axustámolo, chegamos ás nosas mellores prácticas. E nesta reportaxe falarei deles.
Ademais de Postgres, encántame Linux. Gústame botarlle unha volta e exploralo, gústame recoller núcleos. Encántame a virtualización, os contenedores, o docker, Kubernetes. Todo isto interésame, porque os vellos hábitos de administración están afectando. Gústame ocuparme do seguimento. E encántanme as cousas de postgres relacionadas coa administración, é dicir, a replicación, a copia de seguridade. E no meu tempo libre escribo en Go. Non son enxeñeiro de software, só escribo para min en Go. E dáme pracer.
- Creo que moitos de vós sabedes que Postgres non ten HA (alta dispoñibilidade) fóra da caixa. Para obter HA, cómpre instalar algo, configuralo, facer un esforzo e conseguilo.
- Hai varias ferramentas e Patroni é unha delas que resolve HA bastante chula e moi ben. Pero poñéndoo todo nun laboratorio de probas e executándoo, podemos ver que todo funciona, podemos reproducir algúns problemas, ver como os atende Patroni. E veremos que todo funciona moi ben.
- Pero na práctica, enfrontámonos a diferentes problemas. E falarei destes problemas.
- Vouche dicir como o diagnosticamos, o que axustamos, se nos axudou ou non.
- Non che direi como instalar Patroni, porque podes buscar en Google en Internet, podes mirar os ficheiros de configuración para entender como comeza todo, como está configurado. Podes comprender os esquemas, arquitecturas, atopar información sobre el en Internet.
- Non vou falar da experiencia doutra persoa. Só falarei dos problemas aos que nos enfrontamos.
- E non vou falar de problemas que están fóra de Patroni e PostgreSQL. Se, por exemplo, hai problemas asociados ao equilibrio, cando o noso clúster colapsou, non vou falar diso.
E unha pequena exención de responsabilidade antes de comezar o noso informe.
Todos estes problemas que nos atopamos, tímolos nos primeiros 6-7-8 meses de funcionamento. Co paso do tempo, chegamos ás nosas mellores prácticas internas. E os nosos problemas desapareceron. Por iso, o informe foi anunciado hai uns seis meses, cando estaba todo fresco na miña cabeza e recordaba todo perfectamente.
No transcurso da elaboración do informe, xa levantei autopsias antigas, mirei os rexistros. E algúns dos detalles poderían esquecerse, ou algúns nalgúns detalles non se puideron investigar completamente durante a análise dos problemas, polo que nalgúns puntos pode parecer que os problemas non están totalmente considerados ou hai algunha falta de información. E por iso pídoche desculpas por este momento.
Que é Patroni?
- Este é un modelo para construír HA. Iso é o que di na documentación. E dende o meu punto de vista, esta é unha aclaración moi correcta. Patroni non é unha bala de prata que resolva todos os teus problemas, é dicir, tes que esforzarte para que funcione e traia beneficios.
- Este é un servizo de axente que se instala en todos os servizos de base de datos e é unha especie de sistema de inicio para o teu Postgres. Inicia Postgres, detén, reinicia, reconfigura e cambia a topoloxía do seu clúster.
- En consecuencia, para almacenar o estado do clúster, a súa representación actual, segundo parece, é necesario algún tipo de almacenamento. E desde este punto de vista, Patroni tomou o camiño de almacenar o estado nun sistema externo. É un sistema de almacenamento de configuración distribuída. Pode ser Etcd, Consul, ZooKeeper ou kubernetes Etcd, é dicir, unha destas opcións.
- E unha das características de Patroni é que obtén o ficheiro automático da caixa, só configurándoo. Se tomamos Repmgr para comparar, entón o ficheiro está incluído alí. Con Repmgr, obtemos un cambio, pero se queremos un ficheiro automático, necesitamos configuralo adicionalmente. Patroni xa ten un ficheiro automático fóra da caixa.
- E hai moitas outras cousas. Por exemplo, mantemento de configuracións, vertido de novas réplicas, copia de seguridade, etc. Pero isto está fóra do alcance do informe, non vou falar diso.
E un pequeno resultado é que a principal tarefa de Patroni é facer un ficheiro automático ben e de forma fiable para que o noso clúster siga operativo e a aplicación non note cambios na topoloxía do clúster.
Pero cando comezamos a usar Patroni, o noso sistema complícase un pouco máis. Se antes tiñamos Postgres, cando usamos Patroni obtemos o propio Patroni, obtemos DCS onde se almacena o estado. E todo ten que funcionar dalgún xeito. Entón, que pode saír mal?
Maio romper:
- Postgres pode romper. Pode ser un mestre ou unha réplica, un deles pode fallar.
- O propio Patroni pode romper.
- O DCS onde se almacena o estado pode romper.
- E a rede pode romper.
Todos estes puntos terei en conta no informe.
Considerarei casos a medida que se vaian facendo máis complexos, non desde o punto de vista de que o caso implica moitos compoñentes. E dende o punto de vista dos sentimentos subxectivos, que esta funda era difícil para min, era difícil desmontala... e viceversa, algunha funda era lixeira e era fácil desmontala.
E o primeiro caso é o máis sinxelo. Este é o caso cando tomamos un clúster de bases de datos e implantamos o noso almacenamento DCS no mesmo clúster. Este é o erro máis común. Este é un erro ao construír arquitecturas, é dicir, combinar diferentes compoñentes nun só lugar.
Entón, había un arquivo, imos tratar o que pasou.
E aquí nos interesa cando ocorreu o arquivo. É dicir, interésanos este momento no que o estado do clúster cambiou.
Pero o ficheiro non sempre é instantáneo, é dicir, non leva ningunha unidade de tempo, pódese atrasar. Pode ser de longa duración.
Polo tanto, ten unha hora de inicio e unha hora de finalización, é dicir, é un evento continuo. E dividimos todos os eventos en tres intervalos: temos tempo antes do arquivo, durante o arquivo e despois do arquivo. É dicir, consideramos todos os eventos nesta liña de tempo.
E o primeiro, cando ocorreu un arquivo, buscamos a causa do que pasou, cal foi a causa do que levou ao arquivo.
Se miramos os rexistros, serán os clásicos rexistros de Patroni. Cóntanos neles que o servidor converteuse no mestre e o papel do mestre pasou a este nodo. Aquí se destaca.
A continuación, necesitamos entender por que ocorreu o ficheiro, é dicir, que eventos ocorreron que fixeron que o rol mestre se movese dun nodo a outro. E neste caso, todo é sinxelo. Temos un erro ao interactuar co sistema de almacenamento. O mestre deuse conta de que non podía traballar con DCS, é dicir, había algún tipo de problema coa interacción. E di que xa non pode ser mestre e dimite. Esta liña "auto degradado" di exactamente iso.
Se observamos os eventos que precederon ao ficheiro, podemos ver alí as razóns que provocaron que o problema continuase co asistente.
Se observamos os rexistros de Patroni, veremos que temos moitos erros, tempo de espera, é dicir, o axente de Patroni non pode traballar con DCS. Neste caso, trátase do axente Consul, que se está comunicando no porto 8500.
E o problema aquí é que Patroni e a base de datos funcionan no mesmo host. E os servidores Consul lanzáronse no mesmo nodo. Ao crear unha carga no servidor, tamén creamos problemas para os servidores de Consul. Non se podían comunicar correctamente.
Despois dun tempo, cando a carga diminuíu, o noso Patroni puido comunicarse de novo cos axentes. Retomouse o traballo normal. E o mesmo servidor Pgdb-2 volveu ser mestre. É dicir, houbo un pequeno flip, debido ao cal o nodo renunciou aos poderes do mestre e despois tomounos de novo, é dicir, todo volveu como estaba.
E isto pode considerarse como unha falsa alarma, ou pódese considerar que Patroni fixo todo ben. É dicir, deuse conta de que non podía manter o estado do clúster e quitoulle a autoridade.
E aquí xurdiu o problema debido a que os servidores Consul están no mesmo hardware que as bases. En consecuencia, calquera carga: xa sexa a carga en discos ou procesadores, tamén afecta a interacción co clúster Consul.
E decidimos que non debería vivir xuntos, asignamos un clúster separado para Cónsul. E Patroni xa estaba traballando cun Cónsul separado, é dicir, había un clúster de Postgres separado, un clúster de Cónsul separado. Esta é unha instrución básica sobre como levar e gardar todas estas cousas para que non convivan.
Como opción, pode torcer os parámetros ttl, loop_wait, retry_timeout, é dicir, tentar sobrevivir a estes picos de carga a curto prazo aumentando estes parámetros. Pero esta non é a opción máis adecuada, porque esta carga pode ser longa no tempo. E simplemente iremos máis aló destes límites destes parámetros. E iso quizais non axude realmente.
O primeiro problema, como entendes, é sinxelo. Collemos e xuntamos o DCS coa base, temos un problema.
O segundo problema é semellante ao primeiro. É semellante en que volvemos ter problemas de interoperabilidade co sistema DCS.
Se miramos os rexistros, veremos que volvemos ter un erro de comunicación. E Patroni di que non podo interactuar con DCS polo que o mestre actual pasa ao modo de réplica.
O vello mestre convértese nunha réplica, aquí Patroni funciona, como debe ser. Executa pg_rewind para rebobinar o rexistro de transaccións e despois conectarse ao novo mestre para poñerse ao día co novo mestre. Aquí Patroni traballa, como debería.
Aquí debemos atopar o lugar que precedeu ao arquivo, é dicir, aqueles erros que fixeron que tivésemos un arquivo. E neste sentido, os rexistros de Patroni son bastante cómodos para traballar. Escribe as mesmas mensaxes nun intervalo determinado. E se comezamos a desprazarnos rapidamente por estes rexistros, veremos a partir dos rexistros que os rexistros cambiaron, o que significa que comezaron algúns problemas. Volvemos rapidamente a este lugar, a ver que pasa.
E nunha situación normal, os rexistros parecen algo así. Compróbase o propietario da pechadura. E se o propietario, por exemplo, cambiou, poden ocorrer algúns eventos aos que Patroni debe responder. Pero neste caso, estamos ben. Buscamos o lugar onde comezaron os erros.
E tendo desprazado ata o punto onde comezaron a aparecer os erros, vemos que tivemos un auto-archivo. E dado que os nosos erros estaban relacionados coa interacción con DCS e no noso caso usamos Consul, tamén miramos os rexistros de Consul, o que pasou alí.
Comparando grosso modo a hora do arquivo e a hora dos rexistros Cónsul, vemos que os nosos veciños do clúster Cónsul comezaron a dubidar da existencia doutros membros do clúster Cónsul.
E se miras tamén os rexistros doutros axentes do Cónsul, tamén podes ver que alí se está a producir algún tipo de colapso da rede. E todos os membros do clúster Cónsul dubidan mutuamente da existencia. E este foi o impulso para o arquivo.
Se observas o que pasou antes destes erros, podes ver que hai todo tipo de erros, por exemplo, o prazo, o RPC caeu, é dicir, hai claramente algún tipo de problema na interacción dos membros do clúster Cónsul entre si. .
A resposta máis sinxela é reparar a rede. Pero para min, parado no podio, é fácil dicir isto. Pero as circunstancias son tales que non sempre o cliente pode permitirse o luxo de reparar a rede. Pode vivir nun DC e pode non ser capaz de reparar a rede, afectar o equipo. E por iso son necesarias outras opcións.
Hai opcións:
- A opción máis sinxela, que está escrita, na miña opinión, mesmo na documentación, é desactivar as comprobacións Consul, é dicir, simplemente pasar unha matriz baleira. E dicímoslle ao axente Cónsul que non use ningún cheque. Con estas comprobacións, podemos ignorar estas tormentas de rede e non iniciar un arquivo.
- Outra opción é comprobar dúas veces o raft_multiplier. Este é un parámetro do propio servidor Consul. De xeito predeterminado, está definido en 5. Este valor recoméndase a documentación para ambientes de preparación. De feito, isto afecta á frecuencia das mensaxes entre os membros da rede Cónsul. De feito, este parámetro afecta á velocidade de comunicación do servizo entre os membros do clúster Consul. E para a produción, xa se recomenda reducilo para que os nodos intercambien mensaxes con máis frecuencia.
- Outra opción que se nos ocorre é aumentar a prioridade dos procesos Consul entre outros procesos para o programador de procesos do sistema operativo. Hai un parámetro tan "bonito", que só determina a prioridade dos procesos que o programador do SO ten en conta ao programar. Tamén reducimos o bo valor para os axentes cónsules, é dicir. aumentou a prioridade para que o sistema operativo dea máis tempo aos procesos Consul para traballar e executar o seu código. No noso caso, isto resolveu o noso problema.
- Outra opción é non usar Cónsul. Teño un amigo que é un gran defensor de Etcd. E discutimos regularmente con el cal é mellor Etcd ou Cónsul. Pero en canto a cal é mellor, adoitamos coincidir con el en que Consul ten un axente que debería estar en execución en cada nodo cunha base de datos. É dicir, a interacción de Patroni co clúster Cónsul pasa por este axente. E este axente convértese nun pescozo de botella. Se algo lle ocorre ao axente, Patroni xa non pode traballar co clúster Consul. E este é o problema. Non hai ningún axente no plan Etcd. Patroni pode traballar directamente cunha lista de servidores Etcd e xa comunicarse con eles. Neste sentido, se usa Etcd na súa empresa, entón Etcd probablemente sexa unha mellor opción que Consul. Pero os nosos clientes sempre estamos limitados polo que escolleu e utiliza. E temos Cónsul na súa maior parte para todos os clientes.
- E o último punto é revisar os valores dos parámetros. Podemos aumentar estes parámetros coa esperanza de que os nosos problemas de rede a curto prazo sexan curtos e non queden fóra do rango destes parámetros. Deste xeito, podemos reducir a agresividade de Patroni para autoarchivar se ocorren algúns problemas de rede.
Creo que moitos dos que usan Patroni están familiarizados con este comando.
Este comando mostra o estado actual do clúster. E a primeira vista, esta imaxe pode parecer normal. Temos un mestre, temos unha réplica, non hai un atraso de replicación. Pero esta imaxe é normal exactamente ata que sabemos que este clúster debería ter tres nodos, non dous.
En consecuencia, houbo un ficheiro automático. E despois deste ficheiro automático, a nosa réplica desapareceu. Necesitamos descubrir por que desapareceu e traela de volta, restaurala. E de novo imos aos rexistros e vemos por que tivemos un auto-fileover.
Neste caso, a segunda réplica converteuse no mestre. Está todo ben aquí.
E hai que mirar a réplica que caeu e que non está no clúster. Abrimos os rexistros de Patroni e vemos que tivemos un problema durante o proceso de conexión ao clúster na fase pg_wind. Para conectarse ao clúster, cómpre rebobinar o rexistro de transaccións, solicitar o rexistro de transaccións necesario ao mestre e usalo para poñerse ao día co mestre.
Neste caso, non temos un rexistro de transaccións e a réplica non pode iniciarse. En consecuencia, detemos Postgres cun erro. E polo tanto non está no clúster.
Necesitamos entender por que non está no clúster e por que non había rexistros. Imos ao novo mestre e miramos o que ten nos rexistros. Resulta que cando se fixo pg_rewind, ocorreu un punto de control. E algúns dos antigos rexistros de transaccións foron simplemente renomeados. Cando o mestre antigo intentou conectarse ao novo mestre e consultar estes rexistros, xa foron renomeados, simplemente non existían.
Comparei marcas de tempo cando sucederon estes eventos. E alí a diferenza é literalmente de 150 milisegundos, é dicir, o punto de control completouse en 369 milisegundos, os segmentos WAL foron renomeados. E literalmente en 517, despois de 150 milisegundos, comezou o rebobinado na antiga réplica. É dicir, literalmente 150 milisegundos foron suficientes para nós para que a réplica non puidese conectarse e gañar.
Cales son as opcións?
Inicialmente utilizamos slots de replicación. Pensamos que era bo. Aínda que na primeira fase de funcionamento desactivamos as tragamonedas. Pareceunos que se os slots acumulan moitos segmentos de WAL, podemos deixar o mestre. Caerá. Sufrimos un tempo sen slots. E decatámonos de que necesitamos slots, devolvémonos.
Pero hai un problema aquí, que cando o mestre vai á réplica, elimina os slots e elimina os segmentos WAL xunto cos slots. E para eliminar este problema, decidimos aumentar o parámetro wal_keep_segments. Por defecto é 8 segmentos. Subímolo a 1 e miramos canto espazo libre tiñamos. E doamos 000 gigabytes para wal_keep_segments. É dicir, ao cambiar, sempre temos unha reserva de 16 gigabytes de rexistros de transaccións en todos os nodos.
E ademais, aínda é relevante para tarefas de mantemento a longo prazo. Digamos que necesitamos actualizar unha das réplicas. E queremos desactivalo. Necesitamos actualizar o software, quizais o sistema operativo, outra cousa. E cando desactivamos unha réplica, tamén se elimina o slot para esa réplica. E se usamos un pequeno wal_keep_segments, entón cunha longa ausencia dunha réplica, perderanse os rexistros de transaccións. Crearemos unha réplica, solicitará aqueles rexistros de transaccións onde se detivo, pero pode que non estean no mestre. E a réplica tampouco poderá conectarse. Polo tanto, temos un gran stock de revistas.
Temos unha base de produción. Xa hai proxectos en marcha.
Había un arquivo. Entramos e miramos: todo está en orde, as réplicas están no seu lugar, non hai un atraso de replicación. Tampouco hai erros nos rexistros, todo está en orde.
O equipo do produto di que debería haber algúns datos, pero vémolos desde unha fonte, pero non os vemos na base de datos. E hai que entender o que lles pasou.
Está claro que pg_wind os botou de menos. Inmediatamente entendémolo, pero fomos ver que pasaba.
Nos rexistros, sempre podemos atopar cando ocorreu o ficheiro, quen se converteu no mestre e podemos determinar quen era o antigo mestre e cando quería converterse nunha réplica, é dicir, necesitamos estes rexistros para descubrir a cantidade de rexistros de transaccións que estaba perdido.
O noso antigo mestre reiniciou. E Patroni rexistrouse no autorun. Lanzou Patroni. Despois comezou Postgres. Máis precisamente, antes de iniciar Postgres e antes de facelo unha réplica, Patroni lanzou o proceso pg_wind. En consecuencia, borrou parte dos rexistros de transaccións, descargou outros novos e conectouse. Aquí Patroni traballou con intelixencia, é dicir, como se esperaba. Restourouse o clúster. Tivemos 3 nodos, despois do ficheiro 3 nodos - todo é xenial.
Perdemos algúns datos. E hai que entender canto perdemos. Buscamos só o momento no que tivemos un rebobinado. Podemos atopalo en entradas deste tipo de xornal. O rebobinado comezou, fixo algo alí e rematou.
Necesitamos atopar a posición no rexistro de transaccións onde o antigo mestre deixou. Neste caso, esta é a marca. E precisamos unha segunda marca, é dicir, a distancia pola que se diferencia o vello mestre do novo.
Tomamos o pg_wal_lsn_diff habitual e comparamos estas dúas marcas. E neste caso, temos 17 megabytes. Moito ou pouco, cada un decide por si mesmo. Porque para alguén 17 megabytes non son moito, para alguén é moito e inaceptable. Aquí, cada individuo determina por si mesmo de acordo coas necesidades da empresa.
Pero que descubrimos por nós mesmos?
En primeiro lugar, debemos decidir por nós mesmos: sempre necesitamos que Patroni se inicie despois dun reinicio do sistema? Moitas veces pasa que temos que ir ao vello mestre, a ver ata onde chegou. Quizais inspeccione segmentos do rexistro de transaccións, vexa o que hai. E para entender se podemos perder estes datos ou se necesitamos executar o antigo mestre en modo autónomo para extraer estes datos.
E só despois diso debemos decidir se podemos descartar estes datos ou podemos restauralos, conectar este nodo como réplica ao noso clúster.
Ademais, hai un parámetro "maximum_lag_on_failover". De forma predeterminada, se a miña memoria me serve, este parámetro ten un valor de 1 megabyte.
Como traballa? Se a nosa réplica está atrasada 1 megabyte de datos no atraso de replicación, entón esta réplica non participa nas eleccións. E se de súpeto hai un arquivo, Patroni mira que réplicas quedan atrás. Se están atrasados por un gran número de rexistros de transaccións, non poden converterse nun mestre. Esta é unha característica de seguranza moi boa que evita que perdas moitos datos.
Pero hai un problema en que o atraso de replicación no clúster Patroni e DCS actualízase nun intervalo determinado. Creo que 30 segundos é o valor ttl predeterminado.
En consecuencia, pode haber unha situación na que haxa un atraso de replicación para as réplicas en DCS, pero de feito pode haber un atraso completamente diferente ou pode que non haxa ningún atraso, é dicir, isto non é en tempo real. E non sempre reflicte a imaxe real. E non paga a pena facerlle unha lóxica extravagante.
E o risco de perda sempre permanece. E no peor dos casos, unha fórmula, e no caso medio, outra fórmula. É dicir, cando planificamos a implantación de Patroni e avaliamos cantos datos podemos perder, debemos apoiarnos nestas fórmulas e imaxinar a grandes liñas cantos datos podemos perder.
E hai boas novas. Cando o vello mestre saíu adiante, pode seguir adiante debido a algúns procesos de fondo. É dicir, houbo algún tipo de autovacuum, escribiu os datos, gardounos no rexistro de transaccións. E podemos ignorar e perder estes datos facilmente. Non hai problema nisto.
E así se ven os rexistros se se define maximum_lag_on_failover e se produciu un ficheiro e cómpre seleccionar un novo mestre. A réplica avalíase como incapaz de participar nas eleccións. E ela négase a participar na carreira polo líder. E agarda a que se seleccione un novo mestre para poder conectarse a el. Esta é unha medida adicional contra a perda de datos.
Aquí temos un equipo de produtos que escribiu que o seu produto está a ter problemas con Postgres. Ao mesmo tempo, non se pode acceder ao propio mestre, porque non está dispoñible a través de SSH. E o ficheiro automático tampouco ocorre.
Este host foi forzado a reiniciarse. Debido ao reinicio, produciuse un ficheiro automático, aínda que foi posible facer un ficheiro automático manual, segundo entendo agora. E despois do reinicio, xa imos ver que tiñamos co actual mestre.
Ao mesmo tempo, sabiamos de antemán que tiñamos problemas cos discos, é dicir, xa sabiamos por vixilancia onde cavar e que buscar.
Entramos no rexistro de postgres, comezamos a ver que pasaba alí. Vimos compromisos que duran alí un, dous, tres segundos, o que non é nada normal. Vimos que o noso autovacuo comeza moi lentamente e de forma estraña. E vimos ficheiros temporais no disco. É dicir, todos estes son indicadores de problemas cos discos.
Buscamos no sistema dmesg (rexistro do núcleo). E vimos que temos problemas cun dos discos. O subsistema de disco era o software Raid. Miramos /proc/mdstat e vimos que nos faltaba unha unidade. É dicir, hai un Raid de 8 discos, fáltanos un. Se miras atentamente a diapositiva, na saída podes ver que non temos sde alí. A nós, condicionalmente falando, o disco caeu. Isto provocou problemas de disco e as aplicacións tamén experimentaron problemas ao traballar co clúster Postgres.
E neste caso, Patroni non nos axudaría de ningún xeito, porque Patroni non ten a tarefa de supervisar o estado do servidor, o estado do disco. E debemos controlar este tipo de situacións mediante un seguimento externo. Engadimos rapidamente a supervisión de disco á supervisión externa.
E houbo tal pensamento: poderían axudarnos o software de esgrima ou de vixilancia? Pensamos que dificilmente nos tería axudado neste caso, porque durante os problemas Patroni continuou interactuando co clúster DCS e non viu ningún problema. É dicir, dende o punto de vista de DCS e Patroni, todo estaba ben co clúster, aínda que en realidade houbo problemas co disco, houbo problemas coa dispoñibilidade da base de datos.
Na miña opinión, este é un dos problemas máis estraños que investiguei durante moito tempo, lin moitos rexistros, volvín escollelo e chamei simulador de cluster.
O problema era que o antigo mestre non podía converterse nunha réplica normal, é dicir, Patroni iniciouna, Patroni mostrou que este nodo estaba presente como unha réplica, pero ao mesmo tempo non era unha réplica normal. Agora verás por que. Isto é o que conservei da análise dese problema.
E como comezou todo? Comezou, como no problema anterior, con freos de disco. Tiñamos compromisos por un segundo, dous.
Houbo roturas nas conexións, é dicir, os clientes estaban rasgados.
Houbo bloqueos de diversa gravidade.
E, en consecuencia, o subsistema de disco non responde moito.
E o máis misterioso para min é a solicitude de peche inmediato que chegou. Postgres ten tres modos de apagado:
- É gracioso cando agardamos a que todos os clientes se desconecten por si mesmos.
- Hai rápido cando obrigamos aos clientes a desconectarse porque imos pechar.
- E inmediata. Neste caso, inmediato nin sequera lle indica aos clientes que se pechen, só apágase sen previo aviso. E a todos os clientes, o sistema operativo xa envía unha mensaxe RST (unha mensaxe TCP de que a conexión está interrompida e o cliente non ten máis que atrapar).
Quen enviou este sinal? Os procesos en segundo plano de Postgres non se envían tales sinais entre si, é dicir, isto é kill-9. Non se envían tales cousas entre si, só reaccionan ante tales cousas, é dicir, este é un reinicio de emerxencia de Postgres. Quen o enviou, non sei.
Mirei o comando "último" e vin unha persoa que tamén iniciou sesión neste servidor connosco, pero era demasiado tímido para facer unha pregunta. Quizais fose matar -9. Vería kill -9 nos rexistros, porque Postgres di que levou a matar -9, pero non o vin nos rexistros.
Mirando máis aló, vin que Patroni non escribiu no rexistro durante bastante tempo: 54 segundos. E se comparamos dúas marcas de tempo, non houbo mensaxes durante uns 54 segundos.
E durante este tempo houbo un ficheiro automático. Patroni fixo un gran traballo aquí de novo. O noso vello mestre non estaba dispoñible, pasoulle algo. E comezou a elección dun novo mestre. Todo funcionou ben aquí. O noso pgsql01 converteuse no novo líder.
Temos unha réplica que se converteu nun mestre. E hai unha segunda resposta. E houbo problemas coa segunda réplica. Tentou reconfigurarse. Segundo entendo, intentou cambiar recovery.conf, reiniciar Postgres e conectarse ao novo mestre. Ela escribe mensaxes cada 10 segundos que está intentando, pero non o consegue.
E durante estes intentos, un sinal de apagado inmediato chega ao vello mestre. Reiniciarase o mestre. E tamén se detén a recuperación porque o vello mestre entra en reinicio. É dicir, a réplica non pode conectarse a ela, porque está en modo de apagado.
Nalgún momento, funcionou, pero a replicación non comezou.
A miña única suposición é que había un antigo enderezo mestre en recovery.conf. E cando apareceu un novo mestre, a segunda réplica aínda intentaba conectarse co vello mestre.
Cando Patroni iniciouse na segunda réplica, o nodo iniciouse pero non puido replicarse. E formouse un atraso de replicación, que parecía algo así. É dicir, os tres nodos estaban no seu lugar, pero o segundo quedou atrás.
Ao mesmo tempo, se observas os rexistros que se escribiron, podes ver que non se puido iniciar a replicación porque os rexistros de transaccións eran diferentes. E eses rexistros de transaccións que ofrece o mestre, que se especifican en recovery.conf, simplemente non se axustan ao noso nodo actual.
E aquí cometín un erro. Tiven que vir ver o que había en recovery.conf para probar a miña hipótese de que estabamos conectando co mestre incorrecto. Pero entón só estaba lidando con isto e non se me ocorreu, ou vin que a réplica estaba atrasada e habería que recargala, é dicir, traballei dalgunha maneira descoidada. Esta foi a miña articulación.
Despois de 30 minutos, xa chegou o administrador, é dicir, reiniciei Patroni na réplica. Xa lle puxen punto, pensei que habería que encher de novo. E pensei: reiniciarei Patroni, quizais sairá algo bo. A recuperación comezou. E a base aínda se abriu, estaba lista para aceptar conexións.
A replicación comezou. Pero un minuto despois, ela caeu cun erro de que os rexistros de transaccións non son axeitados para ela.
Pensei en reiniciar de novo. Reiniciei Patroni de novo e non reiniciei Postgres, pero reiniciei Patroni coa esperanza de que inicie a base de datos de xeito máxico.
A replicación comezou de novo, pero as marcas no rexistro de transaccións eran diferentes, non eran as mesmas que o intento de inicio anterior. A replicación detívose de novo. E a mensaxe xa era lixeiramente diferente. E non foi moi informativo para min.
E entón ocórreseme: e se reinicio Postgres, neste momento fago un punto de control no mestre actual para avanzar un pouco o punto no rexistro de transaccións para que a recuperación comece noutro momento? Ademais, aínda tiñamos existencias de WAL.
Reiniciei Patroni, fixen un par de puntos de control no master, un par de puntos de reinicio na réplica cando se abriu. E axudou. Pensei durante moito tempo por que axudaba e como funcionaba. E comezou a réplica. E a replicación xa non estaba rasgada.
Tal problema para min é un dos máis misteriosos, sobre o que aínda me desconcerta o que realmente pasou alí.
Cales son as implicacións aquí? Patroni pode funcionar como se pretende e sen erros. Pero, ao mesmo tempo, esta non é unha garantía do 100% de que todo estea ben connosco. A réplica pode comezar, pero pode estar nun estado semi-funcional e a aplicación non pode funcionar con esa réplica, porque haberá datos antigos.
E despois do ficheiro, sempre cómpre comprobar que todo está en orde co clúster, é dicir, hai o número necesario de réplicas, non hai un atraso de replicación.
E mentres pasemos por estas cuestións, farei recomendacións. Tentei combinalos en dúas diapositivas. Probablemente, todas as historias poderían combinarse en dúas diapositivas e só contar.
Cando utilizas Patroni, debes ter un seguimento. Sempre debes saber cando se produciu un autofileover, porque se non sabes que tivo un autofileover, non tes control sobre o clúster. E iso é malo.
Despois de cada ficheiro, sempre temos que comprobar manualmente o clúster. Temos que asegurarnos de que sempre temos un número actualizado de réplicas, que non hai ningún atraso de replicación, que non hai erros nos rexistros relacionados coa replicación por streaming, con Patroni, co sistema DCS.
A automatización pode funcionar con éxito, Patroni é unha ferramenta moi boa. Pode funcionar, pero isto non levará o clúster ao estado desexado. E se non nos enteramos diso, teremos problemas.
E Patroni non é unha bala de prata. Aínda necesitamos entender como funciona Postgres, como funciona a replicación e como funciona Patroni con Postgres, e como se proporciona a comunicación entre os nodos. Isto é necesario para poder solucionar problemas coas mans.
Como abordo o tema do diagnóstico? Ocorreu que traballamos con diferentes clientes e ninguén ten unha pila ELK, e temos que ordenar os rexistros abrindo 6 consolas e 2 pestanas. Nunha pestana, estes son os rexistros de Patroni para cada nodo, na outra pestana, estes son os rexistros de Consul ou Postgres se é necesario. É moi difícil diagnosticar isto.
Que enfoques tomei? En primeiro lugar, sempre miro cando chegou o ficheiro. E para min isto é un punto de partida. Miro o que pasou antes do arquivo, durante o arquivo e despois do arquivo. O ficheiroover ten dúas marcas: esta é a hora de inicio e fin.
A continuación, busco nos rexistros os eventos anteriores ao ficheiro, que precedeu ao ficheiro, é dicir, busco os motivos polos que ocorreu o ficheiro.
E isto dá unha imaxe de comprensión do que pasou e do que se pode facer no futuro para que non se produzan tales circunstancias (e, como resultado, non hai un arquivo).
E onde miramos normalmente? Vexo:
- Primeiro, aos rexistros de Patroni.
- A continuación, miro os rexistros de Postgres, ou os rexistros de DCS, dependendo do que se atope nos rexistros de Patroni.
- E os rexistros do sistema tamén ás veces dan unha comprensión do que causou o ficheiro.
Como me parece Patroni? Teño moi boa relación con Patroni. Na miña opinión, este é o mellor que hai hoxe. Coñezo moitos outros produtos. Estes son Stolon, Repmgr, Pg_auto_failover, PAF. 4 ferramentas. Probeinos todos. Patroni é o meu favorito.
Se me preguntan: "Recomendo Patroni?". Direi que si, porque me gusta Patroni. E creo que aprendín a cociñalo.
Se estás interesado en ver que outros problemas hai con Patroni ademais dos problemas que mencionei, sempre podes consultar a páxina en GitHub. Hai moitas historias diferentes e alí se tratan moitos temas interesantes. E como resultado, introducíronse e resolvéronse algúns erros, é dicir, esta é unha lectura interesante.
Hai algunhas historias interesantes sobre as persoas que se disparan no pé. Moi informativo. Le e comprende que non é necesario facelo. Marqueime a min mesmo.
E gustaríame darlle as grazas a Zalando por desenvolver este proxecto, é dicir, a Alexander Kukushkin e Alexey Klyukin. Aleksey Klyukin é un dos coautores, xa non traballa en Zalando, pero son dúas persoas que comezaron a traballar con este produto.
E creo que Patroni é unha cousa moi chula. Estou feliz de que exista, é interesante con ela. E moitas grazas a todos os colaboradores que escriben parches a Patroni. Espero que Patroni sexa máis maduro, fresco e eficiente coa idade. Xa é funcional, pero espero que mellore aínda. Polo tanto, se pensas usar Patroni, non teñas medo. Esta é unha boa solución, pódese implementar e usar.
Iso é todo. Se tes preguntas, pregunta.
preguntas
Grazas polo informe! Se despois dun arquivo aínda necesitas mirar alí con moito coidado, entón por que necesitamos un arquivo automático?
Porque son cousas novas. Só levamos un ano con ela. Mellor estar seguro. Queremos entrar e ver que todo funcionou como debería. Este é o nivel de desconfianza dos adultos: é mellor comprobar e ver.
Por exemplo, fomos pola mañá e miramos, non?
Non pola mañá, normalmente aprendemos sobre o ficheiro automático case inmediatamente. Recibimos notificacións, vemos que se produciu un ficheiro automático. Case inmediatamente imos mirar. Pero todas estas comprobacións deberían levarse ao nivel de vixilancia. Se accedes a Patroni a través da API REST, hai un historial. Segundo o historial, podes ver as marcas de tempo cando se produciu o ficheiro. En base a isto pódese facer un seguimento. Podes ver a historia, cantos acontecementos houbo. Se temos máis eventos, ocorreu un ficheiro automático. Podes ir e ver. Ou a nosa automatización de vixilancia comprobou que temos todas as réplicas no seu lugar, non hai ningún atraso e todo está ben.
Grazas!
Moitas grazas pola gran historia! Se movemos o clúster DCS a algún lugar lonxe do clúster de Postgres, entón este clúster tamén necesita ser atendido periodicamente? Cales son as mellores prácticas que precisan desactivar algunhas pezas do clúster DCS, facer algo con elas, etc.? Como sobrevive toda esta estrutura? E como fas estas cousas?
Para unha empresa, foi necesario facer unha matriz de problemas, que pasa se un dos compoñentes ou varios compoñentes fallan. Segundo esta matriz, percorremos secuencialmente todos os compoñentes e construímos escenarios en caso de falla destes compoñentes. En consecuencia, para cada escenario de fallo, pode ter un plan de acción para a recuperación. E no caso de DCS, vén como parte da infraestrutura estándar. E o administrador o administra, e xa confiamos nos administradores que o administran e na súa capacidade para solucionalo en caso de accidente. Se non hai DCS en absoluto, entón implantámolo, pero ao mesmo tempo non o monitorizamos especialmente, porque non somos responsables da infraestrutura, pero damos recomendacións sobre como e que supervisar.
É dicir, entendín correctamente que teño que desactivar Patroni, desactivar o ficheiro, desactivar todo antes de facer nada cos hosts?
Depende de cantos nodos teñamos no clúster DCS. Se hai moitos nodos e se desactivamos só un dos nós (a réplica), entón o clúster mantén un quórum. E Patroni segue operativo. E non se dispara nada. Se temos algunhas operacións complexas que afectan a máis nodos, cuxa ausencia pode arruinar o quórum, entón, si, pode ter sentido poñer a Patroni en pausa. Ten un comando correspondente: patronictl pause, patronictl resume. Facemos unha pausa e o ficheiro automático non funciona nese momento. Facemos mantemento no clúster DCS, despois despegamos a pausa e seguimos vivindo.
Moitas grazas!
Moitas grazas polo teu informe! Como se sente o equipo do produto sobre a perda de datos?
Aos equipos de produto non lles importa, e os responsables do equipo están preocupados.
Que garantías hai?
As garantías son moi difíciles. Alexander Kukushkin ten un informe "Como calcular RPO e RTO", é dicir, o tempo de recuperación e cantos datos podemos perder. Creo que hai que buscar estas diapositivas e estudalas. Polo que recordo, hai pasos específicos sobre como calcular estas cousas. Cantas transaccións podemos perder, cantos datos podemos perder. Como opción, podemos utilizar a replicación síncrona a nivel de Patroni, pero esta é unha arma de dobre fío: ou temos fiabilidade dos datos ou perdemos velocidade. Hai replicación síncrona, pero tampouco garante o 100% de protección contra a perda de datos.
Alexey, grazas polo gran informe! Algunha experiencia co uso de Patroni para protección de nivel cero? É dicir, en conxunto co modo de espera sincrónico? Esta é a primeira pregunta. E a segunda pregunta. Usaches diferentes solucións. Usamos Repmgr, pero sen ficheiro automático, e agora estamos a planear incluír o ficheiro automático. E consideramos a Patroni como unha solución alternativa. Que podes dicir como vantaxes en comparación con Repmgr?
A primeira pregunta foi sobre as réplicas síncronas. Ninguén usa a replicación sincrónica aquí, porque todos teñen medo (varios clientes xa a están a usar, en principio, non notaron problemas de rendemento - Nota do orador). Pero elaboramos unha regra para nós mesmos de que debería haber polo menos tres nodos nun clúster de replicación síncrona, porque se temos dous nodos e se falla o mestre ou a réplica, Patroni cambia este nodo ao modo Autónomo para que a aplicación continúe funcionando. traballo. Neste caso, existe o risco de perda de datos.
Respecto da segunda pregunta, usamos Repmgr e aínda o facemos con algúns clientes por razóns históricas. Que se pode dicir? Patroni inclúe un ficheiro automático fóra da caixa, Repmgr inclúe o ficheiro automático como unha función adicional que debe activarse. Necesitamos executar o daemon Repmgr en cada nodo e despois podemos configurar o ficheiro automático.
Repmgr comproba se os nodos de Postgres están activos. Os procesos de Repmgr verifican a existencia uns dos outros, este non é un enfoque moi eficiente. pode haber casos complexos de illamento de rede nos que un gran clúster de Repmgr pode desfacerse en varios máis pequenos e seguir traballando. Hai tempo que non sigo a Repmgr, quizais se solucionou... ou quizais non. Pero a eliminación da información sobre o estado do clúster en DCS, como fai Stolon, Patroni, é a opción máis viable.
Alexey, teño unha pregunta, quizais unha coxa. Nun dos primeiros exemplos, moveches DCS da máquina local a un host remoto. Entendemos que a rede é unha cousa que ten as súas propias características, vive soa. E que pasa se por algún motivo o clúster DCS non está dispoñible? Non vou dicir as razóns, pode haber moitas: desde as mans tortas dos networkers ata problemas reais.
Non o dixen en voz alta, pero o clúster DCS tamén debe ser conmutación por fallo, é dicir, é un número impar de nodos, para que se cumpra un quórum. Que ocorre se o clúster DCS non está dispoñible ou non se pode cumprir un quórum, é dicir, algún tipo de división de rede ou fallo de nodo? Neste caso, o clúster Patroni pasa ao modo de só lectura. O clúster de Patroni non pode determinar o estado do clúster e que facer. Non pode contactar co DCS e almacenar alí o novo estado do clúster, polo que todo o clúster pasa a só lectura. E agarda a intervención manual do operador ou a que se recupere o DCS.
En liñas xerais, DCS convértese nun servizo para nós tan importante como a propia base?
Si Si. En tantas empresas modernas, Service Discovery é unha parte integrante da infraestrutura. Estase implementando incluso antes de que existise unha base de datos na infraestrutura. Relativamente falando, a infraestrutura foi lanzada, despregada no DC, e inmediatamente temos Service Discovery. Se é Cónsul, pódese crear DNS nel. Se isto é Etcd, entón pode haber unha parte do clúster de Kubernetes, na que se despregará todo o demais. Paréceme que Service Discovery xa é parte integrante das modernas infraestruturas. E pensan niso moito antes que nas bases de datos.
Grazas!
Fonte: www.habr.com