Configura la replicación lógica y la decodificación

MySQL   |  PostgreSQL   |  SQL Server

Puedes usar las funciones de replicación y decodificación lógicas en Cloud SQL para PostgreSQL. Estas funciones habilitan flujos de trabajo de replicación lógica y flujos de trabajo de captura de datos modificados (CDC).

Importante: Antes de usar estas funciones, consulta las Notas y limitaciones.

Para obtener información general sobre la replicación, consulta Sobre la replicación en Cloud SQL.

Introducción

Cuando PostgreSQL realiza la replicación lógica, los cambios que se transmiten a las réplicas se extraen de los registros WAL mediante la decodificación lógica. Los cambios decodificados son independientes del formato de almacenamiento físico subyacente. Los cambios solo reflejan los cambios en los datos del nivel de SQL, en términos de INSERT, UPDATE y DELETE. Esta independencia de la capa de almacenamiento proporciona una gran flexibilidad y permite una gran variedad de funcionalidades por parte de los consumidores de las transmisiones de cambios.

La replicación lógica es la función insignia que se compila en la decodificación lógica.

A diferencia de la función de replicación física de PostgreSQL, que requiere que las bases de datos de origen y de destino sean la misma versión, la replicación lógica permite la replicación en todas las versiones principales de PostgreSQL. La replicación lógica en Cloud SQL es compatible con la extensión pglogical, disponible en todas las versiones de PostgreSQL, y la replicación lógica nativa de PostgreSQL, agregada en PostgreSQL 10.

El formato en el que se transmiten los cambios se puede configurar con diferentes complementos. Esto permite arquitecturas de captura de datos modificados (CDC) flexibles. Por ejemplo, la extensión wal2json permite transmitir todos los cambios en una base de datos a un consumidor, con formato JSON. Cloud SQL admite el decodificador pgoutput integrado, el módulo de contribución test_decoding y wal2json. En la actualidad, Cloud SQL admite ambas variantes wal2json de salida de JSON: format-version 1 que codifica toda la transacción como un objeto JSON único yformat-version 2 que produce un objeto JSON por comando. Estos complementos permiten la replicación en bases de datos que no son de PostgreSQL.

Configura tu instancia de PostgreSQL

Nota: Para cambiar las marcas analizadas en esta sección, es necesario reiniciar la instancia. Para minimizar el tiempo de inactividad, lee toda esta sección antes de decidir tu configuración de marcas.

PostgreSQL admite la decodificación lógica mediante la escritura de información adicional en su registro de escritura por adelantado (WAL).

Para habilitar esta función en Cloud SQL, configura la marca cloudsql.logical_decoding como on. Esta configuración es diferente de la que se usa en PostgreSQL estándar. Si cambias una instancia externa de PostgreSQL, debes habilitar esta función mediante la configuración del parámetro de configuración wal_level en logical.

Nota: Para habilitar o inhabilitar marcas en Cloud SQL, usa las instrucciones estándar.

Si planeas usar la extensión pglogical, pglogical debe agregarse a shared_preload_libraries. Dado que Cloud SQL no permite la modificación directa de esta marca, pglogical está habilitado si configuras cloudsql.enable_pglogical en on. (En una VM, sudo apt-get install postgresql-13-pglogical) y reinicia la base de datos.

Si usas pglogical para replicar entre dos instancias de PostgreSQL, la decodificación lógica solo debe estar habilitada en la instancia principal y no en la instancia de réplica (a menos que esa instancia sea una principal para otras réplicas). Sin embargo, la extensión pglogical debe estar habilitada en ambas instancias. Para ver ejemplos de cómo se usan los términos “principal” y “réplica” y sus significados, consulta Sobre la replicación en Cloud SQL.

Habilita la conectividad de red

Asegúrate de que tus instancias principales acepten conexiones de la instancia de réplica.

Principal	Réplica	Configuración
Cloud SQL (IP pública)	Cloud SQL (IP pública)	Agrega la dirección IP saliente de la réplica a las redes autorizadas de la instancia principal.
Cloud SQL (IP privada)	Cloud SQL (IP privada)	Si ambas instancias se encuentran en el mismo proyecto de Google Cloud, debes agregar el rango de IP asignado de la red de VPC de la réplica a la red autorizada que aloja las instancias. Para encontrar el rango de IP asignado en la consola de Google Cloud, sigue estos pasos: Navega a la página Redes de VPC. Selecciona la red de VPC que usas. Selecciona la pestaña Conexión privada a servicios. Selecciona la pestaña Rangos de IP asignados. Nota: No necesitas agregar nada a las redes autorizadas de ninguna de las instancias si la subred de la red de VPC está en el rango 10.0.0.0/8, 172.16.0.0/12 o 192.168.0.0/16, ya que estos bloques de subred tienen LCA en cada instancia de forma predeterminada.
Externo	Cloud SQL	Puedes usar Database Migration Service.
Cloud SQL	Externo	Consulta Configura réplicas externas para obtener más información.

