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

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

Para obtener información general sobre la replicación, consulta Acerca de 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 a nivel de SQL, en términos de INSERTs, UPDATEs y DELETEs. Esta independencia de la capa de almacenamiento proporciona una gran flexibilidad y permite una amplia gama de funciones a los consumidores de los flujos de cambios.

La replicación lógica es la función principal basada 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 tengan la misma versión, la replicación lógica permite replicar entre 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 con la replicación lógica nativa de PostgreSQL, que se añadió 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 de cambios (CDC) flexibles. Por ejemplo, la extensión wal2json permite transmitir todos los cambios de una base de datos a un consumidor, con el formato JSON. Cloud SQL admite el decodificador pgoutput integrado, el módulo de contribución test_decoding y wal2json. Actualmente, Cloud SQL admite las dos variantes wal2json de salida JSON: format-version 1, que codifica toda la transacción como un único objeto JSON, y format-version 2, que genera un objeto JSON por comando. Estos complementos permiten la replicación en bases de datos que no son de PostgreSQL.

Configurar la instancia de PostgreSQL

PostgreSQL admite la decodificación lógica escribiendo información adicional en su registro de escritura anticipada (WAL).

En Cloud SQL, puedes habilitar esta función configurando la cloudsql.logical_decoding marca en on. Este ajuste es diferente del que se usa en PostgreSQL estándar. Si cambias una instancia de PostgreSQL externa, puedes habilitar esta función asignando el valor logical al parámetro de configuración wal_level.

Si tienes previsto usar la extensión pglogical, debes añadirla a shared_preload_libraries. Como Cloud SQL no permite modificar directamente esta marca, pglogical se habilita asignando el valor cloudsql.enable_pglogical a on. (En una máquina virtual, sudo apt-get install postgresql-13-pglogical) y reinicia la base de datos.

