En esta página, se documenta la versión 15.7.1 de AlloyDB Omni con la opción de implementación de Kubernetes. Elige otra opción de implementación.

Esta página se ha traducido con Cloud Translation API.

Cambio y conmutación por error con la replicación pglogical

Selecciona una versión de la documentación:

En esta página se explica cómo hacer un cambio y una conmutación por error con la replicación pglogical.

Antes de empezar

Una vez que se haya configurado la replicación pglogical y haya una solución viable de alta disponibilidad (HA) y recuperación ante desastres (DR), y teniendo en cuenta que la replicación lógica no proporciona true ni una replicación completa de todos los objetos de la base de datos, debes probar esta configuración antes de empezar a usarla.

Para obtener más información sobre la extensión pglogical, consulta el artículo Acerca de pglogical.

Para obtener información sobre la replicación de datos mediante pglogical, consulta los artículos Replicar datos entre AlloyDB para PostgreSQL y AlloyDB Omni y Replicar datos entre AlloyDB Omni y otras bases de datos.

Cambio con replicación pglogical

El cambio es un proceso controlado que se usa para cambiar los roles entre las bases de datos del proveedor y del suscriptor. Cuando realizas un cambio, se invierten los roles de las dos bases de datos, la de proveedor y la de suscriptor. El proveedor pasa a ser el suscriptor y el suscriptor pasa a ser el proveedor.

Esta función de cambio es importante para las actualizaciones del sistema operativo, las actualizaciones de PostgreSQL o las pruebas de conmutación por error.

Para conseguirlo en las configuraciones de replicación unidireccional, debes configurar una nueva relación entre proveedor y suscriptor, y eliminar la antigua.

Crear la nueva configuración de proveedor o suscriptor

Impide que la aplicación escriba en el sistema del proveedor para evitar más cambios en la base de datos y comprueba el retraso de la replicación para asegurarte de que todas las transacciones se repiten en el nodo suscriptor:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Cuando todos los campos de latencia muestren cero, la replicación estará actualizada y la base de datos estará lista para un cambio.

El resultado debería ser similar al siguiente:

-[ RECORD 1 ]----+------------------------------
application_name | test_sub_1
state            | streaming
sync_state       | async
client_addr      | 10.45.0.80
client_hostname  | 
sent_lag         | 0
receiving_lag    | 0
replay_lag       | 0
total_lag        | 0
reply_delay      | 00:00:26.203433