Obtén la dirección IP saliente de una instancia de replicación

Si la instancia de réplica es una instancia de Cloud SQL y tiene una dirección IP pública, sigue estos pasos para obtener su dirección IP saliente.

Nota: Omite este procedimiento si configuras la replicación solo con una red privada. Esto se debe a que no es necesaria una dirección IP saliente en esta situación.

Console

1. Abre la página Instancias de Cloud SQL.

2. Junto a la dirección IP pública de la réplica de Cloud SQL, desplázate sobre la sugerencia de herramientas Más información y recupera la dirección IP saliente. Ten en cuenta que la dirección IP saliente no es la dirección IP que se muestra en la lista principal de la réplica en la consola de Cloud.

Precaución: Las instancias que usan una alta disponibilidad (HA) no tienen una dirección IP saliente coherente y no se pueden usar como suscriptores.

Si la instancia de réplica no es una instancia de Cloud SQL, consulta la documentación relevante.

Si deseas obtener más información para obtener la dirección IP pública de la instancia, consulta Obtén la dirección IP saliente de la réplica de Cloud SQL.

gcloud

Puedes usar el siguiente comando de gcloud:

gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"

Permite conexiones

Si la instancia principal es una instancia de Cloud SQL, puedes permitir el acceso desde la dirección IP saliente de la réplica si la agregas como una red autorizada.

Precaución: Cuando restableces una instancia de suscriptor a partir de una copia de seguridad, la dirección IP saliente de la instancia del suscriptor puede cambiar. Para reiniciar la replicación después de restablecer la instancia de suscriptor, debes agregar la IP saliente nueva como una red autorizada.

Habilita conexiones de replicación para PostgreSQL 9.6 y versiones anteriores

Si tu instancia principal no se ejecuta en Cloud SQL y ejecuta PostgreSQL 9.6 o una versión anterior, debes asegurarte de que el archivo pg_hba.conf de la instancia esté configurado para aceptar conexiones de replicación. Agrega la línea siguiente a ese archivo y usa all all solo para las pruebas iniciales. Para obtener más seguridad, limita los usuarios y las direcciones IP solo a las necesarias, como en este ejemplo:

host replication all all md5

Para obtener más información, consulta El archivo pg_hba.conf.

Crea un usuario de replicación

Para usar funciones de decodificación lógica, debes crear un usuario de PostgreSQL con el atributo REPLICATION.

Nota: En PostgreSQL estándar, debes proporcionar permisos de SUPERUSER. Cuando usas la extensión pglogical, el usuario debe tener la función cloudsqlsuperuser, para luego ejecutar el comando CREATE EXTENSION; en Cloud SQL, un usuario debe tener la función cloudsqlsuperuser a fin de ejecutar ese comando.

Ejemplos

CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';

También puedes configurar este atributo en un usuario existente:

ALTER USER existing_user WITH REPLICATION;

Nota: El usuario existente debe tener el privilegio CREATE en cada base de datos que intenta replicar.

Recursos de PostgreSQL

Cuando se usa la decodificación lógica, un proceso en segundo plano en la instancia principal de PostgreSQL transforma los cambios de WAL en cambios lógicos con el complemento de decodificación seleccionado y los retransmite a un consumidor (incluso puede ser una instancia que no es de PostgreSQL). Este proceso en segundo plano se llama remitente de WAL. La cantidad de remitentes de WAL simultáneos que pueden estar activos en una instancia de PostgreSQL está limitada por la marca max_wal_forwardings. La marca predeterminada es 10, y su límite crece de forma lineal con la memoria de la instancia de Cloud SQL, lo que permite 8 remitentes de WAL por GB de memoria.

