Configurazione di replica e decodifica logiche

Puoi utilizzare le funzionalità di replica e decodifica logiche in Cloud SQL per PostgreSQL. Queste funzionalità consentono i workflow di replica logica e di Change Data Capture (CDC).

Per informazioni generali sulla replica, consulta Informazioni sulla replica in Cloud SQL.

Introduzione

Quando PostgreSQL esegue la replica logica, le modifiche trasmesse in streaming alle repliche vengono estratte dai log WAL utilizzando la decodifica logica. Le modifiche decodificate sono indipendenti dal formato di archiviazione fisica sottostante. Le modifiche riflettono solo le modifiche ai dati a livello SQL, in termini di INSERT, UPDATE e DELETE. Questa indipendenza dal livello di archiviazione offre una grande flessibilità e consente un'ampia gamma di funzionalità per i consumer delle modifiche in tempo reale.

La replica logica è la funzionalità principale basata sulla decodifica logica.

A differenza della funzionalità di replica fisica di PostgreSQL, che richiede che i database di origine e di destinazione siano della stessa versione, la replica logica consente la replica tra le versioni principali di PostgreSQL. La replica logica in Cloud SQL è supportata dall'estensione pglogical, disponibile in tutte le versioni di PostgreSQL, e dalla replica logica nativa di PostgreSQL, aggiunta in PostgreSQL 10.

Il formato in cui vengono trasmessi i flussi di modifiche può essere configurato con diversi plug-in. Ciò consente di creare architetture flessibili di Change Data Capture (CDC). Ad esempio, l'estensione wal2json consente di trasmettere in streaming tutte le modifiche di un database a un consumer, formattate come JSON. Cloud SQL supporta il decodificatore pgoutput integrato, il modulo contrib test_decoding e wal2json. Cloud SQL attualmente supporta entrambe le varianti wal2json dell'output JSON: format-version 1, che codifica l'intera transazione come un singolo oggetto JSON, e format-version 2, che restituisce un oggetto JSON per comando. Questi plug-in consentono la replica in database non PostgreSQL.

Configura l'istanza PostgreSQL

PostgreSQL supporta la decodifica logica scrivendo informazioni aggiuntive nel suo write-ahead log (WAL).

In Cloud SQL, questa funzionalità viene attivata impostando il flag cloudsql.logical_decoding su on. Questa impostazione è diversa da quella utilizzata in PostgreSQL standard. Se modifichi un'istanza PostgreSQL esterna, attivi questa funzionalità impostando il parametro di configurazione wal_level su logical.

Se prevedi di utilizzare l'estensione pglogical, devi aggiungere pglogical a shared_preload_libraries. Poiché Cloud SQL non consente la modifica diretta di questo flag, pglogical viene attivato impostando cloudsql.enable_pglogical su on. (Su una VM, sudo apt-get install postgresql-13-pglogical) e riavvia il database.

Se utilizzi pglogical per la replica tra due istanze PostgreSQL, la decodifica logica deve essere abilitata solo nell'istanza principale e non nell'istanza di replica (a meno che l'istanza stessa non sia un'istanza principale per altre repliche). Tuttavia, l'estensione pglogical deve essere abilitata su entrambe le istanze. Per esempi di come vengono utilizzati i termini "principale" e "replica" e i relativi significati, consulta Informazioni sulla replica in Cloud SQL.

Abilita la connettività di rete

Assicurati che le istanze principali accettino le connessioni dall'istanza di replica.

Ottieni l'indirizzo IP in uscita di un'istanza di replica

Se l'istanza di replica è un'istanza Cloud SQL e ha un indirizzo IP pubblico, segui questi passaggi per ottenere il suo indirizzo IP in uscita.

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

Consenti connessioni

Se l'istanza principale è un'istanza Cloud SQL, puoi consentire l'accesso dall'indirizzo IP in uscita della replica aggiungendolo come rete autorizzata.