Si usas pglogical para replicar entre dos instancias de PostgreSQL, solo tienes que habilitar la decodificación lógica en la instancia principal, no en la instancia de réplica (a menos que esa instancia sea la principal de 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 Información sobre la replicación en Cloud SQL.

Habilitar la conectividad de red

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

Obtener la dirección IP de salida de una instancia de réplica

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 de salida.

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

Permitir conexiones

Si la instancia principal es una instancia de Cloud SQL, puedes permitir el acceso desde la dirección IP de salida de la réplica añadiéndola como red autorizada.

Habilitar las conexiones de replicación en PostgreSQL 9.6 y versiones anteriores

Si tu instancia principal no se ejecuta en Cloud SQL y usa 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. Añade la siguiente línea a ese archivo. Usa all all solo para las pruebas iniciales. Para aumentar la seguridad, limita los usuarios y las direcciones IP a los que sean necesarios, como en este ejemplo:

host replication all all md5

Para obtener más información, consulta el artículo El archivo pg_hba.conf.

Crear un usuario de replicación

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

Ejemplos

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

También puedes definir este atributo en un usuario que ya tengas:

ALTER USER existing_user WITH REPLICATION;

Recursos de PostgreSQL

Cuando se usa la decodificación lógica, un proceso en segundo plano de la instancia principal de PostgreSQL transforma los cambios de WAL en cambios lógicos mediante el complemento de decodificación seleccionado y los transmite a un consumidor (que incluso podría ser una instancia que no sea de PostgreSQL). Este proceso en segundo plano se denomina "remitente WAL". El número de remitentes WAL simultáneos que pueden estar activos en una instancia de PostgreSQL está limitado por la marca max_wal_senders. El valor predeterminado de esta marca es 10 y su límite aumenta de forma lineal con la memoria de tu instancia de Cloud SQL, lo que permite 8 remitentes de WAL por GB de memoria.

Para asegurarse de que los segmentos WAL no se descarten antes de enviarse a todos los consumidores, PostgreSQL usa slots de replicación lógica para registrar qué datos se han enviado a qué consumidor (y slots de replicación para réplicas de lectura). El número de ranuras de replicación que puedes crear para una instancia de PostgreSQL está limitado por la marca max_replication_slots. El valor predeterminado de esta marca es 10 y su límite aumenta 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 el número máximo de ranuras de replicación de la instancia.

Por lo general, hay una ranura de replicación y un remitente de WAL por consumidor, por lo que estas marcas deben tener valores aproximadamente iguales. Sin embargo, PostgreSQL recomienda proporcionar un pequeño búfer para max_wal_senders que se encargue de gestionar las conexiones cuando se cierran de forma inesperada y se establecen nuevas conexiones. La replicación física, que usan las réplicas de lectura de Cloud SQL, también utiliza un espacio de replicación y un remitente de WAL, por lo que debes tenerlos en cuenta al calcular cuántos recursos de cada tipo necesitas.

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

Si este valor es demasiado bajo y la replicación falla con el mensaje de error worker registration failed en tus registros, es probable que tengas que aumentar el valor de max_worker_processes.

Ten en cuenta que los remitentes de WAL no se consideran procesos de trabajo. Los procesos de trabajo generados para la ejecución de consultas paralelas sí se tienen en cuenta, por lo que, si el valor de max_worker_processes es demasiado bajo, puede que el rendimiento sea deficiente 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 de cloudsqlsuperuser, como el usuario administrador predeterminado postgres. Esta función solo está disponible en PostgreSQL 10 y versiones posteriores.

Para calcular el uso total de disco de WAL, haz lo siguiente:

postgres=> select * from pg_ls_waldir();

(2 filas)

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

(1 fila)

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

Consulta Configurar réplicas externas para ver un ejemplo completo con pglogical y la decodificación lógica.

Configurar 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 tanto en la instancia principal como en la réplica. Para ello, asigna el valor cloudsql.enable_pglogical=on a una instancia de Cloud SQL o añade pglogical a shared_preload_libraries en una instancia externa. Ten en cuenta que, para cambiar estas marcas, es necesario reiniciar tanto la instancia principal como la réplica.

Si tienes problemas con estos pasos, consulta Solucionar problemas de pglogical.

Crear un usuario con privilegios de replicación

Cuando se usa pglogical, se necesita un usuario con privilegios de replicación y el rol cloudsqlsuperuser en las instancias principal y de réplica. El usuario debe ejecutar los comandos que se describen a continuación.

Instalar la extensión pglogical

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

CREATE EXTENSION pglogical;

Crear un nodo pglogical en cada instancia

Un nodo de pglogical representa una instancia física de PostgreSQL y almacena los detalles de conexión de esa instancia. Tanto la instancia principal como la réplica deben registrarse 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 los datos que quieras replicar

La extensión pglogical permite replicar solo un subconjunto de tablas en un destino. Por ejemplo, vamos a crear una tabla ficticia en la instancia principal y a rellenarla con algunos datos para hacer pruebas:

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

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

Añadir la tabla a un conjunto de réplicas

Para admitir la replicación de diferentes conjuntos de datos en diferentes destinos, pglogical tiene el concepto de conjunto de replicación. Podemos añadir nuestra tabla de prueba al conjunto de réplicas predeterminado.

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

Crear la suscripción pglogical

Crea la suscripción pglogical en la instancia de destino proporcionando los detalles de conexión a la instancia principal.

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 es "replicando", significa que la configuración se ha completado correctamente. Consulte la tabla replica_test para comprobar que los datos se han replicado. Inserta y modifica registros en la instancia principal y comprueba que aparecen en la instancia de réplica.

En la principal, consulta la tabla pg_replication_slots para ver el espacio de replicación creado por la suscripción.

Limpieza

Una vez que la prueba se haya completado correctamente, elimina la suscripción de la réplica con pglogical.drop_subscription('test_sub'). Verifica que la ranura de replicación también se haya eliminado en el primario. De lo contrario, los segmentos WAL seguirán acumulándose en la instancia de réplica.

Para obtener más información sobre los conjuntos de réplicas, la réplica parcial de datos, la réplica de DDL, otras configuraciones avanzadas y las limitaciones, consulta la documentación de pglogical.

Uso de recursos

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

En el estado estable, se ejecuta un proceso de "supervisor" cuando está habilitado, un proceso de "gestor" por cada base de datos PostgreSQL que tenga instalada la extensión (por ejemplo, podría haber D) y un proceso de "aplicación" por cada suscripción pglogical en la instancia de réplica (por ejemplo, podría haber S). Sin embargo, la extensión puede generar procesos de trabajo adicionales al realizar una sincronización inicial y, de hecho, genera procesos de "gestor" para cada base de datos de la instancia, pero si la base de datos no tiene instalada la extensión, se cierra inmediatamente.

Por lo tanto, asigna algunos procesos de trabajador más de los necesarios en el estado estable. PostgreSQL usa procesos de trabajo para otros fines, como el procesamiento de consultas en paralelo. Si max_worker_processes es demasiado bajo, la replicación puede fallar sin mostrar ningún mensaje o PostgreSQL puede no ser capaz de realizar el procesamiento de consultas en paralelo.

En resumen, te recomendamos que uses estos ajustes:

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)