Para garantizar que los segmentos de WAL no se descarten antes de enviarse a todos los consumidores, PostgreSQL usa ranuras de replicación lógica a fin de realizar un seguimiento de los datos que se enviaron a cada consumidor (y ranuras de replicación físicas para réplicas de lectura). La cantidad de ranuras de replicación que puedes crear para una instancia de PostgreSQL está limitada por la marca max_replication_slots. El valor predeterminado de esta marca es 10 y su límite crece con la memoria de tu instancia de Cloud SQL, lo que permite entre 2 y 8 ranuras de replicación por GB de memoria.

En la siguiente tabla, se muestra la relación entre la memoria máxima de una instancia de Cloud SQL y las ranuras de replicación máximas para la instancia.

Memoria máxima (GB)	Cantidad máxima de ranuras de replicación
4	10
16	32
32	128
64	256
128	512
256	1024
512	2048
512+	4096

Importante: Una ranura que no se usa de forma activa para realizar un seguimiento de los datos hace que PostgreSQL se conserve en los segmentos WAL de forma indefinida, lo que hace que el espacio en disco crezca de forma indefinida. La mayoría de las herramientas compiladas en la decodificación lógica crean y descartan ranuras de replicación de forma automática. Las ranuras de replicación sin usar se pueden detectar si consultas la vista del sistema pg_replication_slots y filtras en la columna active. Las ranuras sin usar se pueden descartar para quitar los segmentos de WAL mediante el comando pg_drop_replication_slot.

Por lo general, hay una ranura de replicación y un remitente de WAL por consumidor, por lo que estas marcas deben configurarse en valores aproximadamente iguales. Sin embargo, PostgreSQL recomienda proporcionar un pequeño búfer para max_wal_senders a fin de controlar cuándo se cierran las conexiones de forma inesperada y se realizan conexiones nuevas. La replicación física, como la usan las réplicas de lectura de Cloud SQL, también usa una ranura de replicación y un remitente de WAL, por lo que debes contarlos cuando calcules cuántos de cada recurso necesitas.

La replicación lógica nativa de PostgreSQL y pglogical requieren procesos en segundo plano adicionales para ejecutarse, tanto en la instancia principal como en la réplica. La marca max_worker_processes limita la cantidad de procesos que se pueden ejecutar. El valor predeterminado es ocho y su límite crece de forma lineal con la memoria de tu instancia de Cloud SQL, lo que permite dos procesos adicionales por GB de memoria. La cantidad exacta de procesos de trabajador que se usan con estos enfoques se explica en sus respectivas secciones.

Si esta marca es demasiado baja y la replicación falla con el mensaje de error worker registration failed en tus registros, es probable que debas aumentar la configuración de max_worker_processes.

Ten en cuenta que los remitentes de WAL no se cuentan como procesos de trabajadores. Los trabajadores generados para la ejecución de consultas paralelas sí cuentan, por lo que si el valor de max_worker_processes se establece demasiado bajo, es posible que experimentes un rendimiento bajo porque PostgreSQL no puede aprovechar la ejecución de consultas paralelas.

Con la función pg_ls_waldir (), puedes determinar el uso del disco de WAL. Esta función está restringida a los usuarios cloudsqlsuperuser, como el usuario administrador predeterminado postgres. Esta función solo está disponible en la versión 10 de PostgreSQL y versiones posteriores.

Para calcular el uso total de uso del disco de WAL, sigue estos pasos:

postgres=> select * from pg_ls_waldir();

nombre	tamaño	modificación
00000001000000000000000A	16777216	2021-08-11 15:16:49+00
000000010000000000000009	16777216	2021-08-12 06:23:24+00

(2 filas)

postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();

Uso total de uso del disco de WAL
32 MB

(1 fila)

Configura la replicación lógica con una réplica externa

Consulta Configura réplicas externas para obtener un ejemplo completo mediante la decodificación de pglogical y lógica.

Configura la replicación lógica con pglogical

Para configurar la replicación lógica con pglogical, la decodificación lógica debe estar habilitada en la instancia principal. Configura cloudsql.logical_decoding=on en la instancia de Cloud SQL o wal_level=logical en una instancia externa. Además, pglogical debe estar habilitado en la instancia principal y en la de réplica. configura cloudsql.enable_pglogical=on en una instancia de Cloud SQL o agrega pglogical a shared_preload_libraries en una instancia externa. Ten en cuenta que, para cambiar estas marcas, se requiere un reinicio de las instancias principal y de réplica.

Si tienes problemas con estos pasos, consulta Solución de problemas de pglogical.

Crea un usuario con privilegios de replicación