Abilita le connessioni di replica per PostgreSQL 9.6 e versioni precedenti

Se l'istanza principale non è in esecuzione in Cloud SQL ed esegue PostgreSQL 9.6 o versioni precedenti, devi assicurarti che il file pg_hba.conf dell'istanza sia impostato per accettare le connessioni di replica. Aggiungi la seguente riga al file, utilizzando all all solo per i test iniziali. Per una maggiore sicurezza, limita gli utenti e gli indirizzi IP solo a quelli richiesti, come in questo esempio:

host replication all all md5

Per ulteriori informazioni, consulta Il file pg_hba.conf.

Crea un utente di replica

Per utilizzare le funzionalità di decodifica logica, crea un utente PostgreSQL con l'attributo REPLICATION.

Esempi

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

In alternativa, puoi impostare questo attributo su un utente esistente:

ALTER USER existing_user WITH REPLICATION;

Risorse PostgreSQL

Quando viene utilizzata la decodifica logica, un processo in background nell'istanza PostgreSQL principale trasforma le modifiche WAL in modifiche logiche, utilizzando il plug-in di decodifica selezionato, e le trasmette a un consumer (che potrebbe anche essere un'istanza non PostgreSQL). Questo processo in background è chiamato WAL sender. Il numero di mittenti WAL simultanei che possono essere attivi in un'istanza PostgreSQL è limitato dal flag max_wal_senders. Il valore predefinito di questo flag è 10 e il suo limite cresce in modo lineare con la memoria dell'istanza Cloud SQL, consentendo 8 mittenti WAL per GB di memoria.

Per garantire che i segmenti WAL non vengano eliminati prima di essere inviati a tutti i consumer, PostgreSQL utilizza slot di replica logica per monitorare quali dati sono stati inviati a quale consumer (e slot di replica fisici per le repliche di lettura). Il numero di slot di replica che puoi creare per un'istanza PostgreSQL è limitato dal flag max_replication_slots. Il valore predefinito di questo flag è 10 e il suo limite aumenta con la memoria dell'istanza Cloud SQL, consentendo tra 2 e 8 slot di replica per GB di memoria.

La tabella seguente mostra la relazione tra la memoria massima di un'istanza Cloud SQL e gli slot di replica massimi per l'istanza.

In genere esiste uno slot di replica e un mittente WAL per consumer, quindi questi flag devono essere impostati su valori approssimativamente uguali. Tuttavia, PostgreSQL consiglia di fornire un piccolo buffer per max_wal_senders per gestire i casi in cui le connessioni si interrompono inaspettatamente e vengono stabilite nuove connessioni. La replica fisica, utilizzata dalle repliche di lettura di Cloud SQL, utilizza anche uno slot di replica e un mittente WAL, quindi tienili in considerazione quando calcoli la quantità di ogni risorsa necessaria.

La replica logica nativa di PostgreSQL e pglogical richiedono l'esecuzione di processi in background aggiuntivi, sia sulle istanze principali che su quelle di replica. Il numero di processi in background che possono essere eseguiti è limitato dal flag max_worker_processes. Il valore predefinito è otto e il limite cresce in modo lineare con la memoria dell'istanza Cloud SQL, consentendo due processi aggiuntivi per GB di memoria. Il numero esatto di processi worker utilizzati con questi approcci è spiegato nelle rispettive sezioni.

Se questo flag è impostato su un valore troppo basso e la replica non riesce con il messaggio di errore worker registration failed nei log, probabilmente devi aumentare l'impostazione max_worker_processes.

Tieni presente che i mittenti WAL non vengono conteggiati come processi worker. I worker generati per l'esecuzione di query parallele vengono conteggiati, quindi se il valore di max_worker_processes è impostato su un valore troppo basso, potresti riscontrare prestazioni scadenti perché PostgreSQL non può sfruttare l'esecuzione di query parallele.

