Asegurar la fiabilidad y la calidad de tu configuración de alta disponibilidad de Patroni es fundamental para mantener las operaciones de la base de datos de forma continua y minimizar el tiempo de inactividad. En esta página se ofrece una guía completa para probar tu clúster de Patroni, que abarca varios casos de fallo, la coherencia de la replicación y los mecanismos de conmutación por error.
Probar la configuración de Patroni
Conéctate a cualquiera de tus instancias de Patroni (
alloydb-patroni1,alloydb-patroni2oalloydb-patroni3) y ve a la carpeta de Patroni de AlloyDB Omni.cd /alloydb/
Inspecciona los registros de Patroni.
docker compose logs alloydbomni-patroni
Las últimas entradas deben reflejar información sobre el nodo de Patroni. Debería ver algo similar a lo siguiente.
alloydbomni-patroni | 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock alloydbomni-patroni | 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lockConéctate a cualquier instancia que ejecute Linux y que tenga conectividad de red con tu instancia principal de Patroni,
alloydb-patroni1, y obtén información sobre la instancia. Puede que tengas que instalar la herramientajqejecutandosudo apt-get install jq -y.curl -s http://alloydb-patroni1:8008/patroni | jq .
Debería ver algo similar a lo que se muestra a continuación.
{ "state": "running", "postmaster_start_time": "2024-05-16 14:12:30.031673+00:00", "role": "master", "server_version": 150005, "xlog": { "location": 83886408 }, "timeline": 1, "replication": [ { "usename": "alloydbreplica", "application_name": "patroni2", "client_addr": "10.172.0.40", "state": "streaming", "sync_state": "async", "sync_priority": 0 }, { "usename": "alloydbreplica", "application_name": "patroni3", "client_addr": "10.172.0.41", "state": "streaming", "sync_state": "async", "sync_priority": 0 } ], "dcs_last_seen": 1715870011, "database_system_identifier": "7369600155531440151", "patroni": { "version": "3.3.0", "scope": "my-patroni-cluster", "name": "patroni1" } }
Al llamar al endpoint de la API HTTP de Patroni en un nodo de Patroni, se muestran varios detalles sobre el estado y la configuración de esa instancia de PostgreSQL concreta gestionada por Patroni, incluida información sobre el estado del clúster, la cronología, la información de WAL y las comprobaciones de estado que indican si los nodos y el clúster están activos y funcionan correctamente.
Probar la configuración de HAProxy
En un ordenador con un navegador y conectividad de red a tu nodo HAProxy, ve a la siguiente dirección:
http://haproxy:7000. También puedes usar la dirección IP externa de la instancia de HAProxy en lugar de su nombre de host.Debería ver algo similar a la siguiente captura de pantalla.
Imagen 1. Página de estado de HAProxy que muestra el estado y la latencia de los nodos de Patroni.
En el panel de control de HAProxy, puede ver el estado y la latencia de su nodo principal de Patroni,
patroni1, y de las dos réplicas,patroni2ypatroni3.Puedes hacer consultas para comprobar las estadísticas de replicación de tu clúster. Desde un cliente como pgAdmin, conéctate al servidor de base de datos principal a través de HAProxy y ejecuta la siguiente consulta.
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;Debería ver algo similar al siguiente diagrama, que muestra que
patroni2ypatroni3están transmitiendo desdepatroni1.
Imagen 2. Salida de pg_stat_replication que muestra el estado de replicación de los nodos de Patroni.
Probar la conmutación por error automática
En esta sección, en tu clúster de tres nodos, simularemos una interrupción en el nodo principal deteniendo el contenedor Patroni adjunto en ejecución. Puedes detener el servicio Patroni en el nodo principal para simular una interrupción o aplicar algunas reglas de cortafuegos para detener la comunicación con ese nodo.
En la instancia principal de Patroni, ve a la carpeta AlloyDB Omni Patroni.
cd /alloydb/
Detén el contenedor.
docker compose down
Debería ver algo similar al siguiente resultado. Debería validar que el contenedor y la red se han detenido.
[+] Running 2/2 ✔ Container alloydb-patroni Removed ✔ Network alloydbomni-patroni_default RemovedActualiza el panel de control de HAProxy y observa cómo se produce la conmutación por error.
Imagen 3. Panel de control de HAProxy que muestra la conmutación por error del nodo principal al nodo de reserva.
La instancia
patroni3se ha convertido en la nueva principal ypatroni2es la única réplica que queda. El anterior principal,patroni1, no funciona y las comprobaciones de estado fallan.Patroni realiza y gestiona la conmutación por error mediante una combinación de monitorización, consenso y orquestación automatizada. En cuanto el nodo principal no renueva su concesión en el plazo de espera especificado o informa de un error, los demás nodos del clúster reconocen esta condición a través del sistema de consenso. Los nodos restantes se coordinan para seleccionar la réplica más adecuada y convertirla en la nueva principal. Una vez que se selecciona una réplica candidata, Patroni asciende este nodo a principal aplicando los cambios necesarios, como actualizar la configuración de PostgreSQL y reproducir los registros WAL pendientes. A continuación, el nuevo nodo principal actualiza el sistema de consenso con su estado y las otras réplicas se vuelven a configurar para seguir al nuevo nodo principal, lo que incluye cambiar su fuente de replicación y, posiblemente, ponerse al día con las nuevas transacciones. HAProxy detecta la nueva instancia principal y redirige las conexiones de los clientes en consecuencia, lo que garantiza que las interrupciones sean mínimas.
Desde un cliente como pgAdmin, conéctate a tu servidor de base de datos a través de HAProxy y comprueba las estadísticas de replicación de tu clúster después de la conmutación por error.
SELECT pid, usename, application_name, client_addr, state, sync_state FROM pg_stat_replication;Debería ver algo similar al siguiente diagrama, que muestra que solo
patroni2se está emitiendo en este momento.
Imagen 4. Salida de pg_stat_replication que muestra el estado de replicación de los nodos de Patroni después de la conmutación por error.
Tu clúster de tres nodos puede resistir otra interrupción. Si detienes el nodo principal actual,
patroni3, se producirá otra conmutación por error.
Imagen 5. Panel de control de HAProxy que muestra la conmutación por error del nodo principal,
patroni3, al nodo de reserva,patroni2.
Consideraciones sobre las alternativas
La restauración es el proceso para restablecer el nodo de origen anterior después de que se haya producido una conmutación por error. Por lo general, no se recomienda la conmutación por error automática en un clúster de base de datos de alta disponibilidad debido a varios problemas críticos, como la recuperación incompleta, el riesgo de escenarios de cerebro dividido y el retraso de la replicación.
En tu clúster de Patroni, si activas los dos nodos con los que has simulado una interrupción, se volverán a unir al clúster como réplicas de espera.
Imagen 6. Panel de control de HAProxy que muestra la restauración de patroni1 y patroni3 como nodos de reserva.
Ahora, patroni1 y patroni3 se replican desde la principal actual patroni2.
Ilustración 7. Salida de pg_stat_replication que muestra el estado de replicación de los nodos de Patroni después de la conmutación por error.
Si quieres volver manualmente a tu instancia principal inicial, puedes hacerlo mediante la interfaz de línea de comandos patronictl. Si optas por la conmutación por error manual, puedes asegurarte de que el proceso de recuperación sea más fiable, coherente y esté verificado a fondo, lo que te permitirá mantener la integridad y la disponibilidad de tus sistemas de bases de datos.