Garantizar la confiabilidad y la calidad de la configuración de alta disponibilidad de Patroni es fundamental para mantener las operaciones continuas de la base de datos de AlloyDB Omni y minimizar el tiempo de inactividad. En esta página, se proporciona una guía completa para probar tu clúster de Patroni, que abarca varios casos de falla, la coherencia de la replicación y los mecanismos de conmutación por error.
Prueba tu configuración de Patroni
Conéctate a cualquiera de tus instancias de Patroni (
alloydb-patroni1,alloydb-patroni2oalloydb-patroni3) y navega a la carpeta de Patroni de AlloyDB Omni.cd /alloydb/
Inspecciona los registros de Patroni.
sudo journalctl -u patroni
Las últimas entradas deben reflejar información sobre el nodo de Patroni. Deberías ver un resultado similar al siguiente.
May 16 15:10:29 alloydb-patroni1 patroni[1234]: 2024-06-12 15:10:29,020 INFO: no action. I am (patroni1), the leader with the lock May 16 15:10:39 alloydb-patroni1 patroni[1234]: 2024-06-12 15:10:39,010 INFO: no action. I am (patroni1), the leader with the lock May 16 15:10:49 alloydb-patroni1 patroni[1234]: 2024-06-12 15:10:49,007 INFO: no action. I am (patroni1), the leader with the lock
Conéctate a cualquier instancia que ejecute Linux que tenga conectividad de red a tu instancia principal de Patroni,
alloydb-patroni1, y obtén información sobre la instancia. Es posible que debas instalar la herramientajqejecutandosudo dnf install jq.curl -s http://alloydb-patroni1:8008/patroni | jq .
Deberías ver algo similar a lo siguiente.
{ "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" } }
Llamar extremo de API de HTTP de Patroni en un nodo de Patroni expone varios detalles sobre el estado y la configuración de esa instancia de PostgreSQL en particular administrada por Patroni, incluida la información del estado del clúster, la línea de tiempo, la información de WAL y las verificaciones de estado que indican si los nodos y el clúster están en funcionamiento correctamente.
Prueba tu configuración de HAProxy
En una máquina con un navegador y conectividad de red a tu nodo de HAProxy, ve a la siguiente dirección:
http://haproxy:7000. Como alternativa, puedes usar la dirección IP externa de la instancia de HAProxy en lugar de su nombre de host.Deberías ver algo similar a la siguiente captura de pantalla.
Figura 1. Página de estado de HAProxy que muestra el estado y la latencia de los nodos de Patroni
En el panel de HAProxy, puedes ver el estado y la latencia de tu nodo principal de Patroni,
patroni1, y de las dos réplicas,patroni2ypatroni3.Puedes realizar consultas para verificar las estadísticas de replicación en tu clúster. Desde un cliente como pgAdmin, conéctate a tu 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ías ver algo similar al siguiente diagrama, que muestra que
patroni2ypatroni3transmiten desdepatroni1.
Figura 2. Resultado de pg_stat_replication que muestra el estado de replicación de los nodos de Patroni
Prueba la conmutación por error automática
En esta sección, en tu clúster de tres nodos, simulamos una interrupción en el nodo principal deteniendo el contenedor de Patroni en ejecución adjunto. Puedes detener el servicio de Patroni en la instancia principal para simular una interrupción o aplicar algunas reglas de firewall para detener la comunicación con ese nodo.
En la instancia principal de Patroni, navega a la carpeta de Patroni de AlloyDB Omni.
cd /alloydb/
Detén el contenedor.
sudo systemctl stop patroni
Deberías ver un resultado similar al siguiente. Esto debería validar que se detuvieron el contenedor y la red.
patroni.service - Runner for Patroni Loaded: loaded (/etc/systemd/system/patroni.service; enabled; vendor preset: disabled) Active: inactive (dead) since ...
Actualiza el panel de HAProxy y observa cómo se realiza la conmutación por error.
Figura 3. Panel de HAProxy que muestra la conmutación por error del nodo principal al nodo de reserva
La instancia
patroni3se convirtió en la nueva instancia principal, ypatroni2es la única réplica restante. La instancia principal anterior,patroni1, está inactiva y las verificaciones de estado fallan.Patroni realiza y administra la conmutación por error a través de una combinación de supervisión, consenso y orquestación automatizada. En cuanto el nodo principal no renueva su concesión dentro de un tiempo de espera especificado o si informa una falla, los otros 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 para promoverla como la nueva instancia principal. Una vez que se selecciona una réplica candidata, Patroni promueve este nodo a la instancia principal aplicando los cambios necesarios, como actualizar la configuración de PostgreSQL y reproducir los registros de WAL pendientes. Luego, el nuevo nodo principal actualiza el sistema de consenso con su estado y las otras réplicas se vuelven a configurar para seguir la nueva instancia principal, lo que incluye cambiar su fuente de replicación y, posiblemente, ponerse al día con las transacciones nuevas. HAProxy detecta la nueva instancia principal y redirecciona las conexiones del cliente en consecuencia, lo que garantiza una interrupción mínima.
Desde un cliente como pgAdmin, conéctate a tu servidor de base de datos a través de HAProxy y verifica las estadísticas de replicación en 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ías ver algo similar al siguiente diagrama, que muestra que solo
patroni2transmite ahora.
Figura 4. Resultado 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 sobrevivir a una interrupción más. Si detienes el nodo principal actual,
patroni3, se producirá otra conmutación por error.
Figura 5. Panel de HAProxy que muestra la conmutación por error del nodo principal,
patroni3, al nodo de reserva,patroni2
Consideraciones sobre la reversión
La reversión es el proceso de restablecimiento del nodo fuente anterior luego de que se produce una conmutación por error. Por lo general, no se recomienda la reversión automática en un clúster de base de datos de alta disponibilidad debido a varias inquietudes críticas, como la recuperación incompleta, el riesgo de situaciones de cerebro dividido y el retraso de la replicación.
En tu clúster de Patroni, si activas los dos nodos con los que simulaste una interrupción, se volverán a unir al clúster como réplicas de reserva.
Figura 6. Panel de HAProxy que muestra el restablecimiento de patroni1 y patroni3 como nodos de reserva
Ahora, patroni1 y patroni3 se replican desde la instancia principal actual patroni2.
Figura 7. Resultado de pg_stat_replication que muestra el estado de replicación de los nodos de Patroni después de la reversión
Si deseas revertir manualmente a tu instancia principal inicial, puedes hacerlo con la interfaz de línea de comandos de patronictl. Si eliges la reversión manual, puedes garantizar un proceso de recuperación más confiable, coherente y completamente verificado, lo que mantiene la integridad y la disponibilidad de tus sistemas de base de datos.