Utilizzando la funzione pg_ls_waldir (), puoi determinare l'utilizzo del disco WAL. Questa funzione è limitata agli utenti cloudsqlsuperuser, ad esempio l'utente amministratore predefinito postgres. Questa funzione è disponibile solo in PostgreSQL versione 10 e successive.

Per calcolare l'utilizzo totale del disco WAL:

postgres=> select * from pg_ls_waldir();

(2 rows)

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

(1 riga)

Configura la replica logica con una replica esterna

Consulta Configurazione delle repliche esterne per un esempio completo che utilizza pglogical e la decodifica logica.

Configura la replica logica con pglogical

Per configurare la replica logica con pglogical, la decodifica logica deve essere abilitata sull'istanza principale. Imposta cloudsql.logical_decoding=on sull'istanza Cloud SQL o wal_level=logical su un'istanza esterna. Inoltre, pglogical deve essere abilitato sia nell'istanza principale che in quella di replica; imposta cloudsql.enable_pglogical=on su un'istanza Cloud SQL o aggiungi pglogical a shared_preload_libraries su un'istanza esterna. Tieni presente che la modifica di questi flag richiede il riavvio delle istanze principale e di replica.

Se riscontri problemi con questi passaggi, consulta Risolvi i problemi di pglogical.

Crea un utente con privilegi di replica

Quando utilizzi pglogical, hai bisogno di un utente con privilegi di replica e il ruolo cloudsqlsuperuser sia nell'istanza principale che in quella di replica. Tutti i comandi descritti di seguito devono essere eseguiti da quell'utente.

Installa l'estensione pglogical

Devi installare l'estensione pglogical sia sull'istanza principale sia su quella di replica. Sul database principale, l'utente di replica (ovvero l'utente che si connette al database) deve installarlo.

CREATE EXTENSION pglogical;

Crea un nodo pglogical su ogni istanza

Un nodo pglogical rappresenta un'istanza PostgreSQL fisica e memorizza i dettagli di connessione per l'istanza. Sia l'istanza principale sia quella di replica devono registrarsi come nodi:

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 tabella con i dati da replicare

L'estensione pglogical consente di replicare solo un sottoinsieme di tabelle in una destinazione. Ad esempio, creeremo una tabella fittizia nell'istanza principale e la compileremo con alcuni dati per il test:

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

La tabella deve essere creata anche nell'istanza di replica.

Aggiungi la tabella a un set di replica

Per supportare la replica di diversi set di dati in destinazioni diverse, pglogical utilizza il concetto di set di replica. Possiamo aggiungere la nostra tabella di test al set di replica predefinito.

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

Crea la sottoscrizione pglogical

Crea la sottoscrizione pglogical nell'istanza di destinazione fornendo i dettagli di connessione all'istanza principale.

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

Se lo stato è "In fase di replica", la configurazione è riuscita. Esegui una query sulla tabella replica_test per assicurarti che i dati siano stati replicati. Inserisci e modifica i record nell'istanza principale e verifica che vengano visualizzati nell'istanza di replica.

Nell'istanza principale, esegui una query sulla tabella pg_replication_slots per visualizzare lo slot di replica creato dalla sottoscrizione.

Esegui la pulizia

Una volta eseguito il test, elimina la sottoscrizione sulla replica utilizzando pglogical.drop_subscription('test_sub'). Verifica che lo slot di replica sia stato eliminato anche sul database primario. In caso contrario, i segmenti WAL continuano ad accumularsi nell'istanza di replica.

Per saperne di più sui set di replica, sulla replica parziale dei dati, sulla replica DDL, su altre configurazioni avanzate e sulle limitazioni, consulta la documentazione di pglogical.

Utilizzo delle risorse

L'estensione pglogical esegue più processi in background che vengono conteggiati ai fini del limite max_worker_processes.