Convierte la base de datos de suscriptores en una base de datos de proveedores:
1. Detener la suscripción del suscriptor.
2. Añade el conjunto de réplicas, si es necesario.
3. Añade las tablas necesarias al conjunto de réplicas.
4. Crea una nueva suscripción de suscriptor en la nueva base de datos de suscriptores.
5. Redirige las aplicaciones al nuevo proveedor.
Detén la suscripción en la base de datos de suscriptores actual, que se convertirá en el nuevo proveedor:
```
SELECT pglogical.alter_subscription_disable(SUBSCRIPTION_NAME);
```
(Opcional) Crea un conjunto de réplicas que coincida con la definición de la base de datos del proveedor original. No es necesario si usas los conjuntos de réplicas predeterminados:
```
SELECT pglogical.create_replication_set(REPLICATION_SET_NAME);
```
Añade tablas a ese conjunto de réplicas:
```
SELECT pglogical.replication_set_add_table(REPLICATION_SET_NAME, TABLE_NAME);
```
Haz los cambios siguientes:
- REPLICATION_SET_NAME: el nombre del conjunto de réplicas.
- TABLE_NAME: nombre de la tabla de un propietario de un esquema. Por ejemplo, ARRAY['public'].`

En la nueva base de datos de suscriptores, que antes era la base de datos del proveedor, crea la nueva suscripción con la opción synchronize_data definida como false para evitar la carga inicial de la tabla:

SELECT pglogical.create_subscription (
           subscription_name := '<subscription name>',
           replication_sets := array['default'],
           synchronize_data := false,
           provider_dsn := 'host=<hostname or IP> port=5432 
           dbname=<db name> user=pglogical_replication password=<password>');

Comprueba si la suscripción funciona en el nodo del proveedor:

SELECT application_name,
    state,
    sync_state,
    client_addr,
    client_hostname,
    pg_wal_lsn_diff(pg_current_wal_lsn(),sent_lsn) AS sent_lag,
    pg_wal_lsn_diff(sent_lsn,flush_lsn) AS receiving_lag,
    pg_wal_lsn_diff(flush_lsn,replay_lsn) AS replay_lag,
    pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) AS total_lag,
    now()-reply_time AS reply_delay
FROM pg_stat_replication
ORDER BY client_hostname;

Si la replicación funciona, cambia las cadenas de conexión de la aplicación para usar la nueva base de datos del proveedor y reinicia los niveles de la aplicación.

Si cambia los datos del nodo del proveedor antiguo después de detener el suscriptor, estos cambios no se replicarán y se perderán datos. Si hay cambios en los datos no replicados en la base de datos del proveedor original o si el proveedor original, que es el nuevo suscriptor, no se encuentra en un estado coherente con la nueva base de datos del proveedor, que es el antiguo suscriptor, debe crear la nueva base de datos del suscriptor por completo.

Quitar el proveedor y la suscripción antiguos

Si quieres que la replicación sea unidireccional, debes eliminar la configuración anterior del proveedor o del suscriptor.

Elimina la suscripción antigua en el nuevo proveedor:

SELECT pglogical.drop_subscription('<subscription name>')

Elimine el conjunto de réplicas en el nuevo suscriptor o elimine todas las tablas del conjunto de réplicas:

SELECT pglogical.drop_replication_set('<replication set name>')

SELECT pglogical.replication_set_remove_table('<replication set name>','<table name>')

Replicación bidireccional

Para cambiar sin que haya tiempo de inactividad o para asegurarte de que no se pierdan datos debido a cambios de datos no planificados, debes usar la réplica bidireccional. Cuando implementes la replicación bidireccional, ten en cuenta la resolución de conflictos, a menos que se hayan implementado controles estrictos para evitar el acceso de escritura a ambos nodos al mismo tiempo.

Puede configurar la resolución de conflictos con los siguientes ajustes de pglogical.conflict_resolution:

error: el suscriptor se detiene cuando se detecta un conflicto.
apply_remote: siempre aplica los cambios entrantes independientemente de los datos de la base de datos de suscriptores. Esta es la configuración predeterminada.
keep_local: siempre ignora los datos entrantes que estén en conflicto y descarta el cambio en conflicto.
last_update_wins: la versión de los datos con la marca de tiempo de la última confirmación es la que se confirma.
first_update_wins: la versión de los datos con la marca de tiempo más antigua es la que se confirma.

Para configurar la replicación bidireccional, configura el proveedor y el suscriptor de forma que la replicación se produzca en ambos sentidos. El suscriptor original también se convierte en proveedor con el mismo conjunto de réplicas que el proveedor original. Consulta Crear una tabla y añadirla al conjunto de réplicas predeterminado en la base de datos de proveedor de AlloyDB para PostgreSQL para crear un conjunto de réplicas que duplique el conjunto de réplicas original en la base de datos de proveedor inicial.

En el proveedor original, debes añadir un nuevo suscriptor. Consulta Crear un nodo y una suscripción en la base de datos de suscriptor de AlloyDB Omni para crear un suscriptor nuevo. Asegúrate de que el parámetro synchronize_data del comando pglogical.create_subscription esté definido como false. De esta forma, se evita la copia inicial de los datos de la tabla.

Conmutación por error con replicación pglogical

La conmutación por error se produce cuando la base de datos del proveedor deja de estar disponible por cualquier motivo y debes cambiar la aplicación para que use la base de datos del suscriptor.

Para evitar que se apliquen datos duplicados por error a la base de datos de suscriptor tras la conmutación por error, debes inhabilitar la suscripción. De esta forma, se asegura de que los cambios de un proveedor restaurado no se apliquen por error cuando el proveedor vuelva a estar disponible.

Detener al suscriptor test_sub_1:

SELECT pglogical.alter_subscription_disable(`test_sub_1`);

Comprueba que el estado sea disabled:

SELECT pglogical.show_subscription_status('test_sub_1');