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

Organízate con las colecciones Guarda y clasifica el contenido según tus preferencias.

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

Para obtener información general sobre la replicación, consulte Acerca de la replicación en Cloud SQL .

Introducción

Cuando PostgreSQL realiza una replicación lógica, los cambios transmitidos a las réplicas se extraen de los registros WAL mediante decodificación lógica. Los cambios decodificados son independientes del formato de almacenamiento físico subyacente. Los cambios reflejan únicamente los cambios en los datos a nivel SQL, en términos de INSERT, UPDATE y DELETE. Esta independencia de la capa de almacenamiento proporciona una gran flexibilidad y permite una amplia gama de funcionalidades para los usuarios de los flujos de cambios.

La replicación lógica es la característica principal basada en la decodificación lógica.

A diferencia de la replicación física de PostgreSQL, que requiere que las bases de datos de origen y destino tengan la misma versión, la replicación lógica permite la replicación entre 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 con la replicación lógica nativa de PostgreSQL, añadida en PostgreSQL 10.

El formato de transmisión de los cambios se puede configurar con diferentes complementos. Esto permite arquitecturas flexibles de captura de datos de cambios (CDC). Por ejemplo, la extensión wal2json permite transmitir todos los cambios de una base de datos a un consumidor, en formato JSON. Cloud SQL admite el decodificador pgoutput integrado, el módulo contrib test_decoding y wal2json . Cloud SQL admite actualmente ambas variantes de salida JSON de wal2json : 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 a bases de datos que no son PostgreSQL.

Configurar su instancia de PostgreSQL

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

En Cloud SQL, esta función se habilita configurando el indicador cloudsql.logical_decoding en on . Esta configuración es diferente a la utilizada en PostgreSQL estándar. Si modifica una instancia externa de PostgreSQL, esta función se habilita configurando el parámetro de configuración wal_level en " logical .

Si planea usar la extensión pglogical, debe agregarla a shared_preload_libraries . Dado que Cloud SQL no permite la modificación directa de esta opción, pglogical se habilita configurando cloudsql.enable_pglogical en on . (En una máquina virtual, ejecute sudo apt-get install postgresql-13-pglogical) y reinicie la base de datos.

Si utiliza pglogical para replicar entre dos instancias de PostgreSQL, la decodificación lógica solo debe habilitarse en la instancia principal , no en la réplica (a menos que esta sea la instancia 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, consulte Acerca de la replicación en Cloud SQL .

Habilitar la conectividad de red

Asegúrese de que sus instancias principales acepten conexiones desde la instancia de réplica.

Obtener la dirección IP saliente 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, realice los siguientes pasos para obtener su dirección IP saliente.

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

Permitir conexiones

Si la instancia principal es una instancia de Cloud SQL, puede permitir el acceso desde la dirección IP saliente de la réplica agregándola como una red autorizada .

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

Si su instancia principal no se ejecuta en Cloud SQL y sí ejecuta PostgreSQL 9.6 o una versión anterior, debe asegurarse de que el archivo pg_hba.conf de la instancia esté configurado para aceptar conexiones de replicación. Añada la siguiente línea a ese archivo, utilizando all all solo para las pruebas iniciales. Para mayor seguridad, limite los usuarios y las direcciones IP solo a los necesarios, como en este ejemplo:

host replication all all md5

Para obtener información adicional, consulte El archivo pg_hba.conf .

Crear un usuario de replicación

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

Ejemplos

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

Alternativamente, puede configurar este atributo en un usuario existente:

ALTER USER existing_user WITH REPLICATION;

Recursos de PostgreSQL

Cuando se utiliza 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 mediante el complemento de decodificación seleccionado y los retransmite a un consumidor (que podría ser una instancia externa a PostgreSQL). Este proceso en segundo plano se denomina remitente de WAL. El número de remitentes de WAL simultáneos que pueden estar activos en una instancia de PostgreSQL está limitado por el indicador max_wal_senders . Este indicador tiene un valor predeterminado de 10 y su límite aumenta linealmente 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 WAL no se descarten antes de enviarse a todos los consumidores, PostgreSQL utiliza ranuras de replicación lógicas para rastrear qué datos se enviaron a cada consumidor (y ranuras de replicación físicas para las réplicas de lectura). El número de ranuras de replicación que se pueden crear para una instancia de PostgreSQL está limitado por el indicador max_replication_slots . Este indicador tiene un valor predeterminado de 10 y su límite aumenta con la memoria de la instancia de Cloud SQL, lo que permite entre 2 y 8 ranuras de replicación por GB de memoria.

La siguiente tabla 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.

Generalmente hay una ranura de replicación y un remitente WAL por consumidor, por lo que estos indicadores deben tener valores aproximadamente iguales. Sin embargo, PostgreSQL recomienda proporcionar un pequeño margen para que max_wal_senders gestione las conexiones cuando se interrumpen inesperadamente y se establecen nuevas. La replicación física, como la que utilizan las réplicas de lectura de Cloud SQL, también utiliza una ranura de replicación y un remitente WAL, así que téngalos en cuenta al calcular la cantidad de cada recurso que necesita.

La replicación lógica nativa de PostgreSQL y pglogical requieren procesos adicionales en segundo plano para su ejecución, 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 el indicador max_worker_processes . El valor predeterminado es ocho y su límite aumenta linealmente con la memoria de la instancia de Cloud SQL, lo que permite dos procesos adicionales por GB de memoria. El número exacto de procesos de trabajo utilizados con estos enfoques se explica en sus respectivas secciones.

Si este indicador se establece demasiado bajo y la replicación falla con el mensaje de error worker registration failed en sus registros, probablemente necesite aumentar la configuración max_worker_processes .

Tenga en cuenta que los remitentes de WAL no se consideran procesos de trabajo. Los trabajadores generados para la ejecución de consultas paralelas sí se consideran, por lo que si el valor de max_worker_processes es demasiado bajo, podría experimentar un rendimiento deficiente, ya que PostgreSQL no puede aprovechar la ejecución de consultas paralelas.

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

Para calcular el uso total del disco WAL:

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

Consulte Configuración de réplicas externas para obtener un ejemplo completo utilizando pglogical y 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. Configure 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 de réplica; configure cloudsql.enable_pglogical=on en una instancia de Cloud SQL o agregue pglogical a shared_preload_libraries en una instancia externa. Tenga en cuenta que cambiar estos indicadores requiere reiniciar tanto la instancia principal como la de réplica.

Si encuentra problemas con estos pasos, consulte Solucionar problemas de pglogical .

Crear un usuario con privilegios de replicación

Necesita un usuario con privilegios de replicación y el rol cloudsqlsuperuser tanto en la instancia principal como en la réplica al usar pglogical. Ese usuario debe ejecutar todos los comandos descritos a continuación.

Instalar la extensión pglogical

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

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 de dicha 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'
);