In stato stabile, esegue un processo "supervisor" quando è abilitato, un processo "manager" per database PostgreSQL in cui è installata l'estensione (ad esempio, potrebbero essercene D) e un processo "apply" per sottoscrizione pglogical nell'istanza di replica (ad esempio, potrebbero essercene S). Tuttavia, l'estensione potrebbe generare processi worker aggiuntivi durante l'esecuzione di una sincronizzazione iniziale e genera effettivamente processi "manager" per ogni database nell'istanza, ma se nel database non è installata l'estensione, esce immediatamente.

Pertanto, alloca un numero di processi worker leggermente superiore a quello necessario nello stato stabile. I processi worker vengono utilizzati da PostgreSQL per altri scopi, ad esempio l'elaborazione parallela delle query. Se max_worker_processes è impostato su un valore troppo basso, la replica potrebbe non riuscire senza segnalazioni o PostgreSQL potrebbe non essere in grado di eseguire l'elaborazione delle query in parallelo.

In sintesi, ti consigliamo di utilizzare queste impostazioni:

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)

Risolvi i problemi di pglogical

Impossibile creare l'estensione pglogical

Quando provi a installare l'estensione pglogical, potresti visualizzare l'errore:

ERROR:  pglogical is not in shared_preload_libraries

Quando installi pglogical su un'istanza Cloud SQL, assicurati di aver impostato cloudsql.enable_pglogical=on. Se utilizzi un'istanza esterna, aggiungila direttamente al flag shared_preload_libraries, ad esempio shared_preload_libraries=pg_stat_statements,pglogical. Queste modifiche richiedono il riavvio dell'istanza principale.

Impossibile creare la sottoscrizione pglogical

Quando crei una sottoscrizione, pglogical verifica innanzitutto che sia possibile utilizzare i dettagli della connessione per connettersi all'istanza. Innanzitutto, tenta di creare una connessione regolare e, se non riesce, si verifica un errore: ERROR: could not connect to the postgresql server.

Se si verifica questo errore, assicurati che l'istanza principale sia configurata per consentire le connessioni dall'istanza di replica e che i dettagli di connessione forniti siano corretti. Vengono forniti ulteriori dettagli sul motivo per cui PostgreSQL non è riuscito a stabilire una connessione.

Dopo aver creato una connessione regolare, pglogical tenta di stabilire una connessione di replica speciale. In PostgreSQL 9.6 e versioni precedenti, questo tipo di connessione potrebbe avere una configurazione di autenticazione diversa. Se visualizzi questo errore: ERROR: could not connect to the postgresql server in replication mode, devi aggiornare il file pg_hba.conf nell'istanza di origine.

Il file pg_hba.conf utilizzato da Cloud SQL contiene già le modifiche necessarie; questo errore si verifica solo quando ci si connette a un'istanza esterna non gestita da Cloud SQL.

In alternativa, la connessione in modalità di replica potrebbe non riuscire se l'istanza di origine non consente un numero sufficiente di mittenti WAL. Se vedi FATAL: number of requested standby connections exceeds max_wal_senders, aumenta max_wal_senders nell'istanza principale.

La sottoscrizione pglogical non è attiva

La replica di una sottoscrizione pglogical potrebbe non riuscire. Per risolvere il problema, assicurati innanzitutto che nell'istanza di replica sia in esecuzione un processo in background. Esegui una query su pg_stat_activity per verificare che un processo pglogical apply sia in esecuzione. In caso contrario, controlla i log sul nodo di destinazione. Se visualizzi il messaggio worker registration failed,, puoi aumentare l'impostazione max_worker_processes.

Quindi, assicurati che sia stato creato uno slot di replica nell'istanza principale. Nell'istanza di replica, la riga in pglogical.subscription contiene il nome dello slot che la sottoscrizione tenta di creare, mentre nell'istanza principale puoi eseguire una query su pg_replication_slots per verificare che lo slot sia stato creato correttamente.

Se non è stato creato alcuno slot di replica, controlla i log nell'istanza principale.

