Puoi utilizzare le funzionalità di replica e decodifica logiche in Cloud SQL per PostgreSQL. Queste funzionalità consentono flussi di lavoro di replica logica e flussi di lavoro 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 alle repliche vengono estratte dai log WAL utilizzando la decodifica logica. Le modifiche decodificate sono indipendenti dal formato di archiviazione fisico 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 grande flessibilità e consente un'ampia gamma di funzionalità da parte dei consumatori deimodifiche in tempo realee.
La replica logica è la funzionalità di punta 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 in streaming i cambiamenti può essere configurato con diversi
plug-in. Ciò consente architetture
Change Data Capture
(CDC) flessibili.
Ad esempio, l'estensione wal2json
consente di trasmettere in streaming tutte le modifiche in 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 log write-ahead (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, questa deve essere aggiunta a
shared_preload_libraries. Poiché Cloud SQL non consente la modifica diretta
di questo flag, pglogical viene abilitato 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 sull'istanza principale e non sull'istanza di replica (a meno che l'istanza stessa non sia un'istanza principale per altre repliche). Tuttavia, l'estensione pglogical deve essere attivata su entrambe le istanze. Per esempi di come vengono utilizzati i termini "primario" e "replica" e i relativi significati, consulta Informazioni sulla replica in Cloud SQL.
Attivare la connettività di rete
Assicurati che le istanze principali accettino le connessioni dall'istanza di replica.
| Principale | Replica | Configurazione |
|---|---|---|
| Cloud SQL (IP pubblico) | Cloud SQL (IP pubblico) | Aggiungi l'indirizzo IP in uscita della replica alle reti autorizzate del database principale. |
| Cloud SQL (IP privato) | Cloud SQL (IP privato) | Se entrambe le istanze si trovano nello stesso Google Cloud progetto, aggiungi l'
intervallo IP allocato della rete VPC della replica alla rete autorizzata che ospita le istanze.
Per trovare l'intervallo IP allocato nella console Google Cloud :
|
| Esterno | Cloud SQL | Puoi utilizzare il servizio di migrazione dei database. |
| Cloud SQL | Esterno | Per saperne di più, consulta Configurare repliche esterne. |
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.
Console
Apri la pagina Istanze Cloud SQL.
Accanto all'indirizzo IP pubblico della replica Cloud SQL, passa il mouse sopra il suggerimento Più informazioni e recupera l'indirizzo IP in uscita. Tieni presente che l'indirizzo IP in uscita non è l'indirizzo IP visualizzato nell'elenco principale della replica nella console Google Cloud.
Se l'istanza di replica non è un'istanza Cloud SQL, consulta la documentazione pertinente.
Per saperne di più su come ottenere l'indirizzo IP pubblico di un'istanza, consulta Ottenere l'indirizzo IP in uscita della replica Cloud SQL.
gcloud
Puoi utilizzare il seguente comando gcloud:
gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"
Consenti connessioni
Se l'istanza primaria è un'istanza Cloud SQL, puoi consentire l'accesso dall'indirizzo IP in uscita della replica aggiungendolo come rete autorizzata.
Attiva le connessioni di replica per PostgreSQL 9.6 e versioni precedenti
Se l'istanza primaria non è in esecuzione in Cloud SQL ed esegue PostgreSQL
9.6 o versioni precedenti, devi assicurarti che il file
pg_hba.conf
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
necessari, 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 sull'istanza PostgreSQL primaria trasforma le modifiche WAL in modifiche logiche, utilizzando il plug-in di decodifica selezionato e le trasmette a un consumer (che potrebbe essere anche un'istanza non PostgreSQL). Questo processo in background è chiamato mittente WAL. Il numero di mittenti WAL simultanei che possono essere attivi in un'istanza PostgreSQL è limitato dal flag max_wal_senders. Questo flag è impostato per impostazione predefinita su 10 e il suo limite aumenta linearmente 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 gli slot di replica logica per monitorare quali dati sono stati inviati a quale consumer (e gli slot di replica fisica per le repliche di lettura). Il numero di slot di replica che puoi creare per un'istanza PostgreSQL è limitato dal flag max_replication_slots. Questo flag ha un valore predefinito di 10 e il suo limite aumenta con la memoria dell'istanza Cloud SQL, consentendo da 2 a 8 slot di replica per GB di memoria.
La seguente tabella mostra la relazione tra la memoria massima di un'istanza Cloud SQL e gli slot di replica massimi per l'istanza.
In genere c'è uno slot di replica e un mittente WAL per consumatore, quindi questi
flag devono essere impostati su valori approssimativamente uguali. Tuttavia, PostgreSQL consiglia
di fornire un piccolo buffer per max_wal_senders da gestire quando le connessioni
vengono interrotte in modo imprevisto e vengono effettuate nuove connessioni. La replica fisica, come quella utilizzata dalle repliche di lettura Cloud SQL, utilizza anche uno slot di replica e un mittente WAL, quindi conteggiali quando calcoli il numero di risorse di ciascun tipo di cui hai bisogno.
La replica logica nativa di PostgreSQL e pglogical richiedono l'esecuzione di processi in background aggiuntivi sia sull'istanza principale sia su quella 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 aumenta linearmente 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 di lavoro. 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, le prestazioni potrebbero essere scarse 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, come 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();
| nome | dimensioni | modifica |
|---|---|---|
| 00000001000000000000000A | 16777216 | 2021-08-11 15:16:49+00 |
| 000000010000000000000009 | 16777216 | 2021-08-12 06:23:24+00 |
(2 righe)
postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();
| Utilizzo totale disco WAL |
|---|
| 32 MB |
(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 sull'istanza principale che su 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 sia dell'istanza principale sia di quella di replica.
Se riscontri problemi con questi passaggi, consulta la sezione Risolvere i problemi relativi a pglogical.
Creare un utente con privilegi di replica
Quando utilizzi pglogical, devi disporre di un utente con privilegi di replica e del ruolo cloudsqlsuperuser sia nell'istanza primaria sia in quella di replica. Tutti i comandi
descritti di seguito devono essere eseguiti da questo utente.
Installa l'estensione pglogical
Devi installare l'estensione pglogical sia sull'istanza primaria sia su quella di replica. Sulla primaria, deve essere installato dall'utente di replica (ovvero l'utente che si connette al database).
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 quell'istanza. Sia l'istanza principale che 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, creiamo una tabella fittizia nell'istanza primaria e la compiliamo con alcuni dati da testare:
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 sull'istanza di replica.
Aggiungi la tabella a un set di replica
Per supportare la replica di diversi set di dati in destinazioni diverse, pglogical ha il concetto di set di replica. Possiamo aggiungere la nostra tabella di test al set di repliche predefinito.
SELECT pglogical.replication_set_add_table('default', 'replica_test', true);
Crea la sottoscrizione pglogical
Crea l'abbonamento pglogical sull'istanza di destinazione fornendo i dettagli di connessione all'istanza primaria.
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 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
replica.
Sul server primario, 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 l'abbonamento sulla replica utilizzando
pglogical.drop_subscription('test_sub'). Verifica che lo slot di replica sia
stato eliminato anche sul nodo primario. In caso contrario, i segmenti WAL continuano ad accumularsi sull'istanza di replica.
Per saperne di più sui set di replica, sulla replica parziale dei dati, sulla replica DDL, su altre configurazioni avanzate e limitazioni, consulta la documentazione di pglogical.
Utilizzo delle risorse
L'estensione pglogical esegue più processi in background che vengono conteggiati ai fini del limite di max_worker_processes.
In stato stazionario, esegue un processo "supervisore" quando è abilitato, un processo "gestore" per ogni database PostgreSQL in cui è installata l'estensione (ad esempio, potrebbero essercene D) e un processo "applica" per ogni abbonamento pglogical nell'istanza di replica (ad esempio, potrebbero essercene S).
L'estensione, tuttavia, può generare processi di lavoro aggiuntivi durante l'esecuzione di una
sincronizzazione iniziale e genera effettivamente processi "manager" per ogni database
nell'istanza, ma se il database non ha l'estensione installata, esce immediatamente.
Pertanto, alloca qualche processo worker in più rispetto a quelli necessari in condizioni stabili. I processi di lavoro 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 in modo invisibile o PostgreSQL potrebbe non essere in grado di eseguire
l'elaborazione parallela delle query.
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)
Risolvere 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 l'abbonamento pglogical
Quando crei un abbonamento, pglogical verifica innanzitutto di poter utilizzare i dettagli di connessione per connettersi all'istanza. Tenta prima di creare una
connessione normale 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 che hai fornito siano corretti. Vengono forniti ulteriori dettagli sul motivo per cui PostgreSQL non è riuscito a stabilire una connessione.
Dopo aver creato una connessione normale, 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 ha 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 sull'istanza principale.
L'abbonamento pglogical non è attivo
Una sottoscrizione pglogical potrebbe non essere replicata. Per risolvere il problema, assicurati innanzitutto che sia in esecuzione un processo in background sull'istanza di replica. Esegui una query
pg_stat_activity per verificare che sia in esecuzione un processo pglogical apply. In caso
contrario, controlla i log sul nodo di destinazione. Se visualizzi il messaggio worker
registration failed,, puoi aumentare l'impostazione max_worker_processes.
Poi, assicurati che sia stato creato uno slot di replica sull'istanza principale. Nell'istanza replica, la riga in pglogical.subscription contiene il nome dello slot che il progetto tenta di creare. Nell'istanza primaria puoi eseguire 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
al suggerimento utile HINT: Free one or increase max_replication_slots.
Configura la replica logica nativa di PostgreSQL
A partire da PostgreSQL 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) esaminando le sezioni in Configura l'istanza PostgreSQL. Questa pagina fornisce i passaggi per una prova di fattibilità. Se riscontri problemi durante i passaggi descritti in queste sezioni, consulta la pagina Risolvere i problemi di pglogical. Per saperne di più, consulta la sezione Replica logica nella documentazione di PostgreSQL.
Crea una tabella con i dati da replicare
La replica logica PostgreSQL nativa 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 sull'istanza di replica.
Crea una pubblicazione nell'istanza principale
La replica logica PostgreSQL nativa gestisce editori e abbonati.
Crea una pubblicazione dei dati in native_test:
CREATE PUBLICATION pub FOR TABLE native_test;
Crea una sottoscrizione sull'istanza di replica
Ecco un esempio di creazione di un abbonamento sull'istanza di replica:
CREATE SUBSCRIPTION sub
CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
PUBLICATION pub;
Per creare l'abbonamento sull'istanza di replica è necessario il ruolo
cloudsqlsuperuser. Dopo aver creato l'abbonamento, esegui una query sulla tabella
native_test per verificare che i dati siano visualizzati nell'istanza
di replica.
Sul server primario, puoi eseguire query sulla tabella pg_replication_slots per visualizzare lo
slot di replica creato dalla sottoscrizione.
Esegui la pulizia
Una volta superato il test, rilascia l'abbonamento sulla replica utilizzando DROP
SUBSCRIPTION sub;. Verifica che lo slot di replica sia eliminato anche sul
primario. In caso contrario, i segmenti WAL continuano ad accumularsi nell'istanza principale.
Limitazioni alla 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ò scaricare informazioni sugli abbonamenti perché verifica
se l'utente che si connette dispone delle autorizzazioni di superutente.
Ricevere 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 tua
scelta del plug-in di decodifica. Puoi utilizzare:
wal2json, per trasmettere in streaming le modifiche formattate come JSON oppure
test_decoding, per trasmettere in streaming le modifiche formattate con un formato di testo essenziale
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 allo stream
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 database ed esegui i seguenti 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 di decodifica 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 di decodifica 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 del test, elimina lo slot di replica creato eseguendo il comando:
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 in questa sezione si applicano alle funzionalità di replica logica e decodifica di Cloud SQL per PostgreSQL.
L'estensione
pglogicalnon funziona nelle istanze in cui è abilitata l'applicazione del connettore. Questa limitazione non si applica alle istanze per cui è configurato l'accesso privato ai servizi.Quando ripristini un'istanza con
cloudsql.logical_decodingocloudsql.enable_pglogicalabilitato e che funge attualmente da publisher per la replica logica, devi prima disabilitare la replica in tutte le istanze di destinazione. In caso contrario, il ripristino dell'istanza non va a buon fine e viene visualizzato un errore, ma al momento i dettagli dell'errore non sono visibili.Quando ripristini un backup di un'istanza in cui erano attivati
cloudsql.logical_decodingocloudsql.enable_pglogical(al momento del backup) e lo ripristini in una nuova istanza, lo stato di replica non viene ripristinato nella nuova istanza. In seguito, devi riconfigurare manualmente la replica.Su un'istanza Cloud SQL con una o più repliche di lettura Cloud SQL (utilizzando la replica fisica), se abiliti
cloudsql.logical_decodingocloudsql.enable_pglogical, questi flag vengono abilitati anche sulla replica di lettura.Per Cloud SQL per PostgreSQL versioni 15 e precedenti, le istanze di replica di lettura 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 sostituire l'istanza principale in caso di promozione, i flag logici sono ancora attivati 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 Cloud SQL possono fungere da publisher per la replica logica, se l'istanza principale ha impostato i flag logici. L'abbonato logico può essere un'istanza Cloud SQL o un'istanza esterna. Tuttavia, l'eliminazione di righe e le operazioni di vacuum sull'istanza principale potrebbero eliminare le tuple ancora necessarie per la decodifica logica sulla replica di lettura. In questi casi, lo slot di replica logica sulla replica di lettura viene invalidato per evitare incoerenze.
L'attivazione di
cloudsql.logical_decodingocloudsql.enable_pglogicalsull'istanza principale comporta l'attivazione dei flag su tutte le repliche di lettura e 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 (2) impostare i flag sull'istanza primaria.La disattivazione di
cloudsql.logical_decodingocloudsql.enable_pglogicalnell'istanza principale non comporta la disattivazione dei flag in tutte le repliche di lettura. Per disattivare i flag in tutte le istanze, devi eseguire l'inverso dei passaggi descritti sopra: (1) disattiva i flag nell'istanza primaria e poi (2) disattiva i flag in ogni replica di lettura a turno.