Crear una tabla con datos para replicar

La extensión pglogical permite replicar solo un subconjunto de tablas a un destino. Por ejemplo, crearemos una tabla ficticia en la instancia principal y la rellenaremos con datos para realizar 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.

Agregar la tabla a un conjunto de replicación

Para permitir la replicación de diferentes conjuntos de datos a distintos destinos, pglogical utiliza el concepto de 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);

Crear la suscripción pglogical

Cree la suscripción pglogical en la instancia de destino proporcionando 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 aparece como "replicando", la configuración se ha realizado correctamente. Consulte la tabla replica_test para comprobar que los datos se han replicado. Inserte y modifique registros en la instancia principal y verifique que aparezcan en la instancia de réplica.

En el servidor principal, consulte la tabla pg_replication_slots para ver la ranura de replicación creada por la suscripción.

Limpieza

Tras la prueba, cancele la suscripción en la réplica mediante pglogical.drop_subscription('test_sub') . Verifique que la ranura de replicación también se cancele en la instancia principal. De lo contrario, los segmentos WAL seguirán acumulándose en la réplica.

Para obtener más información sobre conjuntos de replicación, replicación de datos parciales, replicación DDL, otras configuraciones avanzadas y limitaciones, consulte la documentación de pglogical .

Uso de recursos

La extensión pglogical ejecuta múltiples procesos en segundo plano que cuentan para el límite max_worker_processes .

En estado estable, ejecuta un proceso "supervisor" cuando está habilitado, un proceso "manager" por cada base de datos PostgreSQL que tenga instalada la extensión (por ejemplo, podría haber D ) y un proceso "apply" 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 "manager" para cada base de datos de la instancia; sin embargo, si la base de datos no tiene la extensión instalada, se cierra inmediatamente.

Por lo tanto, asigne algunos procesos de trabajo más de los necesarios en el estado estable. PostgreSQL utiliza los procesos de trabajo para otros fines, como el procesamiento de consultas paralelas. Si el valor max_worker_processes es demasiado bajo, la replicación podría fallar silenciosamente o PostgreSQL podría no poder realizar el procesamiento de consultas paralelas.

En resumen, se recomiendan estas configuraciones:

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, es posible que vea el error:

ERROR:  pglogical is not in shared_preload_libraries

Al instalar pglogical en una instancia de Cloud SQL, asegúrese de haber configurado cloudsql.enable_pglogical=on . Si usa una instancia externa, agréguela directamente al indicador shared_preload_libraries ; por ejemplo, shared_preload_libraries=pg_stat_statements,pglogical . Estas modificaciones requieren reiniciar la instancia principal.

No se puede crear la suscripción pglogical

Al crear una suscripción, pglogical primero comprueba que puede usar los datos de conexión para conectarse a la instancia. Primero intenta crear una conexión normal y, si falla, se produce el error: ERROR: could not connect to the postgresql server .

Si se produce este error, asegúrese de que la instancia principal esté configurada para permitir conexiones desde la réplica y de que los datos de conexión proporcionados sean correctos. Se proporciona información adicional sobre por qué PostgreSQL no pudo establecer una conexión.

Tras crear una conexión regular, pglogical intenta establecer 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. Debe actualizar el archivo pg_hba.conf en la instancia de origen si ve este error: ERROR: could not connect to the postgresql server in replication mode .