Un errore di ERROR: logical decoding requires wal_level >= logical implica che il flag wal_level non è stato impostato su logical. Risolvi il problema impostando cloudsql.logical_decoding=on sull'istanza principale se si tratta di un'istanza Cloud SQL.

In alternativa, se l'istanza è un'istanza esterna, imposta wal_level=logical.

In caso contrario, potresti visualizzare ERROR: all replication slots are in use, insieme all'utile HINT: Free one or increase max_replication_slots.

Configura la replica logica PostgreSQL nativa

A partire dalla versione 10, PostgreSQL supporta la replica logica integrata nativa. Per configurare la replica logica nativa, la decodifica logica deve essere abilitata sull'istanza principale, impostando cloudsql.logical_decoding=on su un'istanza Cloud SQL o wal_level=logical su un'istanza esterna. Tieni presente che la modifica di questi flag richiede il riavvio dell'istanza principale.

Assicurati che le istanze siano configurate correttamente (per la connettività di rete e così via) consultando le sezioni in Configura l'istanza PostgreSQL. Questa pagina fornisce i passaggi per un proof of concept. Se riscontri problemi durante l'esecuzione dei passaggi descritti in queste sezioni, consulta Risolvi i problemi di pglogical. Per saperne di più, consulta Replica logica nella documentazione di PostgreSQL.

Crea una tabella con i dati da replicare

La replica logica nativa di PostgreSQL supporta un intero database o solo singole tabelle. Ad esempio, creeremo una tabella fittizia nell'istanza principale e la compileremo con i dati da testare.

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

La tabella deve essere creata anche nell'istanza di replica.

Crea una pubblicazione nell'istanza principale

La replica logica nativa di PostgreSQL si occupa di publisher e sottoscrittori. Crea una pubblicazione dei dati in native_test:

CREATE PUBLICATION pub FOR TABLE native_test;

Crea una sottoscrizione nell'istanza di replica

Ecco un esempio di creazione di una sottoscrizione nell'istanza di replica:

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

Per creare la sottoscrizione nell'istanza di replica è necessario il ruolo cloudsqlsuperuser. Dopo aver creato la sottoscrizione, esegui una query sulla tabella native_test per verificare che i dati siano visualizzati nell'istanza di replica.

Sull'istanza principale, puoi eseguire una query sulla tabella pg_replication_slots per visualizzare lo slot di replica creato dalla sottoscrizione.

Esegui la pulizia

Una volta completato il test, elimina la sottoscrizione sulla replica utilizzando DROP SUBSCRIPTION sub;. Verifica che lo slot di replica sia stato eliminato anche sul database principale. In caso contrario, i segmenti WAL continuano ad accumularsi nell'istanza principale.

Limitazioni della replica logica nativa di PostgreSQL

L'accesso alla colonna subconninfo della tabella di sistema pg_subscription non è disponibile.

L'esecuzione di pg_dump non può eseguire il dump delle informazioni sulle sottoscrizioni perché verifica se l'utente che si connette dispone delle autorizzazioni di super utente.

Ricevi le modifiche WAL decodificate per Change Data Capture (CDC)

Come caso d'uso alternativo per CDC, la decodifica logica può trasmettere in streaming le modifiche da un'istanza PostgreSQL. Lo strumento standard utilizzato per questa operazione è pg_recvlogical.

Puoi utilizzare lo strumento pg_recvlogical per creare uno slot di replica e per trasmettere in streaming le modifiche monitorate da questo slot. Il formato delle modifiche è determinato dalla scelta del plug-in di decodifica. Puoi utilizzare:

• wal2json, per trasmettere in streaming le modifiche formattate come JSON o

• test_decoding, per trasmettere in streaming le modifiche formattate con un formato di testo di base

Crea slot di replica

Per creare uno slot di replica, esegui:

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

Modifiche in tempo reale

In un terminale Cloud Shell, esegui:

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

