El objetivo principal de Patroni es proporcionar alta disponibilidad para PostgreSQL. Pero Patroni es solo una plantilla, no una herramienta lista para usar (que, en general, se dice en la documentación). A primera vista, después de configurar Patroni en el laboratorio de pruebas, puede ver qué gran herramienta es y qué tan fácil maneja nuestros intentos de romper el clúster. Sin embargo, en la práctica, en un entorno de producción, no siempre todo sucede tan bien y con tanta elegancia como en un laboratorio de pruebas.
Te contaré un poco sobre mí. Empecé como administrador de sistemas. Trabajó en desarrollo web. Trabajo en Data Egret desde 2014. La empresa se dedica a la consultoría en el campo de Postgres. Y servimos exactamente Postgres, y trabajamos con Postgres todos los días, por lo que tenemos diferentes conocimientos relacionados con la operación.
Y a fines de 2018, comenzamos a usar Patroni lentamente. Y se ha acumulado algo de experiencia. De alguna manera lo diagnosticamos, lo ajustamos, llegamos a nuestras mejores prácticas. Y en este reportaje hablaré de ellos.
Aparte de Postgres, me encanta Linux. Me gusta hurgar y explorar, me gusta coleccionar núcleos. Me encanta la virtualización, los contenedores, docker, Kubernetes. Todo esto me interesa, porque los viejos hábitos administrativos están afectando. Me gusta lidiar con el monitoreo. Y me encantan las cosas de postgres relacionadas con la administración, es decir, la replicación, la copia de seguridad. Y en mi tiempo libre escribo en Go. No soy ingeniero de software, solo escribo para mí en Go. Y me da placer.
- Creo que muchos de ustedes saben que Postgres no tiene HA (alta disponibilidad) lista para usar. Para obtener HA, debe instalar algo, configurarlo, hacer un esfuerzo y obtenerlo.
- Hay varias herramientas y Patroni es una de ellas que resuelve HA muy bien y muy bien. Pero al ponerlo todo en un laboratorio de prueba y ejecutarlo, podemos ver que todo funciona, podemos reproducir algunos problemas, ver cómo los atiende Patroni. Y veremos que todo funciona de maravilla.
- Pero en la práctica, nos enfrentamos a diferentes problemas. Y voy a hablar de estos problemas.
- Te diré cómo lo diagnosticamos, qué modificamos, si nos ayudó o no.
- No te diré cómo instalar Patroni, porque puedes googlear en Internet, puedes mirar los archivos de configuración para entender cómo comienza todo, cómo se configura. Puede comprender los esquemas, las arquitecturas y encontrar información al respecto en Internet.
- No voy a hablar de la experiencia de otra persona. Solo hablaré de los problemas que enfrentamos.
- Y no hablaré de problemas que están fuera de Patroni y PostgreSQL. Si, por ejemplo, hay problemas asociados con el equilibrio, cuando nuestro clúster se ha derrumbado, no hablaré de eso.
Y un pequeño descargo de responsabilidad antes de comenzar nuestro informe.
Todos estos problemas que encontramos, los tuvimos en los primeros 6-7-8 meses de funcionamiento. Con el tiempo, llegamos a nuestras mejores prácticas internas. Y nuestros problemas desaparecieron. Por lo tanto, el informe se anunció hace unos seis meses, cuando estaba todo fresco en mi cabeza y lo recordaba todo perfectamente.
En el curso de la preparación del informe, ya levanté autopsias antiguas, miré los registros. Y algunos de los detalles podrían olvidarse, o algunos de algunos detalles no podrían investigarse completamente durante el análisis de los problemas, por lo que en algunos puntos puede parecer que los problemas no se consideran completamente, o hay alguna falta de información. Y por eso te pido que me disculpes por este momento.
¿Qué es Patroni?
- Esta es una plantilla para construir HA. Eso es lo que dice en la documentación. Y desde mi punto de vista, esta es una aclaración muy correcta. Patroni no es una bala de plata que resolverá todos tus problemas, es decir, debes esforzarte para que funcione y traiga beneficios.
- Este es un servicio de agente que se instala en cada servicio de base de datos y es una especie de sistema de inicio para su Postgres. Inicia Postgres, se detiene, reinicia, reconfigura y cambia la topología de su clúster.
- En consecuencia, para almacenar el estado del clúster, su representación actual, tal como parece, se necesita algún tipo de almacenamiento. Y desde este punto de vista, Patroni tomó el camino de almacenar el estado en un sistema externo. Es un sistema de almacenamiento de configuración distribuida. Puede ser Etcd, Consul, ZooKeeper o kubernetes Etcd, es decir, una de estas opciones.
- Y una de las características de Patroni es que obtiene el autofiler listo para usar, solo configurándolo. Si tomamos Repmgr para comparar, entonces el archivador está incluido allí. Con Repmgr, obtenemos un cambio, pero si queremos un autofiler, entonces debemos configurarlo adicionalmente. Patroni ya tiene un filtro automático listo para usar.
- Y hay muchas otras cosas. Por ejemplo, mantenimiento de configuraciones, vertido de nuevas réplicas, copia de seguridad, etc. Pero esto está más allá del alcance del informe, no hablaré de eso.
Y un pequeño resultado es que la tarea principal de Patroni es hacer un autofile bien y de forma fiable para que nuestro clúster siga operativo y la aplicación no note cambios en la topología del clúster.
Pero cuando comenzamos a usar Patroni, nuestro sistema se vuelve un poco más complicado. Si antes teníamos Postgres, entonces cuando usamos Patroni obtenemos Patroni mismo, obtenemos DCS donde se almacena el estado. Y todo tiene que funcionar de alguna manera. Entonces, ¿qué puede salir mal?
Puede romperse:
- Postgres podría romperse. Puede ser un maestro o una réplica, uno de ellos puede fallar.
- El propio Patroni puede romperse.
- El DCS donde se almacena el estado puede romperse.
- Y la red puede romperse.
Todos estos puntos los consideraré en el informe.
Consideraré los casos a medida que se vuelvan más complejos, no desde el punto de vista de que el caso involucra muchos componentes. Y desde el punto de vista de los sentimientos subjetivos, que este caso fue difícil para mí, fue difícil desmontarlo ... y viceversa, algún caso fue ligero y fue fácil desmontarlo.
Y el primer caso es el más fácil. Este es el caso cuando tomamos un clúster de base de datos e implementamos nuestro almacenamiento DCS en el mismo clúster. Este es el error más común. Este es un error en la construcción de arquitecturas, es decir, combinar diferentes componentes en un solo lugar.
Entonces, hubo un archivador, vamos a lidiar con lo que pasó.
Y aquí nos interesa cuándo sucedió el archivador. Es decir, estamos interesados en este momento en el tiempo cuando cambió el estado del clúster.
Pero el archivador no siempre es instantáneo, es decir, no toma ninguna unidad de tiempo, puede retrasarse. Puede ser de larga duración.
Por lo tanto, tiene una hora de inicio y una hora de finalización, es decir, es un evento continuo. Y dividimos todos los eventos en tres intervalos: tenemos tiempo antes del archivador, durante el archivador y después del archivador. Es decir, consideramos todos los eventos en esta línea de tiempo.
Y lo primero, cuando pasa un archivador, buscamos la causa de lo que pasó, cuál fue la causa de lo que llevó al archivador.
Si nos fijamos en los logs, serán los clásicos logs de Patroni. Nos dice en ellos que el servidor se ha convertido en el maestro, y el rol del maestro ha pasado a este nodo. Aquí se destaca.
A continuación, debemos entender por qué sucedió el archivador, es decir, qué eventos ocurrieron que causaron que el rol maestro se moviera de un nodo a otro. Y en este caso, todo es simple. Tenemos un error al interactuar con el sistema de almacenamiento. El maestro se dio cuenta de que no podía trabajar con DCS, es decir, había algún tipo de problema con la interacción. Y dice que ya no puede ser maestro y renuncia. Esta línea "yo degradado" dice exactamente eso.
Si observamos los eventos que precedieron al archivador, podemos ver allí las mismas razones que fueron el problema para la continuación del asistente.
Si miramos los registros de Patroni, veremos que tenemos muchos errores, tiempos de espera, es decir, el agente de Patroni no puede trabajar con DCS. En este caso, este es el agente Consul, que se comunica en el puerto 8500.
Y el problema aquí es que Patroni y la base de datos se ejecutan en el mismo host. Y los servidores de Consul se lanzaron en el mismo nodo. Al crear una carga en el servidor, también creamos problemas para los servidores de Consul. No podían comunicarse correctamente.
Después de un tiempo, cuando la carga disminuyó, nuestro Patroni pudo comunicarse nuevamente con los agentes. Se reanudó el trabajo normal. Y el mismo servidor Pgdb-2 volvió a ser el maestro. Es decir, hubo un pequeño giro, por lo que el nodo renunció a los poderes del maestro y luego los tomó de nuevo, es decir, todo volvió como estaba.
Y esto se puede considerar como una falsa alarma, o se puede considerar que Patroni hizo todo bien. Es decir, se dio cuenta de que no podía mantener el estado del cúmulo y le quitó la autoridad.
Y aquí surgió el problema por el hecho de que los servidores de Consul están en el mismo hardware que las bases. En consecuencia, cualquier carga: ya sea la carga en discos o procesadores, también afecta la interacción con el clúster Consul.
Y decidimos que no deberían vivir juntos, asignamos un grupo separado para Consul. Y Patroni ya estaba trabajando con un Consul separado, es decir, había un grupo de Postgres separado, un grupo de Consul separado. Esta es una instrucción básica sobre cómo llevar y guardar todas estas cosas para que no convivan.
Como opción, puede torcer los parámetros ttl, loop_wait, retry_timeout, es decir, tratar de sobrevivir a estos picos de carga a corto plazo aumentando estos parámetros. Pero esta no es la opción más adecuada, porque esta carga puede ser larga en el tiempo. Y simplemente iremos más allá de estos límites de estos parámetros. Y eso realmente podría no ayudar.
El primer problema, como usted entiende, es simple. Tomamos y juntamos el DCS con la base, tenemos un problema.
El segundo problema es similar al primero. Es similar en que nuevamente tenemos problemas de interoperabilidad con el sistema DCS.
Si miramos los logs, veremos que nuevamente tenemos un error de comunicación. Y Patroni dice que no puedo interactuar con DCS, por lo que el maestro actual entra en modo réplica.
El viejo maestro se convierte en una réplica, aquí Patroni funciona, como debe ser. Ejecuta pg_rewind para rebobinar el registro de transacciones y luego conectarse al nuevo maestro para ponerse al día con el nuevo maestro. Aquí Patroni se ejercita, como debe.
Aquí debemos encontrar el lugar que precedió al archivador, es decir, aquellos errores que nos hicieron tener un archivador. Y en este sentido, los registros de Patroni son bastante convenientes para trabajar. Escribe los mismos mensajes en un cierto intervalo. Y si comenzamos a desplazarnos rápidamente por estos registros, veremos en los registros que los registros han cambiado, lo que significa que han comenzado algunos problemas. Regresamos rápidamente a este lugar, a ver qué pasa.
Y en una situación normal, los registros se ven así. Se comprueba el propietario de la cerradura. Y si el propietario, por ejemplo, ha cambiado, entonces pueden ocurrir algunos eventos a los que Patroni debe responder. Pero en este caso, estamos bien. Estamos buscando el lugar donde comenzaron los errores.
Y después de desplazarnos hasta el punto donde comenzaron a aparecer los errores, vemos que hemos tenido un archivo automático. Y dado que nuestros errores estaban relacionados con la interacción con DCS y en nuestro caso usamos Consul, también miramos los registros de Consul, lo que sucedió allí.
Comparando aproximadamente el tiempo del archivador y el tiempo en los registros de Cónsul, vemos que nuestros vecinos en el grupo de Cónsul comenzaron a dudar de la existencia de otros miembros del grupo de Cónsul.
Y si también observa los registros de otros agentes de Consul, también puede ver que allí se está produciendo algún tipo de colapso de la red. Y todos los miembros del grupo Cónsul dudan de la existencia de los demás. Y este fue el impulso para el archivador.
Si observa lo que sucedió antes de estos errores, puede ver que hay todo tipo de errores, por ejemplo, fecha límite, caída de RPC, es decir, claramente hay algún tipo de problema en la interacción de los miembros del clúster Consul entre sí. .
La respuesta más simple es reparar la red. Pero para mí, de pie en el podio, es fácil decir esto. Pero las circunstancias son tales que no siempre el cliente puede permitirse reparar la red. Es posible que viva en un DC y que no pueda reparar la red, afectar el equipo. Y entonces se necesitan algunas otras opciones.
Hay opciones:
- La opción más simple, que está escrita, en mi opinión, incluso en la documentación, es deshabilitar las comprobaciones de Consul, es decir, simplemente pasar una matriz vacía. Y le decimos al agente del Cónsul que no use ningún cheque. Con estas comprobaciones, podemos ignorar estas tormentas de red y no iniciar un filtro.
- Otra opción es verificar dos veces raft_multiplier. Este es un parámetro del propio servidor Consul. De forma predeterminada, se establece en 5. La documentación recomienda este valor para entornos de ensayo. De hecho, esto afecta la frecuencia de los mensajes entre los miembros de la red Consul. De hecho, este parámetro afecta la velocidad de comunicación del servicio entre los miembros del clúster Consul. Y para la producción, ya se recomienda reducirlo para que los nodos intercambien mensajes con más frecuencia.
- Otra opción que se nos ocurrió es aumentar la prioridad de los procesos de Consul entre otros procesos para el planificador de procesos del sistema operativo. Hay un parámetro tan "agradable", que simplemente determina la prioridad de los procesos que el programador del sistema operativo tiene en cuenta al programar. También hemos reducido el valor agradable para los agentes de Consul, es decir. aumentó la prioridad para que el sistema operativo le dé a los procesos de Consul más tiempo para trabajar y ejecutar su código. En nuestro caso, esto resolvió nuestro problema.
- Otra opción es no usar Consul. Tengo un amigo que es un gran partidario de Etcd. Y regularmente discutimos con él cuál es mejor Etcd o Consul. Pero en términos de cuál es mejor, generalmente estamos de acuerdo con él en que Consul tiene un agente que debería ejecutarse en cada nodo con una base de datos. Es decir, la interacción de Patroni con el cluster Cónsul pasa por este agente. Y este agente se convierte en un cuello de botella. Si algo le sucede al agente, entonces Patroni ya no puede trabajar con el clúster de Consul. Y este es el problema. No hay ningún agente en el plan Etcd. Patroni puede trabajar directamente con una lista de servidores Etcd y ya comunicarse con ellos. En este sentido, si usa Etcd en su empresa, probablemente Etcd sea una mejor opción que Consul. Pero nosotros, en nuestros clientes, siempre estamos limitados por lo que el cliente ha elegido y usa. Y tenemos Cónsul en su mayor parte para todos los clientes.
- Y el último punto es revisar los valores de los parámetros. Podemos aumentar estos parámetros con la esperanza de que nuestros problemas de red a corto plazo sean breves y no queden fuera del rango de estos parámetros. De esta manera podemos reducir la agresividad de Patroni para autoarchivar si ocurren algunos problemas de red.
Creo que muchos de los que usan Patroni están familiarizados con este comando.
Este comando muestra el estado actual del clúster. Y a primera vista, esta imagen puede parecer normal. Tenemos un maestro, tenemos una réplica, no hay retraso en la replicación. Pero esta imagen es exactamente normal hasta que sabemos que este grupo debe tener tres nodos, no dos.
En consecuencia, había un archivo automático. Y después de este autoarchivo, nuestra réplica desapareció. Tenemos que averiguar por qué desapareció y traerla de vuelta, restaurarla. Y de nuevo vamos a los registros y vemos por qué tuvimos una transferencia automática de archivos.
En este caso, la segunda réplica se convirtió en la maestra. Todo está bien aquí.
Y tenemos que mirar la réplica que se cayó y que no está en el grupo. Abrimos los registros de Patroni y vemos que tuvimos un problema durante el proceso de conexión al clúster en la etapa pg_rewind. Para conectarse al clúster, debe rebobinar el registro de transacciones, solicitar el registro de transacciones requerido del maestro y usarlo para ponerse al día con el maestro.
En este caso, no tenemos un registro de transacciones y la réplica no puede iniciarse. En consecuencia, detenemos Postgres con un error. Y por lo tanto no está en el clúster.
Necesitamos entender por qué no está en el clúster y por qué no hubo registros. Vamos al nuevo maestro y miramos lo que tiene en los registros. Resulta que cuando se hizo pg_rewind, se produjo un punto de control. Y algunos de los registros de transacciones antiguos simplemente fueron renombrados. Cuando el antiguo maestro intentó conectarse al nuevo maestro y consultar estos registros, ya se les cambió el nombre, simplemente no existían.
Comparé las marcas de tiempo cuando ocurrieron estos eventos. Y ahí la diferencia es literalmente de 150 milisegundos, es decir, el punto de control se completó en 369 milisegundos, se renombró los segmentos WAL. Y literalmente en 517, después de 150 milisegundos, comenzó el rebobinado en la réplica anterior. Es decir, literalmente nos bastaron 150 milisegundos para que la réplica no pudiera conectarse y ganar.
¿Cuáles son las opciones?
Inicialmente usamos ranuras de replicación. Pensamos que era bueno. Aunque en la primera etapa de operación apagamos las máquinas tragamonedas. Nos pareció que si las tragamonedas acumulan muchos segmentos WAL, podemos eliminar el maestro. Él caerá. Sufrimos durante algún tiempo sin ranuras. Y nos dimos cuenta de que necesitamos franjas horarias, devolvimos las franjas horarias.
Pero aquí hay un problema, que cuando el maestro va a la réplica, elimina las ranuras y elimina los segmentos WAL junto con las ranuras. Y para eliminar este problema, decidimos aumentar el parámetro wal_keep_segments. Por defecto es de 8 segmentos. Lo subimos a 1 y miramos cuánto espacio libre teníamos. Y donamos 000 gigabytes para wal_keep_segments. Es decir, al cambiar, siempre tenemos una reserva de 16 gigabytes de registros de transacciones en todos los nodos.
Y además, sigue siendo relevante para tareas de mantenimiento a largo plazo. Digamos que necesitamos actualizar una de las réplicas. Y queremos apagarlo. Necesitamos actualizar el software, tal vez el sistema operativo, algo más. Y cuando apagamos una réplica, también se elimina la ranura para esa réplica. Y si usamos un wal_keep_segments pequeño, entonces con una larga ausencia de una réplica, los registros de transacciones se perderán. Crearemos una réplica, solicitará los registros de transacciones donde se detuvo, pero es posible que no estén en el maestro. Y la réplica tampoco podrá conectarse. Por ello, mantenemos un amplio stock de revistas.
Tenemos una base de producción. Ya hay proyectos en curso.
Había un archivador. Entramos y miramos: todo está en orden, las réplicas están en su lugar, no hay retraso en la replicación. Tampoco hay errores en los registros, todo está en orden.
El equipo de producto dice que debería haber algunos datos, pero los vemos de una fuente, pero no los vemos en la base de datos. Y tenemos que entender lo que les pasó.
Está claro que pg_rewind los extrañó. Inmediatamente entendimos esto, pero fuimos a ver qué estaba pasando.
En los registros, siempre podemos encontrar cuándo sucedió el archivador, quién se convirtió en el maestro, y podemos determinar quién era el maestro anterior y cuándo quería convertirse en una réplica, es decir, necesitamos estos registros para averiguar la cantidad de registros de transacciones que se perdió.
Nuestro viejo maestro se ha reiniciado. Y Patroni quedó registrado en el autorun. Patroni lanzado. Luego comenzó Postgres. Más precisamente, antes de iniciar Postgres y antes de hacer una réplica, Patroni lanzó el proceso pg_rewind. En consecuencia, borró parte de los registros de transacciones, descargó otros nuevos y se conectó. Aquí Patroni funcionó de manera inteligente, es decir, como se esperaba. El clúster ha sido restaurado. Teníamos 3 nodos, después del archivador 3 nodos: todo está bien.
Hemos perdido algunos datos. Y tenemos que entender cuánto hemos perdido. Estamos buscando justo el momento en que tuvimos un rebobinado. Podemos encontrarlo en tales entradas de diario. Rewind comenzó, hizo algo allí y terminó.
Necesitamos encontrar la posición en el registro de transacciones donde lo dejó el maestro anterior. En este caso, esta es la marca. Y necesitamos una segunda marca, es decir, la distancia en la que el viejo maestro difiere del nuevo.
Tomamos el pg_wal_lsn_diff habitual y comparamos estas dos marcas. Y en este caso, obtenemos 17 megas. Mucho o poco, cada uno decide por sí mismo. Porque para alguien 17 megas no es mucho, para alguien es mucho e inaceptable. Aquí, cada individuo determina por sí mismo de acuerdo con las necesidades del negocio.
Pero, ¿qué hemos descubierto por nosotros mismos?
Primero, debemos decidir por nosotros mismos: ¿siempre necesitamos que Patroni se inicie automáticamente después de reiniciar el sistema? A menudo sucede que tenemos que ir al viejo maestro, ver hasta dónde ha llegado. Tal vez inspeccionar segmentos del registro de transacciones, ver qué hay allí. Y para comprender si podemos perder estos datos o si necesitamos ejecutar el antiguo maestro en modo independiente para extraer estos datos.
Y solo después de eso debemos decidir si podemos descartar estos datos o podemos restaurarlos, conectar este nodo como una réplica a nuestro clúster.
Además, hay un parámetro "maximum_lag_on_failover". Por defecto, si no me falla la memoria, este parámetro tiene un valor de 1 megabyte.
¿Cómo trabaja? Si nuestra réplica tiene un retraso de 1 megabyte de datos en el retraso de la replicación, entonces esta réplica no participa en las elecciones. Y si de repente hay una superposición de archivos, Patroni analiza qué réplicas se están quedando atrás. Si están atrasados por una gran cantidad de registros de transacciones, no pueden convertirse en maestros. Esta es una característica de seguridad muy buena que le impide perder una gran cantidad de datos.
Pero existe el problema de que el retraso de la replicación en el clúster de Patroni y DCS se actualiza en un intervalo determinado. Creo que 30 segundos es el valor ttl predeterminado.
En consecuencia, puede haber una situación en la que haya un retraso de replicación para las réplicas en DCS, pero de hecho puede haber un retraso completamente diferente o puede que no haya ningún retraso, es decir, esto no es en tiempo real. Y no siempre refleja la imagen real. Y no vale la pena hacer una lógica elegante al respecto.
Y el riesgo de pérdida siempre permanece. Y en el peor de los casos, una fórmula, y en el caso medio, otra fórmula. Es decir, cuando planificamos la implementación de Patroni y evaluamos cuántos datos podemos perder, debemos confiar en estas fórmulas e imaginarnos a grandes rasgos cuántos datos podemos perder.
Y hay buenas noticias. Cuando el viejo maestro se ha adelantado, puede hacerlo debido a algunos procesos en segundo plano. Es decir, hubo algún tipo de autovacío, escribió los datos, los guardó en el registro de transacciones. Y podemos ignorar y perder fácilmente estos datos. No hay problema en esto.
Y así es como se ven los registros si se establece maximum_lag_on_failover y se ha producido un archivador, y debe seleccionar un nuevo maestro. La réplica se evalúa a sí misma como incapaz de participar en las elecciones. Y ella se niega a participar en la carrera por el líder. Y espera a que se seleccione un nuevo maestro, para luego conectarse a él. Esta es una medida adicional contra la pérdida de datos.
Aquí tenemos un equipo de producto que escribió que su producto tiene problemas con Postgres. Al mismo tiempo, no se puede acceder al maestro en sí, porque no está disponible a través de SSH. Y el autofile tampoco pasa.
Este host se vio obligado a reiniciar. Debido al reinicio, ocurrió un archivo automático, aunque era posible hacer un archivo automático manual, como ahora entiendo. Y tras el reinicio, ya vamos a ver lo que teníamos con el maestro actual.
Al mismo tiempo, sabíamos de antemano que teníamos problemas con los discos, es decir, ya sabíamos por monitoreo dónde cavar y qué buscar.
Entramos en el registro de postgres, comenzamos a ver qué estaba pasando allí. Vimos commits que duran allí uno, dos, tres segundos, lo cual no es nada normal. Vimos que nuestro autovacío arranca muy lento y de forma extraña. Y vimos archivos temporales en el disco. Es decir, todos estos son indicadores de problemas con los discos.
Miramos en el sistema dmesg (registro del kernel). Y vimos que tenemos problemas con uno de los discos. El subsistema de disco era el software Raid. Examinamos /proc/mdstat y vimos que nos faltaba una unidad. Es decir, hay un Raid de 8 discos, nos falta uno. Si observa cuidadosamente la diapositiva, en la salida puede ver que no tenemos sde allí. A nosotros, condicionalmente hablando, el disco se ha caído. Esto desencadenó problemas de disco y las aplicaciones también experimentaron problemas al trabajar con el clúster de Postgres.
Y en este caso, Patroni no nos ayudaría en nada, porque Patroni no tiene la tarea de monitorear el estado del servidor, el estado del disco. Y debemos monitorear tales situaciones mediante un monitoreo externo. Rápidamente agregamos el monitoreo de disco al monitoreo externo.
Y hubo tal pensamiento: ¿podría ayudarnos el software de esgrima o de vigilancia? Pensamos que difícilmente nos habría ayudado en este caso, porque durante los problemas Patroni siguió interactuando con el clúster DCS y no vio ningún problema. Es decir, desde el punto de vista de DCS y Patroni, todo estaba bien con el clúster, aunque en realidad había problemas con el disco, había problemas con la disponibilidad de la base de datos.
En mi opinión, este es uno de los problemas más extraños que he investigado durante mucho tiempo, he leído muchos registros, volví a elegir y lo llamé simulador de clúster.
El problema era que el antiguo maestro no podía convertirse en una réplica normal, es decir, Patroni lo inició, Patroni mostró que este nodo estaba presente como una réplica, pero al mismo tiempo no era una réplica normal. Ahora verás por qué. Esto es lo que he guardado del análisis de ese problema.
¿Y cómo empezó todo? Empezó, como en el problema anterior, con frenos de disco. Tuvimos compromisos por un segundo, dos.
Hubo interrupciones en las conexiones, es decir, los clientes estaban desgarrados.
Hubo bloqueos de diversa gravedad.
Y, en consecuencia, el subsistema del disco no responde muy bien.
Y lo más misterioso para mí es la solicitud de apagado inmediato que llegó. Postgres tiene tres modos de apagado:
- Es elegante cuando esperamos a que todos los clientes se desconecten solos.
- Hay rápido cuando obligamos a los clientes a desconectarse porque vamos a cerrar.
- e inmediato En este caso, inmediato ni siquiera les dice a los clientes que se apaguen, simplemente se apaga sin previo aviso. Y a todos los clientes, el sistema operativo ya envía un mensaje RST (un mensaje TCP de que la conexión se interrumpió y el cliente no tiene nada más que atrapar).
¿Quién envió esta señal? Los procesos en segundo plano de Postgres no se envían tales señales entre sí, es decir, esto es kill-9. No se envían tales cosas entre sí, solo reaccionan a tales cosas, es decir, este es un reinicio de emergencia de Postgres. Quién lo envió, no lo sé.
Miré el comando "último" y vi a una persona que también inició sesión en este servidor con nosotros, pero era demasiado tímido para hacer una pregunta. Tal vez fue matar -9. Vería kill -9 en los registros, porque Postgres dice que tomó kill -9, pero no lo vi en los registros.
Mirando más allá, vi que Patroni no escribió en el registro durante bastante tiempo: 54 segundos. Y si comparamos dos marcas de tiempo, no hubo mensajes durante unos 54 segundos.
Y durante este tiempo hubo un autofile. Patroni hizo un gran trabajo aquí nuevamente. Nuestro antiguo maestro no estaba disponible, algo le pasó. Y comenzó la elección de un nuevo amo. Todo salió bien aquí. Nuestro pgsql01 se ha convertido en el nuevo líder.
Tenemos una réplica que se ha convertido en un maestro. Y hay una segunda respuesta. Y hubo problemas con la segunda réplica. Ella trató de reconfigurar. Según tengo entendido, intentó cambiar recovery.conf, reiniciar Postgres y conectarse al nuevo maestro. Ella escribe mensajes cada 10 segundos que está intentando, pero no lo está logrando.
Y durante estos intentos, llega una señal de apagado inmediato al antiguo maestro. El maestro se reinicia. Y también la recuperación se detiene porque el antiguo maestro se reinicia. Es decir, la réplica no puede conectarse a él porque está en modo de apagado.
En algún momento, funcionó, pero la replicación no comenzó.
Mi única suposición es que había una dirección maestra antigua en recovery.conf. Y cuando apareció un nuevo maestro, la segunda réplica todavía intentó conectarse al antiguo maestro.
Cuando Patroni se inició en la segunda réplica, el nodo se inició pero no pudo replicarse. Y se formó un retraso de replicación, que se parecía a esto. Es decir, los tres nodos estaban en su lugar, pero el segundo nodo estaba rezagado.
Al mismo tiempo, si observa los registros que se escribieron, podría ver que la replicación no pudo iniciarse porque los registros de transacciones eran diferentes. Y esos registros de transacciones que ofrece el maestro, que se especifican en recovery.conf, simplemente no se ajustan a nuestro nodo actual.
Y aquí cometí un error. Tuve que venir y ver qué había en recovery.conf para probar mi hipótesis de que nos estábamos conectando al maestro equivocado. Pero luego solo estaba lidiando con esto y no se me ocurrió, o vi que la réplica se estaba quedando atrás y habría que rellenarla, es decir, de alguna manera trabajé sin cuidado. Este era mi porro.
Después de 30 minutos, el administrador ya llegó, es decir, reinicié Patroni en la réplica. Ya le puse fin, pensé que habría que rellenarlo. Y pensé: reiniciaré Patroni, tal vez resulte algo bueno. Comenzó la recuperación. Y la base incluso se abrió, estaba lista para aceptar conexiones.
La replicación ha comenzado. Pero un minuto después, se cayó con un error de que los registros de transacciones no son adecuados para ella.
Pensé en reiniciar de nuevo. Reinicié Patroni nuevamente, y no reinicié Postgres, pero reinicié Patroni con la esperanza de que mágicamente iniciaría la base de datos.
La replicación comenzó de nuevo, pero las marcas en el registro de transacciones eran diferentes, no eran las mismas que en el intento de inicio anterior. La replicación se detuvo de nuevo. Y el mensaje ya era un poco diferente. Y no fue muy informativo para mí.
Y luego se me ocurre: ¿qué pasa si reinicio Postgres, en este momento hago un punto de control en el maestro actual para mover el punto en el registro de transacciones un poco hacia adelante para que la recuperación comience desde otro momento? Además, todavía teníamos existencias de WAL.
Reinicié Patroni, hice un par de puntos de control en el maestro, un par de puntos de reinicio en la réplica cuando se abrió. Y ayudó. Pensé durante mucho tiempo por qué ayudó y cómo funcionó. Y empezó la réplica. Y la replicación ya no estaba rota.
Tal problema para mí es uno de los más misteriosos, sobre el cual todavía me pregunto qué sucedió realmente allí.
¿Cuáles son las implicaciones aquí? Patroni puede funcionar según lo previsto y sin errores. Pero al mismo tiempo, esto no es una garantía del 100% de que todo esté bien con nosotros. La réplica puede iniciarse, pero puede estar en un estado semifuncional y la aplicación no puede funcionar con dicha réplica porque habrá datos antiguos.
Y después del archivador, siempre debe verificar que todo esté en orden con el clúster, es decir, existe la cantidad requerida de réplicas, no hay retraso de replicación.
Y a medida que analicemos estos temas, haré recomendaciones. Traté de combinarlos en dos diapositivas. Probablemente, todas las historias podrían combinarse en dos diapositivas y solo contarse.
Cuando usa Patroni, debe tener monitoreo. Siempre debe saber cuándo se produjo una transferencia automática de archivos porque, si no sabe que tuvo una transferencia automática de archivos, no tiene control sobre el clúster. Y eso es malo.
Después de cada archivador, siempre tenemos que verificar manualmente el clúster. Necesitamos asegurarnos de que siempre tengamos un número actualizado de réplicas, que no haya retrasos en la replicación, que no haya errores en los registros relacionados con la replicación de transmisión, con Patroni, con el sistema DCS.
La automatización puede funcionar con éxito, Patroni es una muy buena herramienta. Puede funcionar, pero esto no llevará el clúster al estado deseado. Y si no nos enteramos, estaremos en problemas.
Y Patroni no es una panacea. Todavía necesitamos entender cómo funciona Postgres, cómo funciona la replicación y cómo funciona Patroni con Postgres, y cómo se proporciona la comunicación entre los nodos. Esto es necesario para poder solucionar problemas con las manos.
¿Cómo enfoco el tema del diagnóstico? Dio la casualidad de que trabajamos con diferentes clientes y ninguno tiene una pila ELK, y tenemos que ordenar los registros abriendo 6 consolas y 2 pestañas. En una pestaña, estos son los registros de Patroni para cada nodo, en la otra pestaña, estos son los registros de Consul o Postgres si es necesario. Es muy difícil diagnosticar esto.
¿Qué enfoques he desarrollado? Primero, siempre miro cuando ha llegado el archivador. Y para mí esto es un parteaguas. Observo lo que sucedió antes del archivador, durante el archivador y después del archivador. El fileover tiene dos marcas: esta es la hora de inicio y finalización.
A continuación, busco en los registros los eventos anteriores al archivador, que precedieron al archivador, es decir, busco las razones por las que sucedió el archivador.
Y esto da una imagen de entender lo que pasó y lo que se puede hacer en el futuro para que tales circunstancias no ocurran (y como resultado, no hay un archivador).
¿Y hacia dónde solemos mirar? Yo miro:
- Primero, a los registros de Patroni.
- A continuación, miro los registros de Postgres o los registros de DCS, según lo que se encuentre en los registros de Patroni.
- Y los registros del sistema a veces también dan una idea de lo que causó el archivador.
¿Qué siento por Patroni? Tengo muy buena relación con Patroni. En mi opinión, esto es lo mejor que hay hoy. Conozco muchos otros productos. Estos son Stolon, Repmgr, Pg_auto_failover, PAF. 4 herramientas. Los probé todos. Patroni es mi favorito.
Si me preguntan: "¿Recomiendo Patroni?". Diré que sí, porque me gusta Patroni. Y creo que aprendí a cocinarlo.
Si está interesado en ver qué otros problemas hay con Patroni además de los problemas que he mencionado, siempre puede consultar la página en GitHub. Hay muchas historias diferentes y se discuten muchos temas interesantes allí. Y como resultado, se introdujeron y resolvieron algunos errores, es decir, esta es una lectura interesante.
Hay algunas historias interesantes sobre personas que se pegan un tiro en el pie. Muy informativo. Usted lee y comprende que no es necesario hacerlo. Me marqué a mí mismo.
Y me gustaría dar las gracias a Zalando por desarrollar este proyecto, concretamente a Alexander Kukushkin y Alexey Klyukin. Aleksey Klyukin es uno de los coautores, ya no trabaja en Zalando, pero son dos personas que empezaron a trabajar con este producto.
Y creo que Patroni es algo muy bueno. Estoy feliz de que ella exista, es interesante con ella. Y muchas gracias a todos los colaboradores que escriben parches para Patroni. Espero que Patroni se vuelva más maduro, fresco y eficiente con la edad. Ya es funcional, pero espero que mejore aún más. Por lo tanto, si planea usar Patroni, no tenga miedo. Esta es una buena solución, se puede implementar y utilizar.
Eso es todo. Si tiene alguna pregunta, pregunte.
preguntas
¡Gracias por el informe! Si después de un archivador aún necesita mirar con mucho cuidado, ¿por qué necesitamos un archivador automático?
Porque son cosas nuevas. Solo llevamos un año con ella. Mejor estar seguro. Queremos entrar y ver que todo realmente salió como debería. Este es el nivel de desconfianza de los adultos: es mejor verificar dos veces y ver.
Por ejemplo, fuimos por la mañana y miramos, ¿no?
No por la mañana, por lo general nos enteramos del autoarchivo casi de inmediato. Recibimos notificaciones, vemos que se ha producido un autoarchivo. Casi inmediatamente vamos y miramos. Pero todos estos controles deben llevarse al nivel de monitoreo. Si accede a Patroni a través de la API REST, hay un historial. Por historial, puede ver las marcas de tiempo cuando ocurrió el archivador. En base a esto, se puede hacer un seguimiento. Puedes ver el historial, cuántos eventos hubo. Si tenemos más eventos, entonces se ha producido un archivo automático. Puedes ir y ver. O nuestra automatización de monitoreo comprobó que tenemos todas las réplicas en su lugar, no hay retraso y todo está bien.
Gracias!
¡Muchas gracias por la gran historia! Si movimos el clúster DCS a algún lugar lejos del clúster de Postgres, ¿entonces este clúster también debe recibir servicio periódicamente? ¿Cuáles son las mejores prácticas que algunas piezas del clúster DCS necesitan apagarse, hacer algo con ellas, etc.? ¿Cómo sobrevive toda esta estructura? ¿Y cómo haces estas cosas?
Para una empresa fue necesario hacer una matriz de problemas, qué pasa si uno de los componentes o varios componentes fallan. De acuerdo con esta matriz, revisamos secuencialmente todos los componentes y construimos escenarios en caso de falla de estos componentes. En consecuencia, para cada escenario de falla, puede tener un plan de acción para la recuperación. Y en el caso de DCS, viene como parte de la infraestructura estándar. Y el administrador lo administra, y ya confiamos en los administradores que lo administran y su capacidad para solucionarlo en caso de accidentes. Si no hay DCS en absoluto, lo implementamos, pero al mismo tiempo no lo monitoreamos particularmente, porque no somos responsables de la infraestructura, pero damos recomendaciones sobre cómo y qué monitorear.
Es decir, ¿entendí correctamente que necesito deshabilitar Patroni, deshabilitar el archivador, deshabilitar todo antes de hacer algo con los hosts?
Depende de cuántos nodos tengamos en el clúster DCS. Si hay muchos nodos y si deshabilitamos solo uno de los nodos (la réplica), entonces el clúster mantiene un quórum. Y Patroni sigue operativo. Y no se dispara nada. Si tenemos algunas operaciones complejas que afectan a más nodos, cuya ausencia puede arruinar el quórum, entonces, sí, podría tener sentido poner Patroni en pausa. Tiene un comando correspondiente: pausa patronictl, reanudación patronictl. Simplemente hacemos una pausa y el autofiler no funciona en ese momento. Hacemos mantenimiento en el clúster DCS, luego quitamos la pausa y continuamos en vivo.
¡Muchas gracias!
¡Muchas gracias por tu informe! ¿Cómo se siente el equipo de producto acerca de la pérdida de datos?
A los equipos de productos no les importa, y los líderes de equipo están preocupados.
¿Qué garantías hay?
Las garantías son muy difíciles. Alexander Kukushkin tiene un informe "Cómo calcular RPO y RTO", es decir, el tiempo de recuperación y la cantidad de datos que podemos perder. Creo que necesitamos encontrar estas diapositivas y estudiarlas. Por lo que recuerdo, hay pasos específicos sobre cómo calcular estas cosas. Cuántas transacciones podemos perder, cuántos datos podemos perder. Como opción podemos utilizar la replicación síncrona a nivel de Patroni, pero esto es un arma de doble filo: o tenemos fiabilidad de los datos, o perdemos velocidad. Existe la replicación síncrona, pero tampoco garantiza una protección del 100 % contra la pérdida de datos.
Alexey, gracias por el gran informe! ¿Alguna experiencia con el uso de Patroni para la protección de nivel cero? Es decir, ¿junto con el modo de espera síncrono? Esta es la primera pregunta. Y la segunda pregunta. Ha utilizado diferentes soluciones. Usamos Repmgr, pero sin autofiler, y ahora planeamos incluir autofiler. Y consideramos Patroni como una solución alternativa. ¿Qué puedes decir como ventajas en comparación con Repmgr?
La primera pregunta se refería a las réplicas síncronas. Aquí nadie usa la replicación síncrona, porque todos están asustados (Varios clientes ya la están usando, en principio, no notaron problemas de rendimiento - nota del orador). Pero hemos desarrollado una regla para nosotros mismos de que debe haber al menos tres nodos en un clúster de replicación síncrona, porque si tenemos dos nodos y si el maestro o la réplica fallan, Patroni cambia este nodo al modo independiente para que la aplicación continúe. trabajar. En este caso, existe el riesgo de pérdida de datos.
Con respecto a la segunda pregunta, hemos usado Repmgr y todavía lo hacemos con algunos clientes por razones históricas. ¿Qué se puede decir? Patroni viene con un filtro automático listo para usar, Repmgr viene con un filtro automático como una función adicional que debe habilitarse. Necesitamos ejecutar el demonio Repmgr en cada nodo y luego podemos configurar el autofiler.
Repmgr comprueba si los nodos de Postgres están activos. Los procesos de Repmgr verifican la existencia de los demás, este no es un enfoque muy eficiente. puede haber casos complejos de aislamiento de red en los que un gran clúster de Repmgr puede dividirse en varios más pequeños y seguir funcionando. Hace mucho tiempo que no sigo a Repmgr, tal vez se solucionó... o tal vez no. Pero la eliminación de información sobre el estado del clúster en DCS, como hace Stolon, Patroni, es la opción más viable.
Alexey, tengo una pregunta, tal vez más tonta. En uno de los primeros ejemplos, movió DCS de la máquina local a un host remoto. Entendemos que la red es una cosa que tiene sus propias características, vive por sí sola. ¿Y qué sucede si, por alguna razón, el clúster DCS deja de estar disponible? No diré las razones, puede haber muchas: desde las manos torcidas de los usuarios de redes hasta problemas reales.
No lo dije en voz alta, pero el clúster DCS también debe ser de conmutación por error, es decir, es un número impar de nodos, para que se cumpla el quórum. ¿Qué sucede si el clúster DCS deja de estar disponible o no se puede cumplir con el quórum, es decir, algún tipo de división de la red o falla del nodo? En este caso, el clúster Patroni entra en modo de solo lectura. El clúster de Patroni no puede determinar el estado del clúster y qué hacer. No puede ponerse en contacto con el DCS y almacenar allí el nuevo estado del clúster, por lo que todo el clúster pasa a modo de solo lectura. Y espera la intervención manual del operador o la recuperación del DCS.
A grandes rasgos, ¿DCS se convierte para nosotros en un servicio tan importante como la propia base?
Sí Sí. En tantas empresas modernas, Service Discovery es una parte integral de la infraestructura. Se está implementando incluso antes de que hubiera una base de datos en la infraestructura. En términos relativos, se lanzó la infraestructura, se implementó en el CD y de inmediato tenemos Service Discovery. Si es Consul, entonces se puede construir DNS en él. Si esto es Etcd, entonces puede haber una parte del clúster de Kubernetes, en la que se implementará todo lo demás. Me parece que Service Discovery ya es una parte integral de las infraestructuras modernas. Y lo piensan mucho antes que en las bases de datos.
Gracias!
Fuente: habr.com