Necesitas un usuario con privilegios de replicación y la función cloudsqlsuperuser en las instancias principal y de réplica cuando usas pglogical. Ese usuario debe ejecutar cualquier comando que se describa a continuación.

Instala la extensión pglogical

Debes instalar la extensión pglogical en la instancia principal y la de réplica. En la instancia principal, el usuario de replicación (es decir, el usuario que se conecta a la base de datos) debe instalarlo.

CREATE EXTENSION pglogical;

Crea un nodo pglogical en cada instancia

Un nodo pglogical representa una instancia física de PostgreSQL y almacena los detalles de conexión para esa instancia. La instancia principal y la de réplica se deben registrar como nodos:

source-instance$ SELECT pglogical.create_node(
    node_name := 'primary',
    dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

dest-instance$ SELECT pglogical.create_node(
    node_name := 'replica',
    dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

Crea una tabla con datos para replicar

La extensión pglogical permite replicar solo un subconjunto de tablas en un destino. Como ejemplo, crearemos una tabla ficticia en la instancia principal y la propagaremos con algunos datos para probar:

CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');

La tabla también se debe crear en la instancia de réplica.

Agrega la tabla a un conjunto de replicación

Para admitir la replicación de diferentes conjuntos de datos en diferentes destinos, pglogical tiene el concepto de un conjunto de replicación. Podemos agregar nuestra tabla de prueba al conjunto de replicación predeterminado.

SELECT pglogical.replication_set_add_table('default', 'replica_test', true);

Crea la suscripción a pglogical

Proporciona los detalles de conexión a la instancia principal para crear la suscripción pglogical en la instancia de destino.

SELECT pglogical.create_subscription(
    subscription_name := 'test_sub',
    provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);

SELECT * FROM pglogical.show_subscription_status('test_sub');

Si el estado aparece como “replicación”, significa que la configuración se realizó correctamente. Consulta la tabla replica_test para asegurarte de que los datos se hayan replicado. Inserta y modifica registros en la instancia principal y verifica que aparezcan en la instancia de réplica.

En la instancia principal, consulta la tabla pg_replication_slots para ver la ranura de replicación que creó la suscripción.

Limpieza

Una vez que la prueba se haya completado de forma correcta, descarta la suscripción en la réplica con pglogical.drop_subscription('test_sub'). Verifica que la ranura de replicación también se descarte en la instancia principal. De lo contrario, los segmentos de WAL continuarán acumulando en la instancia de réplica.

Para obtener más información sobre los conjuntos de replicación, la replicación de datos parcial, la replicación de DDL, otra configuración avanzada y las limitaciones, consulta la documentación de pglogical.

Uso de recursos

La extensión pglogical ejecuta varios procesos en segundo plano que se consideran para el límite max_worker_processes.

En el estado estable, ejecuta un proceso de “supervisor” cuando está habilitado, un proceso de “administrador” por base de datos de PostgreSQL que instaló la extensión (por ejemplo, podría haber D de estos) y un proceso de "aplicación" por suscripción pglogical package en la instancia de réplica (por ejemplo, podría haber S de estas). Sin embargo, la extensión puede generar procesos de trabajador adicionales cuando se realiza una sincronización inicial y, en realidad, genera procesos de “administrador” para todas las bases de datos en la instancia, pero si la base de datos no para tener la extensión instalada, se cierra de inmediato.

Por lo tanto, asigna más procesos de trabajadores de los necesarios en el estado estable. PostgreSQL usa los procesos de trabajadores para otros fines, como el procesamiento de consultas paralelas. Si max_worker_processes es demasiado bajo, la replicación puede fallar de forma silenciosa, o es posible que PostgreSQL no pueda realizar el procesamiento de consultas paralelas.

En resumen, se recomienda esta configuración:

max_worker_processes
  >= 1 + D + 8 (on the source instance)
  >= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)

Soluciona problemas de pglogical

No se puede crear la extensión pglogical

Cuando intentes instalar la extensión pglogical, es posible que veas el siguiente error:

ERROR:  pglogical is not in shared_preload_libraries

Cuando instales pglogical en una instancia de Cloud SQL, asegúrate de haber configurado cloudsql.enable_pglogical=on. Si usas una instancia externa, agrégala directamente a la marca shared_preload_libraries, por ejemplo, shared_preload_libraries=pg_stat_statements,pglogical. Estas modificaciones requieren que se reinicie la instancia principal.

No se puede crear una suscripción a pglogical

Cuando creas una suscripción, pglogical primero verifica que puede usar los detalles de conexión para conectarse a la instancia. Primero, intenta crear una conexión regular y, si esto falla, se produce un error: ERROR: could not connect to the postgresql server.

Si se produce este error, asegúrate de que la instancia principal esté configurada para permitir conexiones desde la instancia de réplica y asegúrate de que los detalles de la conexión que proporcionaste sean correctos. Se proporcionan detalles adicionales sobre por qué PostgreSQL no pudo establecer una conexión.

Después de crear una conexión regular, pglogical intenta hacer una conexión de replicación especial. En PostgreSQL 9.6 y versiones anteriores, este tipo de conexión podía tener una configuración de autenticación diferente. Debes actualizar el archivo pg_hba.conf en la instancia de origen si ves este error: ERROR: could not connect to the postgresql server in replication mode.

El archivo pg_hba.conf que usa Cloud SQL ya tiene los cambios necesarios; este error solo ocurre cuando se conecta a una instancia externa que no administra Cloud SQL.

Como alternativa, la conexión del modo de replicación puede fallar si la instancia de origen no permite suficientes remitentes de WAL. Si ves FATAL: number of requested standby connections exceeds max_wal_senders, aumenta max_wal_senders en la instancia principal.

la suscripción a pglogical está baja

Una suscripción pglogical puede no replicarse. Para solucionar este problema, primero asegúrate de que se esté ejecutando un proceso en segundo plano en la instancia de réplica. Consulta pg_stat_activity para verificar que esté en ejecución un proceso pglogical apply. De lo contrario, verifica los registros en el nodo de destino. Si ves el mensaje worker registration failed,, puedes aumentar la configuración de max_worker_processes.

Luego, asegúrate de que se haya creado una ranura de replicación en la instancia principal. En la instancia de réplica, la fila en pglogical.subscription contiene el nombre de la ranura que la suscripción intenta crear y, en la instancia principal, puedes consultar pg_replication_slots para verificar que la ranura se creó correctamente.

Si no se creó una ranura de replicación, verifica los registros en la instancia principal.

Un error de ERROR: logical decoding requires wal_level >= logical implica que la marca wal_level no se estableció en logical. Para solucionar este problema, configura cloudsql.logical_decoding=on en la instancia principal si es una instancia de Cloud SQL.

De forma alternativa, si la instancia es externa, configura wal_level=logical.

De lo contrario, es posible que veas ERROR: all replication slots are in use, junto con el HINT: Free one or increase max_replication_slots útil.

Configura la replicación lógica nativa de PostgreSQL

Desde PostgreSQL 10, PostgreSQL admite la replicación lógica integrada nativa. Para configurar la replicación lógica nativa, la decodificación lógica debe habilitarse en la instancia principal mediante la configuración de cloudsql.logical_decoding=on en una instancia de Cloud SQL o wal_level=logical en una instancia externa. Ten en cuenta que, para modificar estas marcas, debes reiniciar la instancia principal.

Revisa las secciones en Configura tu instancia de PostgreSQL para asegurarte de que las instancias estén configuradas de forma correcta (con conectividad de red, etc.). En esta página, se proporcionan pasos para obtener una prueba de concepto. Si tienes algún problema mientras sigues los pasos de esas secciones, consulta la página sobre cómo solucionar problemas de pglogical. Para obtener más información, consulta Replicación lógica en la documentación de PostgreSQL.

Crea una tabla con datos para replicar

La replicación lógica de PostgreSQL nativa admite una base de datos completa o solo tablas individuales. Como ejemplo, crearemos una tabla ficticia en la instancia principal y la propagaremos con algunos datos para probar.

CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');

La tabla también se debe crear en la instancia de réplica.

Crea una publicación en la instancia principal

Acuerdos de replicación lógica nativos de PostgreSQL con publicadores y suscriptores. Crea una publicación de los datos en native_test:

CREATE PUBLICATION pub FOR TABLE native_test;

Crea una suscripción en la instancia de réplica

El siguiente es un ejemplo de cómo crear una suscripción en la instancia de réplica:

CREATE SUBSCRIPTION sub
    CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
    PUBLICATION pub;

La creación de la suscripción en la instancia de réplica requiere la función cloudsqlsuperuser. Después de crear la suscripción, consulta la tabla native_test para verificar que los datos hayan aparecido en la instancia de réplica.

En el principal, puedes consultar la tabla pg_replication_slots para ver la ranura de replicación que creó la suscripción.

Limpieza

Una vez que la prueba sea exitosa, descarta la suscripción en la réplica con DROP SUBSCRIPTION sub;. Verifica que la ranura de replicación también se descarte en la instancia principal. De lo contrario, los segmentos de WAL continuarán acumulando en la instancia principal.

Limitaciones de la replicación lógica nativa de PostgreSQL

El acceso a la columna subconninfo de la tabla del sistema pg_subscriptions no está disponible.

La ejecución de pg_dump no puede volcar la información sobre las suscripciones porque verifica si el usuario que se conecta tiene permisos de superusuario.

Recibe cambios decodificados de WAL para capturar datos de cambios (CDC)

Como caso de uso alternativo para los CDC, la decodificación lógica puede transmitir cambios desde una instancia de PostgreSQL. La herramienta estándar que se usa para esto es pg_recvlogical.

Puedes usar la herramienta de pg_recvlogical para crear una ranura de replicación y transmitir los cambios que realiza el seguimiento de esa ranura. El formato de los cambios se determina según el complemento de decodificación que elijas. Puedes usar:

• wal2json, para transmitir cambios con formato JSON, o

• test_decoding para transmitir cambios formateados con formato de texto barebones

Crea ranuras de replicación

Para crear una ranura de replicación, ejecuta el siguiente comando:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --create-slot \
  -P <decoder_plugin>

Transmitir los cambios

En una terminal de Cloud Shell, ejecuta lo siguiente:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --start \
  -f -

Cuando estés en otra terminal de Cloud Shell, conéctate a tu base de datos y ejecuta los siguientes comandos:

CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;

Si usas el complemento del decodificador wal2json, se mostrará un resultado similar al siguiente en la primera terminal de Cloud Shell:

{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}

Si usas el complemento del decodificador test_decoding, se mostrará un resultado similar al siguiente en la primera terminal de Cloud Shell:

BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464

(Es posible que sus ID de transacción sean diferentes).

Limpieza

Después de completar las pruebas, ejecuta el siguiente comando para descartar la ranura de replicación que creaste:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --drop-slot

Notas y limitaciones

Las notas y limitaciones de esta sección se aplican a las funciones de replicación y decodificación lógicas de Cloud SQL para PostgreSQL.

• La extensión pglogical no funciona en instancias que tienen habilitada la aplicación forzosa de conectores. Esta limitación no se aplica a las instancias que tienen configurado el acceso a servicios privados.

• Cuando restableces una instancia que tiene habilitados cloudsql.logical_decoding o cloudsql.enable_pglogical, y actúa como publicador para la replicación lógica, primero debes inhabilitar la replicación en todas las instancias de destino. De lo contrario, el restablecimiento a la instancia fallará con un error, pero actualmente los detalles del error no son visibles.

• Cuando restableces una copia de seguridad de una instancia que tenía cloudsql.logical_decoding o cloudsql.enable_pglogical habilitados (en el momento de la copia de seguridad) y la restableces en una instancia nueva, el estado de replicación no se restablece a la instancia nueva. Después debes configurar la replicación de forma manual.

• En una instancia de Cloud SQL con una o más réplicas de lectura de Cloud SQL (mediante la replicación física), si habilitas cloudsql.logical_decoding o cloudsql.enable_pglogical, esas marcas también se habilitarán en la réplica de lectura.

  • Las instancias de réplica de lectura de Cloud SQL no pueden actuar como publicadores para la replicación lógica porque PostgreSQL no admite la decodificación lógica en las réplicas de lectura. Sin embargo, las marcas están habilitadas en la instancia de réplica de lectura para garantizar que pueda servir como reemplazo de la instancia principal cuando se ascienda, si esto ocurre.

  • Habilitar cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal hace que las marcas se habiliten en todas las réplicas de lectura, lo que hace que las réplicas principales y de lectura se reinicien consecutivamente. Para evitar esta situación y controlar cuándo se reinicia cada instancia, puedes (1) configurar las marcas en cada réplica de lectura y, solo entonces, (2) configurar las marcas en la instancia principal.

  • Inhabilitar cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal no hace que las marcas se inhabiliten en todas las réplicas de lectura. Para inhabilitar las marcas en las instancias, debes realizar lo inverso a los pasos descritos antes: (1) inhabilitar las marcas en la instancia principal y, luego, (2) inhabilitar las marcas en cada réplica de lectura de una en una.