El archivo pg_hba.conf utilizado por Cloud SQL ya tiene los cambios necesarios; este error solo ocurre cuando se conecta a una instancia externa que no está administrada por Cloud SQL.

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

La suscripción a pglogical está inactiva

Es posible que una suscripción pglogical no se replique. Para solucionar este problema, primero asegúrese de que se esté ejecutando un proceso en segundo plano en la instancia de réplica. Consulte pg_stat_activity para verificar que se esté ejecutando un proceso pglogical apply . De lo contrario, revise los registros del nodo de destino. Si ve el mensaje worker registration failed, puede aumentar el valor de max_worker_processes .

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

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

Un error de ERROR: logical decoding requires wal_level >= logical implica que el indicador wal_level no estaba configurado en logical . Para solucionarlo, configure cloudsql.logical_decoding=on en la instancia principal si se trata de una instancia de Cloud SQL.

Alternativamente, si la instancia es una instancia externa, establezca wal_level=logical .

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

Configurar la replicación lógica nativa de PostgreSQL

A partir de PostgreSQL 10, PostgreSQL admite la replicación lógica nativa integrada. Para configurar la replicación lógica nativa, se debe habilitar la decodificación lógica en la instancia principal, configurando cloudsql.logical_decoding=on en una instancia de Cloud SQL o wal_level=logical en una instancia externa. Tenga en cuenta que la modificación de estos indicadores requiere reiniciar la instancia principal.

Asegúrese de que sus instancias estén configuradas correctamente (para la conectividad de red, etc.) revisando las secciones de "Configurar su instancia de PostgreSQL" . Esta página proporciona los pasos para una prueba de concepto. Si encuentra algún problema al seguir los pasos de estas secciones, consulte "Solucionar problemas de pglogical" . Para obtener más información, consulte "Replicación lógica" en la documentación de PostgreSQL.

Crear una tabla con datos para replicar

La replicación lógica nativa de PostgreSQL admite una base de datos completa o solo tablas individuales. Por ejemplo, crearemos una tabla ficticia en la instancia principal y la rellenaremos con datos para realizar 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 gestiona publicadores y suscriptores. Cree 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

A continuación se muestra un ejemplo de creación de 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 requiere el rol cloudsqlsuperuser . Después de crear la suscripción, consulte la tabla native_test para verificar que los datos hayan aparecido en la instancia de réplica.

En el servidor principal, puede consultar la tabla pg_replication_slots para ver la ranura de replicación creada por la suscripción.

Limpieza

Una vez que la prueba sea exitosa, cancele la suscripción en la réplica con DROP SUBSCRIPTION sub; Verifique que la ranura de replicación también se cancele en la instancia principal. De lo contrario, los segmentos WAL continúan acumulándose en la instancia principal.

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

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

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

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

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

Puede usar la herramienta pg_recvlogical para crear una ranura de replicación y transmitir los cambios registrados por dicha ranura. El formato de los cambios depende del complemento de decodificación seleccionado. Puede usar:

• wal2json , para transmitir cambios formateados como JSON, o

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

Crear ranura de replicación

Para crear una ranura de replicación, ejecute:

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

Cambios en la transmisión

En una terminal de Cloud Shell, ejecute:

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

Mientras esté en otra terminal de Cloud Shell, conéctese a su base de datos y ejecute 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 está utilizando el complemento 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 está utilizando el complemento decodificador test_decoding , en la primera terminal de Cloud Shell se muestra un resultado similar al siguiente:

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

(Sus ID de transacción pueden ser diferentes).

Limpieza

Después de completar la prueba, elimine la ranura de replicación que creó ejecutando:

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

• La extensión pglogical no funciona en instancias con la aplicación de conectores habilitada. Esta limitación no se aplica a las instancias con acceso privado a servicios configurado.

• Al restaurar una instancia con cloudsql.logical_decoding o cloudsql.enable_pglogical habilitados y que actualmente actúa como publicador para la replicación lógica, primero debe deshabilitar la replicación en todas las instancias de destino. De lo contrario, la restauración a la instancia falla con un error, pero los detalles del error no están visibles.

• Al restaurar una copia de seguridad de una instancia que tenía habilitados cloudsql.logical_decoding o cloudsql.enable_pglogical (en el momento de la copia de seguridad) y restaurarla en una nueva instancia, el estado de replicación no se restaura en la nueva instancia. Posteriormente, deberá reconfigurar la replicación manualmente.

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

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

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

  • Al habilitar cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal, se activan los indicadores en todas las réplicas de lectura, lo que provoca que las réplicas principal y de lectura se reinicien en breve sucesión. Para evitar esta situación y controlar cuándo se reinicia cada instancia, puede (1) activar los indicadores en cada réplica de lectura por turnos y, solo entonces, (2) activarlos en la instancia principal.

  • Deshabilitar cloudsql.logical_decoding o cloudsql.enable_pglogical en la instancia principal no deshabilita las marcas en todas las réplicas de lectura. Para deshabilitarlas en todas las instancias, debe realizar los pasos inversos descritos anteriormente: (1) deshabilite las marcas en la instancia principal y luego (2) deshabilite las marcas en cada réplica de lectura, una por una.