In un altro terminale Cloud Shell, connettiti al tuo database ed esegui questi comandi:

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;

Se utilizzi il plug-in del decoder wal2json, nel primo terminale Cloud Shell viene visualizzato un output simile al seguente:

{"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":[]}

Se utilizzi il plug-in del decoder test_decoding, nel primo terminale Cloud Shell viene visualizzato un output simile al seguente:

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

(Gli ID transazione potrebbero essere diversi).

Esegui la pulizia

Al termine dei test, elimina lo slot di replica creato eseguendo:

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

Note e limitazioni

Le note e le limitazioni di questa sezione si applicano alle funzionalità di replica e decodifica logiche di Cloud SQL per PostgreSQL.

• Le istanze che utilizzano l'alta affidabilità (HA) non possono essere utilizzate come sottoscrittori della replica, perché non hanno un indirizzo IP in uscita coerente.

• L'estensione pglogical non funziona nelle istanze in cui è abilitata l'applicazione dei connettori. Questa limitazione non si applica alle istanze per cui è configurato l'accesso privato ai servizi.

• Quando ripristini un'istanza in cui è abilitato cloudsql.logical_decoding o cloudsql.enable_pglogical e che attualmente funge da publisher per la replica logica, devi prima disabilitare la replica in tutte le istanze target. In caso contrario, il ripristino nell'istanza non va a buon fine e viene generato un errore, ma al momento i dettagli dell'errore non sono visibili.

• Quando ripristini un backup di un'istanza in cui era abilitata la replica cloudsql.logical_decoding o cloudsql.enable_pglogical (al momento del backup) e lo ripristini in una nuova istanza, lo stato della replica non viene ripristinato nella nuova istanza. In seguito, dovrai riconfigurare la replica manualmente.

• In un'istanza Cloud SQL con una o più repliche di lettura Cloud SQL (che utilizzano la replica fisica), se attivi cloudsql.logical_decoding o cloudsql.enable_pglogical, questi flag vengono attivati anche nella replica di lettura.

  • Per le versioni 15 e precedenti di Cloud SQL per PostgreSQL, le istanze di replica di lettura di Cloud SQL non possono fungere da publisher per la replica logica perché PostgreSQL non supporta la decodifica logica sulle repliche di lettura per queste versioni precedenti. Tuttavia, per garantire che le istanze possano fungere da sostituto dell'istanza principale in caso di promozione, i flag logici sono ancora abilitati nelle istanze di replica di lettura per queste versioni precedenti.

  • A partire dalla versione 16 di Cloud SQL per PostgreSQL, le istanze di replica di lettura di Cloud SQL possono fungere da publisher per la replica logica, se nell'istanza principale sono impostati i flag logici. Il sottoscrittore logico può essere un'istanza Cloud SQL o un'istanza esterna. Tuttavia, le operazioni di eliminazione delle righe e di vacuum sull'istanza principale potrebbero eliminare tuple ancora necessarie per la decodifica logica sulla replica di lettura. In questi casi, lo slot di replica logica sulla replica di lettura viene annullato per evitare incoerenze.

  • L'abilitazione di cloudsql.logical_decoding o cloudsql.enable_pglogical sull'istanza principale comporta l'abilitazione dei flag su tutte le repliche di lettura, il che causa il riavvio dell'istanza principale e delle repliche di lettura in rapida successione. Per evitare questa situazione e controllare quando viene riavviata ogni istanza, puoi (1) impostare i flag su ogni replica di lettura a turno e solo successivamente (2) impostare i flag sull'istanza principale.

  • La disattivazione di cloudsql.logical_decoding o cloudsql.enable_pglogical sull'istanza principale non comporta la disattivazione dei flag su tutte le repliche di lettura. Per disabilitare i flag nelle istanze, devi eseguire l'operazione inversa dei passaggi descritti sopra: (1) disabilita i flag nell'istanza principale e poi (2) disabilita i flag in ogni replica di lettura.