Puoi utilizzare le funzionalità di replica e decodifica logica in Cloud SQL per PostgreSQL. Queste funzionalità consentono flussi di lavoro di replica logica e flussi di lavoro CDC (Change Data Capture).
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 di SQL, in termini di INSERT, UPDATE ed DELETE. Questa indipendenza dal livello di archiviazione offre una grande flessibilità e consente un'ampia gamma di funzionalità da parte degli utenti 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 abbiano la stessa versione, la replica logica consente la replica su 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 le modifiche vengono trasmesse in streaming può essere configurato con plug-in diversi. Ciò consente di utilizzare architetture
Change Data Capture (CDC) flessibili.
Ad esempio, l'estensione wal2json consente di inviare un flusso di tutte le modifiche di un database a un consumer, nel formato JSON. Cloud SQL supporta il decodificatore pgoutput integrato, il modulo di contributo test_decoding e wal2json. Cloud SQL attualmente supporta entrambe
wal2json le varianti 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 su database non PostgreSQL.
Configura l'istanza PostgreSQL
PostgreSQL supporta la decodifica logica scrivendo informazioni aggiuntive nel relativo log write-ahead (WAL).
In Cloud SQL, puoi abilitare questa funzionalità impostando il flag cloudsql.logical_decoding su on. Questa impostazione è diversa da quella utilizzata nello standard PostgreSQL.
Se modifichi un'istanza PostgreSQL esterna, puoi abilitare 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 è 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 replicare 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 quella principale per altre repliche). Tuttavia, l'estensione pglogical deve essere abilitata in entrambe le istanze. Per esempi di utilizzo dei termini "principale" e "replica" e dei relativi significati, consulta Informazioni sulla replica in Cloud SQL.
Abilita 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 della replica principale. |
| Cloud SQL (IP privato) | Cloud SQL (IP privato) | Se entrambe le istanze si trovano nello stesso progetto Google Cloud, 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:
|
| Esterna | Cloud SQL | Puoi utilizzare Database Migration Service. |
| Cloud SQL | Esterna | Per saperne di più, consulta Configurare le repliche esterne. |
Recupera 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, esegui i passaggi seguenti per recuperarne l'indirizzo IP in uscita.
Console
Apri la pagina Istanze Cloud SQL.
Accanto all'indirizzo IP pubblico della replica Cloud SQL, passa il mouse sopra la descrizione dello strumento Altre 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 Cloud.
Se l'istanza di replica non è un'istanza Cloud SQL, fai riferimento alla 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 principale è un'istanza Cloud SQL, puoi consentire l'accesso dall'indirizzo IP in uscita della replica aggiungendola 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 connessioni di replica. Aggiungi la seguente riga al file, utilizzando all all solo per i test iniziali. Per maggiore sicurezza, limita gli utenti e gli indirizzi IP solo a quelli necessari, come in questo esempio:
host replication all all md5
Per maggiori informazioni, consulta la sezione 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 inoltra a un consumer (che potrebbe anche essere un'istanza non PostgreSQL). Questa procedura in background è chiamata mittente WAL. 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 della tua istanza Cloud SQL, consentendo 8 mittenti WAL per GB di memoria.
Per garantire che i segmenti WAL non vengano ignorati prima di essere inviati a tutti i consumer, PostgreSQL utilizza slot di replica logici per monitorare i dati inviati a un consumer (e gli 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 cresce con la memoria dell'istanza Cloud SQL, consentendo da 2 a 8 slot di replica per GB di memoria.
La tabella seguente mostra la relazione tra la memoria massima di un'istanza Cloud SQL e il numero massimo di slot di replica per l'istanza.
In genere è presente uno slot di replica e un mittente WAL per consumer, quindi questi flag dovrebbero essere impostati su valori più o meno uguali. Tuttavia, PostgreSQL consiglia di fornire un buffer piccolo per max_wal_senders da gestire quando le connessioni si arrestano inaspettatamente e vengono create nuove connessioni. La replica fisica, come utilizzata dalle repliche di lettura di Cloud SQL, utilizza anche uno slot di replica e un mittente WAL, pertanto tienine conto quando calcoli il numero di risorse di cui hai bisogno per ciascuna risorsa.
La replica logica nativa PostgreSQL e pglogical richiedono ulteriori processi in background per l'esecuzione, sia nell'istanza primaria che in 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 suo 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 il flag è impostato su un valore troppo basso e la replica non riesce e viene visualizzato il messaggio di errore worker registration failed nei tuoi log, probabilmente dovrai 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 a
utenti cloudsqlsuperuser, ad esempio l'utente amministratore predefinito postgres. Questa funzione è disponibile solo in PostgreSQL 10 e versioni successive.
Per calcolare l'utilizzo totale del disco WAL:
postgres=> select * from pg_ls_waldir();
| nome | dimensioni | modifica |
|---|---|---|
| 00000001000000000000000A | 16777216 | 11-08-2021 15:16:49+00 |
| 000000010000000000000009 | 16777216 | 12-08-2021 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 di repliche esterne per un esempio completo utilizzando la decodifica logica e 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 sia 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 di entrambe le istanze principali e di replica.
Se riscontri problemi con questi passaggi, consulta Risoluzione dei problemi legati a questi problemi.
Crea un utente con privilegi di replica
Quando utilizzi pglogical, è necessario un utente con privilegi di replica e il ruolo cloudsqlsuperuser sia sull'istanza principale sia su quella di replica. Tutti i comandi descritti di seguito devono essere eseguiti da quell'utente.
Installa l'estensione pglogical
Devi installare l'estensione pglogical sull'istanza principale e di replica. Nell'istanza principale, l'utente della replica (ovvero l'utente che si connette al database) deve installarla.
CREATE EXTENSION pglogical;
Crea un nodo pglogico su ogni istanza
Un nodo pglogical rappresenta un'istanza PostgreSQL fisica e archivia i dettagli della connessione per quell'istanza. Sia l'istanza principale sia l'istanza 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 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 completeremo 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 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 offre 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 visualizzato è "replica", significa che 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.
Nel file primario, esegui una query nella tabella pg_replication_slots per vedere lo slot di replica creato dalla sottoscrizione.
esegui la pulizia
Se il test ha esito positivo, elimina la sottoscrizione nella replica utilizzando
pglogical.drop_subscription('test_sub'). Verifica che lo slot di replica venga eliminato anche sull'unità principale. In caso contrario, i segmenti WAL continueranno ad accumularsi
nell'istanza di replica.
Per ulteriori informazioni su set di replica, replica parziale dei dati, replica DDL e altre configurazioni e limitazioni avanzate, 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 stabile, esegue un processo "supervisore" se abilitato, un processo "gestore" per ogni database PostgreSQL che ha installato l'estensione (ad esempio, potrebbe essere presente D di questi) e un processo "apply" per abbonamento pglogical sull'istanza di replica (ad esempio, potrebbero essercene S).
L'estensione, tuttavia, può generare ulteriori processi worker durante l'esecuzione di una sincronizzazione iniziale e di fatto genera processi "manager" per ogni database nell'istanza. Tuttavia, se il database non ha l'estensione installata, esce immediatamente.
Alloca quindi più processi worker
di quanto ne abbia bisogno in uno stato stazionario. I processi worker sono utilizzati da PostgreSQL per
altri scopi, come l'elaborazione di query parallela. Se il valore di max_worker_processes è troppo basso, la replica potrebbe non riuscire automaticamente oppure PostgreSQL potrebbe non essere in grado di eseguire l'elaborazione delle query parallela.
In sintesi, sono consigliate 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)
Risoluzione dei problemi pglogical
Impossibile creare l'estensione pglogical
Durante il tentativo di 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 crea una sottoscrizione, pglogical verifica innanzitutto di poter utilizzare i dettagli della connessione per connettersi all'istanza. Innanzitutto prova a creare una connessione normale e, se l'operazione non va a buon fine, si verifica un errore: ERROR: could not
connect to the postgresql server.
Se si verifica questo errore, assicurati che l'istanza principale sia configurata in modo da consentire le connessioni dall'istanza di replica e assicurati che i dettagli della 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. Devi aggiornare il file pg_hba.conf nell'istanza di origine se visualizzi questo errore: ERROR: could
not connect to the postgresql server in replication mode.
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 il valore di max_wal_senders per l'istanza principale.
l'abbonamento a pglogical non è attivo
La replica di un abbonamento pglogical potrebbe non riuscire. Per risolvere questo problema, assicurati prima che sia in esecuzione un processo in background sull'istanza di replica. 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 viene visualizzato 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 della replica, la riga in pglogical.subscription contiene il nome dello slot che l'abbonamento tenta di creare e nell'istanza principale puoi eseguire una query su pg_replication_slots per verificare che lo slot sia stato creato correttamente.
Se non è stato creato alcun 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 nell'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 nativa PostgreSQL
A partire da PostgreSQL 10, PostgreSQL supporta la replica logica integrata nativa. Per configurare la replica logica nativa, è necessario abilitare la decodifica logica nell'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 Configurare l'istanza PostgreSQL. Questa pagina fornisce i passaggi per una proof of concept. Se riscontri problemi durante l'esecuzione dei passaggi in queste sezioni, consulta Risoluzione dei problemi di pglogical. Per ulteriori informazioni, consulta Replica logica nella documentazione di PostgreSQL.
Crea una tabella con dati da replicare
La replica logica nativa PostgreSQL supporta un intero database o solo singole tabelle. Ad esempio, creeremo una tabella fittizia nell'istanza principale e la completeremo 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
Deal di replica logica nativa PostgreSQL con publisher e abbonati.
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 sull'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 nella tabella native_test per verificare che i dati siano stati visualizzati nell'istanza di replica.
Nell'istanza principale, puoi eseguire una query sulla tabella pg_replication_slots per visualizzare lo slot di replica creato dalla sottoscrizione.
esegui la pulizia
Se il test ha esito positivo, elimina l'abbonamento nella replica utilizzando DROP
SUBSCRIPTION sub;. Verifica che lo slot di replica sia eliminato anche sull'unità principale. In caso contrario, i segmenti WAL continueranno ad accumularsi sull'istanza principale.
Limitazioni alla replica logica nativa 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 come super user.
Ricezione delle modifiche WAL decodificate per Change Data Capture (CDC)
Come caso d'uso alternativo di CDC, la decodifica logica può trasmettere le modifiche in streaming da un'istanza PostgreSQL. Lo strumento standard utilizzato per farlo è pg_recvlogical.
Puoi utilizzare lo strumento pg_recvlogical per creare uno slot di replica e trasmettere le modifiche monitorate da quello slot. Il formato delle modifiche è determinato dalla scelta
del plug-in di decodifica. Puoi utilizzare:
wal2json per trasmettere le modifiche in formato JSON o
test_decoding, per trasmettere in streaming 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 -
Mentre ti trovi 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 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 di decodificatore 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
Dopo aver completato il 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 in questa sezione si applicano alle funzionalità di replica logica e decodifica di Cloud SQL per PostgreSQL.
Quando ripristini un'istanza per cui sono abilitati
cloudsql.logical_decodingocloudsql.enable_pglogicale che sta attualmente fungendo da publisher per la replica logica, devi prima disabilitare la replica in tutte le istanze di destinazione. In caso contrario, il ripristino nell'istanza non va a buon fine e viene mostrato un errore, ma al momento i dettagli dell'errore non sono visibili.Quando ripristini il backup di un'istanza in cui è abilitato
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. Devi riconfigurare la replica manualmente dopo.In un'istanza Cloud SQL con una o più repliche di lettura Cloud SQL (mediante la replica fisica), se abiliti
cloudsql.logical_decodingocloudsql.enable_pglogical, questi flag vengono abilitati anche nella replica di lettura.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 nelle repliche di lettura. Tuttavia, i flag sono abilitati nell'istanza della replica di lettura per garantire che possa fungere da sostituzione dell'istanza principale se e quando viene promossa.
L'abilitazione di
cloudsql.logical_decodingocloudsql.enable_pglogicalsull'istanza principale comporta l'abilitazione dei flag su tutte le repliche di lettura e, di conseguenza, le repliche principali e di lettura vengono riavviate in successione. Per evitare questa situazione e questo controllo al momento del riavvio di ogni istanza, puoi (1) impostare i flag su ogni replica di lettura a turno e poi (2) impostare i flag sull'istanza principale.La disabilitazione di
cloudsql.logical_decodingocloudsql.enable_pglogicalnell'istanza principale non determina la disabilitazione dei flag su tutte le repliche di lettura. Per disabilitare i flag in tutte le istanze, devi eseguire l'inverso dei passaggi descritti sopra: (1) disabilitare i flag nell'istanza principale e (2) disabilitare i flag su ogni replica di lettura.