Solucionar problemas de pglogical

No se puede crear la extensión pglogical

Al intentar instalar la extensión pglogical, puede que aparezca el siguiente error:

ERROR:  pglogical is not in shared_preload_libraries

Cuando instales pglogical en una instancia de Cloud SQL, asegúrate de haber definido cloudsql.enable_pglogical=on. Si usas una instancia externa, añádela directamente a la marca shared_preload_libraries, por ejemplo, shared_preload_libraries=pg_stat_statements,pglogical. Para aplicar estas modificaciones, es necesario reiniciar la instancia principal.

No se puede crear una suscripción pglogical

Al crear una suscripción, pglogical primero comprueba que puede usar los detalles de la conexión para conectarse a la instancia. Primero intenta crear una conexión normal y, si no lo consigue, 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 de que los detalles de la conexión que has proporcionado sean correctos. Se proporcionan detalles adicionales sobre por qué PostgreSQL no ha podido establecer una conexión.

Después de crear una conexión normal, pglogical intenta establecer una conexión de replicación especial. En PostgreSQL 9.6 y versiones anteriores, este tipo de conexión podrí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 se produce al conectarse a una instancia externa que no gestiona Cloud SQL.

También puede fallar la conexión del modo de replicación 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 no funciona

Es posible que una suscripción de pglogical no se replique. Para solucionar este problema, primero asegúrese de que se esté ejecutando un proceso en segundo plano en la instancia réplica. Consulta pg_stat_activity para verificar que se está ejecutando un proceso pglogical apply. Si no es así, consulta los registros del nodo de destino. Si ves el mensaje worker registration failed,, puedes aumentar el ajuste max_worker_processes.

A continuación, asegúrate de que se haya creado un espacio de replicación en la instancia principal. En la instancia de réplica, la fila de pglogical.subscription contiene el nombre del espacio que intenta crear la suscripción. En la instancia principal, puede consultar pg_replication_slots para verificar que el espacio se ha creado correctamente.

Si no se ha creado ninguna ranura de replicación, consulta los registros de la instancia principal.

Un error de ERROR: logical decoding requires wal_level >= logical implica que la marca wal_level no se ha definido como logical. Para resolver este problema, define cloudsql.logical_decoding=on en la instancia principal si se trata de una instancia de Cloud SQL.

Si la instancia es externa, también puedes definir wal_level=logical.

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

Configurar 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 estar habilitada en la instancia principal. Para ello, define 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, es necesario reiniciar la instancia principal.

Para asegurarte de que tus instancias están configuradas correctamente (para la conectividad de red, etc.), consulta las secciones de Configurar tu instancia de PostgreSQL. En esta página se describen los pasos para realizar una prueba de concepto. Si tienes algún problema al seguir los pasos de esas secciones, consulta 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 los datos que quieras replicar

La replicación lógica nativa de PostgreSQL admite bases de datos completas o solo tablas concretas. Por ejemplo, crearemos una tabla ficticia en la instancia principal y la rellenaremos con datos para hacer pruebas.

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

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

Crear una publicación en la instancia principal

La replicación lógica nativa de PostgreSQL se ocupa de los editores y los suscriptores. Crea una publicación de los datos en native_test:

CREATE PUBLICATION pub FOR TABLE native_test;

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

Aquí tienes 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;

Para crear la suscripción en la instancia de réplica, se necesita el rol cloudsqlsuperuser. Después de crear la suscripción, consulta la tabla native_test para verificar que los datos han aparecido en la instancia de réplica.

En la principal, puedes consultar la tabla pg_replication_slots para ver el espacio de réplica creado por la suscripción.

Limpieza

Una vez que la prueba se haya completado correctamente, elimina la suscripción de la réplica con DROP SUBSCRIPTION sub;. Verifica que la ranura de réplica también se haya eliminado en el principal. De lo contrario, los segmentos WAL seguirán acumulándose en la instancia principal.

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

No se puede acceder a la columna subconninfo de la tabla de sistema pg_subscription.

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

Recibir cambios de WAL decodificados para la captura de datos de cambios (CDC)

Como alternativa para usar 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 pg_recvlogical para crear un espacio de replicación y transmitir los cambios registrados por ese espacio. El formato de los cambios viene determinado por el complemento de decodificación que elijas. Puedes usar:

• wal2json para transmitir cambios con formato JSON, o

• test_decoding, para transmitir cambios con un formato de texto básico

Crear ranura de replicación

Para crear un espacio 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>

Cambios en la emisión

En un terminal de Cloud Shell, ejecuta lo siguiente:

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

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 de decodificador wal2json, se mostrará un resultado similar al siguiente en el primer 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 de decodificador test_decoding, se mostrará un resultado similar al siguiente en el primer 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

(Los IDs de transacción pueden ser diferentes).

Limpieza

Cuando hayas terminado las pruebas, elimina la ranura de replicación que has creado ejecutando el siguiente comando:

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 lógica y decodificación de Cloud SQL para PostgreSQL.

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

• Cuando restauras una instancia que tiene habilitada la opción cloudsql.logical_decoding o cloudsql.enable_pglogical y que actúa como editor para la replicación lógica, primero debes inhabilitar la replicación en todas las instancias de destino. De lo contrario, se producirá un error al restaurar la instancia, pero actualmente no se pueden ver los detalles del error.

• Cuando restauras una copia de seguridad de una instancia que tenía habilitada la cloudsql.logical_decoding o la cloudsql.enable_pglogical (en el momento de la copia de seguridad) y la restauras en una instancia nueva, el estado de la réplica no se restaura en la instancia nueva. Después, debes volver a configurar la replicación manualmente.

• En una instancia de Cloud SQL con una o varias 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.

  • En las versiones 15 y anteriores de Cloud SQL para PostgreSQL, las instancias de réplica de lectura de Cloud SQL no pueden actuar como editores de la replicación lógica porque PostgreSQL no admite la decodificación lógica en las réplicas de lectura de esas versiones anteriores. Sin embargo, para asegurarse de que las instancias puedan sustituir a la instancia principal en caso de que se produzca una promoción, las marcas lógicas siguen habilitadas en las instancias de réplica de lectura de estas versiones anteriores.

  • A partir de la versión 16 de Cloud SQL para PostgreSQL, las instancias de réplica de lectura de Cloud SQL pueden actuar como editores de replicación lógica si la instancia principal tiene definidos los indicadores lógicos. El suscriptor lógico puede ser una instancia de Cloud SQL o una instancia externa. Sin embargo, la eliminación de filas y las operaciones de vacío en la principal pueden eliminar tuplas que la decodificación lógica de la réplica de lectura aún necesite. En esos casos, la ranura de replicación lógica de la réplica de lectura se invalida para evitar incoherencias.

  • Si habilitas cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal, se habilitarán las marcas en todas las réplicas de lectura, lo que provocará que la instancia principal y las réplicas de lectura se reinicien en una sucesión cercana. Para evitar esta situación y controlar cuándo se reinicia cada instancia, puedes (1) definir las marcas en cada réplica de lectura por turno y, a continuación, (2) definir las marcas en la instancia principal.

  • Si se inhabilita cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal, no se inhabilitarán las marcas en todas las réplicas de lectura. Para inhabilitar las marcas en todas las instancias, debe realizar los pasos inversos a los descritos anteriormente: (1) inhabilite las marcas en la instancia principal y, a continuación, (2) inhabilite las marcas en cada réplica de lectura por turno.