Puoi utilizzare la replica logica e la decodifica in Cloud SQL per PostgreSQL. Questi le funzionalità abilitano flussi di lavoro di replica logica e Change Data Capture (CDC) per i flussi di lavoro.
Per informazioni generali sulla replica, consulta Informazioni sulla replica in Cloud SQL.
Introduzione
Quando PostgreSQL esegue la replica logica, le modifiche trasmesse in flusso vengono estratte dai log WAL mediante la decodifica logica. Lo strumento decodificato sono indipendenti dal formato di archiviazione fisica sottostante. Le modifiche riflettono solo modifiche nei dati a livello 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 dei consumatori dei modifiche in tempo reale.
La replica logica è la funzionalità di punta basata sulla decodifica logica.
A differenza di PostgreSQL, replica fisica che richiede sia l'origine che la destinazione la stessa versione dei database, la replica logica consente la replica Versioni principali di PostgreSQL. La replica logica in Cloud SQL è supportata dal pglogical, disponibile in tutte le versioni PostgreSQL e di replica logica nativa, aggiunta in PostgreSQL 10.
Il formato in cui vengono trasmesse le modifiche può essere configurato con
o plug-in. Ciò consente di avere flessibilità
Change Data Capture (CDC)
(CDC).
Ad esempio, wal2json
consente di trasmettere in modalità flusso tutte le modifiche di un database a un consumer, formattate come
JSON. Cloud SQL supporta il decoder pgoutput integrato,
test_decoding
modulo di contributo e wal2json. Cloud SQL al momento supporta
wal2json varianti dell'output JSON: format-version 1 che codifica l'intera transazione come singolo oggetto JSON e format-version 2 che restituisce un oggetto JSON per comando. Questi plug-in abilitano
in database non PostgreSQL.
Configura l'istanza PostgreSQL
PostgreSQL supporta la decodifica logica scrivendo informazioni aggiuntive nei suoi log write-ahead (WAL).
In Cloud SQL, puoi abilitare questa funzionalità impostando il campo cloudsql.logical_decoding
per on. Questa impostazione è diversa da quella utilizzata in
PostgreSQL standard.
Se modifichi un'istanza PostgreSQL esterna, abilita questa funzionalità
L'impostazione del 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 abilitato impostando cloudsql.enable_pglogical su
on. (Su una VM, sudo apt-get install postgresql-13-pglogical ) e riavvia
per configurare un database.
Se utilizzi pglogical per replicare tra due istanze PostgreSQL, la decodifica logica deve essere abilitata solo sull'istanza principale e non l'istanza di replica (a meno che l'istanza stessa non sia un'istanza principale replicas). Tuttavia, l'estensione pglogical deve essere abilitata su entrambe le istanze. Per esempi di come i termini "principale" e "replica" e le relative significati, vedi Informazioni sulla replica in Cloud SQL.
Attiva connettività di rete
Assicurati che le istanze principali accettino 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 principale. |
| Cloud SQL (IP privato) | Cloud SQL (IP privato) | Se entrambe le istanze si trovano nello stesso progetto Google Cloud, aggiungi
nell'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 Database Migration Service. |
| Cloud SQL | Esterno | Per saperne di più, consulta Configurare le 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 l'app Pagina Istanze Cloud SQL.
Accanto all'indirizzo IP pubblico della replica Cloud SQL, passa il mouse sopra il pulsante Altro info e recupera l'indirizzo IP in uscita. Tieni presente che l'IP in uscita l'indirizzo email non è l'indirizzo IP visualizzato nell'elenco principale della replica in la console Google Cloud.
Se l'istanza di replica non è un'istanza Cloud SQL, consulta documentazione pertinente.
Per saperne di più su come ottenere l'indirizzo IP pubblico di un'istanza, consulta Recuperare l'indirizzo IP in uscita della replica Cloud SQL.
gcloud
Puoi utilizzare questo 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 dalla l'indirizzo IP in uscita della replica la aggiungila 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 e sta eseguendo PostgreSQL
9.6 o versioni precedenti, devi assicurarti che
pg_hba.conf
è impostato per accettare connessioni di replica. Aggiungi il parametro
seguente al file, utilizzando all all per l'iniziale
solo per i test. Per maggiore sicurezza, limita gli utenti e gli indirizzi IP solo a questi
come mostrato in questo esempio:
host replication all all md5
Per ulteriori informazioni, vedi Il file pg_hba.conf.
Crea un utente di replica
Per utilizzare le funzionalità di decodifica logica, devi creare un utente PostgreSQL con
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 si utilizza la decodifica logica, si utilizza un processo in background trasforma le modifiche WAL in modifiche logiche, utilizzando il metodo decodificare un plug-in e li inoltra a un consumatore (che potrebbe essere anche un un'istanza non PostgreSQL). Questo processo in background è chiamato mittente WAL. Il numero di mittenti WAL simultanei che possono essere attivi in un database PostgreSQL è limitata max_wal_senders flag. Per impostazione predefinita, questo flag è 10 e il suo limite cresce linearmente con la memoria dell'istanza Cloud SQL, che consentono 8 mittenti WAL per GB di memoria.
Per garantire che i segmenti WAL non vengano eliminati prima di essere inviati a tutti PostgreSQL utilizza PostgreSQL slot di replica logica per monitorare quali dati sono stati inviati a quale consumatore (e slot di replica fisici per le repliche di lettura). Il numero di gli slot di replica che puoi creare per un'istanza PostgreSQL sono limitati max_replication_slots flag. Questo flag il valore predefinito è 10 e il suo limite aumenta con la memoria del tuo Cloud SQL di replica, 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
dovrebbero essere impostati su valori più o meno uguali. Tuttavia, PostgreSQL consiglia
fornendo a max_wal_senders un piccolo buffer da gestire quando le connessioni
muore inaspettatamente e vengono stabilite nuove connessioni. Replica fisica, come utilizzata da
le repliche di lettura di Cloud SQL, ma utilizza anche uno slot di replica e un mittente WAL, quindi
e quelli per calcolare quante sono
le risorse di cui hai bisogno.
La replica logica nativa di PostgreSQL e pglogical richiedono dei processi in background da eseguire, sia sull'istanza principale che su quella di replica. La di processi in background che possono essere eseguiti è limitato max_worker_processes flag. Il valore predefinito è otto e il suo limite cresce linearmente con la memoria dell'istanza Cloud SQL, consentendo due processi aggiuntivi per GB di memoria. Il numero esatto di worker i processi utilizzati con questi approcci sono illustrati nelle rispettive sezioni.
Se il flag è impostato su un valore troppo basso e la replica non riesce e viene visualizzato un messaggio di errore
worker registration failed nei tuoi log, probabilmente dovrai
aumenta l'impostazione di max_worker_processes.
Tieni presente che i mittenti WAL non vengono conteggiati come processi worker. Lavoratori nati per
le esecuzioni parallele di query contano, 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 parallela delle query.
Utilizzando la funzione pg_ls_waldir (),
puoi determinare l'utilizzo del disco WAL. Questa funzione è limitata a
cloudsqlsuperuser utenti come l'utente amministratore predefinito postgres. Questo
è 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 | 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
Vedi Configura le repliche esterne per ottenere un esempio completo utilizzando la decodifica pglogica e logica.
Configura la replica logica con pglogical
Per configurare la replica logica con pglogical, è necessario abilitare la decodifica logica
sull'istanza principale. Imposta cloudsql.logical_decoding=on su 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
richiede il riavvio dell'istanza principale e di quella di replica.
In caso di problemi con questi passaggi, consulta Risolvi i problemi di pglogical.
Crea un utente con privilegi di replica
È necessario un utente con privilegi di replica
e il ruolo cloudsqlsuperuser su
sia l'istanza principale sia quella di replica quando si utilizza pglogical. Qualsiasi comando
descritti di seguito devono essere eseguiti dallo stesso utente.
Installa l'estensione pglogical
Devi installare l'estensione pglogical sia sull'istanza principale che sulla replica di Compute Engine. Nell'istanza principale, l'utente di replica (ovvero l'utente che si connette il database) devono installarlo.
CREATE EXTENSION pglogical;
Crea un nodo pglogical 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 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 dati da replicare
L'estensione pglogical consente di replicare solo un sottoinsieme di tabelle in un destinazione. Ad esempio, creeremo una tabella fittizia sull'istanza principale e compilarlo 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 set di dati diversi in destinazioni diverse, pglogical ha il concetto di un insieme di replica. Possiamo aggiungere la tabella di test predefinito della replica.
SELECT pglogical.replication_set_add_table('default', 'replica_test', true);
Crea la sottoscrizione pglogical
Crea la sottoscrizione pglogical sull'istanza di destinazione fornendo i dettagli della 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 è "replicante", significa che la configurazione è riuscita. Esegui una query sul
replica_test per garantire che i dati siano stati replicati. Inserisci e modifica
sull'istanza principale e verifica che vengano visualizzati nella replica
in esecuzione in un'istanza Compute Engine.
Nell'istanza principale, esegui una query sulla tabella pg_replication_slots per visualizzare la replica
slot creato dall'abbonamento.
Esegui la pulizia
Dopo l'esito positivo del test, elimina l'abbonamento sulla replica utilizzando
pglogical.drop_subscription('test_sub'). Verifica che lo slot di replica sia
anch'esso caduto nelle primarie. In caso contrario, i segmenti WAL continuano ad accumularsi
l'istanza di replica.
Per ulteriori informazioni su set di replica, replica parziale dei dati, replica DDL altre configurazioni avanzate e limitazioni, consulta documentazione pglogical.
Utilizzo delle risorse
L'estensione pglogical esegue più processi in background che vengono conteggiati ai fini del calcolo
il limite di max_worker_processes.
In stato stabile esegue un "supervisore" una volta abilitato,
"amministratore" per database PostgreSQL che ha installato l'estensione (per
esempio, potrebbero esserci D di questi formati) e uno "apply" processo per pglogical
sull'istanza di replica (ad esempio, potrebbero esserci S di questi).
L'estensione, tuttavia, può generare ulteriori processi worker durante l'esecuzione di
della sincronizzazione iniziale e di fatto genera processi per ogni database
nell'istanza, ma se nel database non è installata l'estensione,
esce immediatamente.
Di conseguenza, assegna un numero limitato di processi worker
richiesta nello stato stabile. I processi worker sono utilizzati da PostgreSQL per
ad esempio l'elaborazione parallela delle query. Se il criterio max_worker_processes è impostato
troppo basso, la replica potrebbe non riuscire in modo invisibile o PostgreSQL potrebbe non essere in grado di
l'elaborazione parallela delle query.
Per riassumere, queste impostazioni sono consigliate:
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 controlla innanzitutto di poter utilizzare
i dettagli della connessione
per connetterti all'istanza. Prova innanzitutto a creare
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 connessioni dall'istanza di replica e assicurati che i dettagli che hai fornito siano corrette. Sono disponibili ulteriori dettagli sul motivo per cui PostgreSQL non è riuscito a stabilire una connessione.
Dopo aver creato una connessione regolare, pglogical cerca di creare una
connessione di replica. In PostgreSQL 9.6 e precedenti, questo tipo di connessione
potrebbe avere una configurazione di autenticazione diversa. Devi aggiornare
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 presenta già le modifiche necessarie.
questo errore si verifica solo quando ti connetti a un'istanza esterna
non è gestito 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 su
l'istanza principale.
La sottoscrizione pglogical non è attiva
La replica di una sottoscrizione pglogical potrebbe non riuscire. Per risolvere questo problema,
per assicurarti che sia in esecuzione
un processo in background sull'istanza di replica. Termine di ricerca
pg_stat_activity per verificare che sia in esecuzione un processo pglogical apply. Se
non è necessario, controlla i log sul nodo di destinazione. Se viene visualizzato il messaggio worker
registration failed,, puoi aumentare l'impostazione di max_worker_processes.
Quindi, assicurati che sia stato creato uno slot di replica nell'istanza principale. Il giorno
di replica, la riga in pglogical.subscription contiene il nome del
slot che la sottoscrizione cerca di creare, e sull'istanza principale puoi eseguire query
pg_replication_slots per verificare che lo slot sia stato creato correttamente.
Se non è stato creato alcuno slot di replica, controlla i log sull'istanza principale.
Un errore di ERROR: logical decoding requires wal_level >= logical implica
che il flag wal_level non era impostato su logical. Risolvi il problema
impostando cloudsql.logical_decoding=on sull'istanza principale se si tratta di un
di Cloud SQL.
In alternativa, se l'istanza è un'istanza esterna, imposta wal_level=logical.
In caso contrario, potresti vedere ERROR: all replication slots are in use, insieme a
l'utile HINT: Free one or increase max_replication_slots.
Configura la replica logica PostgreSQL nativa
A partire da PostgreSQL 10, PostgreSQL supporta la replica logica integrata nativa. A
replica logica nativa, la decodifica logica deve essere abilitata
principale, impostando cloudsql.logical_decoding=on su un ambiente Cloud SQL
o wal_level=logical su un'istanza esterna. Ricorda 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 la tua istanza PostgreSQL. Questa pagina fornisce i passaggi per una proof of concept. Se riscontri problemi mentre segui i passaggi di queste sezioni, vedi Risolvi i problemi di pglogical. Per ulteriori informazioni, consulta Replica logica nella documentazione 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 sul all'istanza e compilarla 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 sull'istanza principale
Deal di replica logica PostgreSQL nativa con publisher e sottoscrittori.
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;
La creazione della sottoscrizione sull'istanza di replica richiede
Ruolo cloudsqlsuperuser. Dopo aver creato la sottoscrizione, esegui una query
Tabella native_test per verificare che i dati siano stati visualizzati nella replica
in esecuzione in un'istanza Compute Engine.
In quella principale, puoi eseguire una query sulla tabella pg_replication_slots per visualizzare
nello slot di replica creato dalla sottoscrizione.
Esegui la pulizia
Una volta esito positivo del test, elimina l'abbonamento sulla replica utilizzando DROP
SUBSCRIPTION sub;. Verifica che lo slot di replica venga rilasciato anche
principale. In caso contrario, i segmenti WAL continueranno ad accumularsi sull'istanza principale.
Limitazioni sulla replica logica PostgreSQL nativa
Accesso alla colonna subconninfo dell'
pg_subscription
tabella di sistema non disponibile.
L'esecuzione di pg_dump non può eseguire il dump delle informazioni sulle sottoscrizioni perché viene controllata
se l'utente che si collega dispone
di autorizzazioni come super user.
Ricevi modifiche WAL decodificate per Change Data Capture (CDC)
Come caso d'uso alternativo per i CDC, la decodifica logica può trasmettere modifiche da un PostgreSQL. Lo strumento standard usato per farlo è pg_recvlogical.
Puoi utilizzare lo strumento pg_recvlogical per creare uno slot di replica e trasmettere
le modifiche monitorate da quell'area. Il formato delle modifiche è determinato dal tuo
il plug-in di decodifica. Puoi utilizzare:
wal2json, per trasmettere in streaming le modifiche nel formato JSON
test_decoding, per trasmettere le modifiche in flusso formattate con un formato di testo semplice
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 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 decoder wal2json, genera un output simile al seguente
viene visualizzata nel primo terminale 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":[]}
Se utilizzi il plug-in decoder test_decoding, ottieni un output simile al
nel primo terminale Cloud Shell:
BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464
Gli ID transazione potrebbero essere diversi.
Esegui la pulizia
Dopo aver completato il test, elimina lo slot di replica creato in esecuzione:
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 alla replica logica e di decodifica di Cloud SQL per PostgreSQL.
Quando ripristini un'istanza che ha
cloudsql.logical_decodingocloudsql.enable_pglogicalattivato e attualmente agisce come publisher Per la replica logica, devi disabilitare la replica in tutte le istanze di destinazione per prima cosa. In caso contrario, il ripristino nell'istanza non riesce e restituisce un errore, ma al momento i dettagli dell'errore non sono visibili.Quando ripristini il backup di un'istanza che aveva
cloudsql.logical_decodingocloudsql.enable_pglogicalsia abilitato (al momento del backup) e lo stanno ripristinando in una nuova istanza, lo stato di replica non viene ripristinato la nuova istanza. Devi riconfigurare la replica manualmente in seguito.In un'istanza Cloud SQL con una o più repliche di lettura di Cloud SQL (utilizzando replica fisica), se abiliti
cloudsql.logical_decodingocloudsql.enable_pglogical, questi flag sono abilitati anche nella cartella replica.Le istanze di replica di lettura di Cloud SQL non possono agire da publisher per perché PostgreSQL non supporta la decodifica logica in lettura replicas. Tuttavia, i flag sono abilitati sull'istanza della replica di lettura garantire che possa sostituire quella principale se e quando promosso.
Attivando
cloudsql.logical_decodingocloudsql.enable_pglogicalsulla principale fa sì che i flag siano abilitati su tutte le repliche di lettura Ciò fa sì che le repliche principali e di lettura vengano riavviate successione. Per evitare questa situazione e controllare quando ogni istanza viene riavviata, puoi (1) impostare uno dopo l'altro i flag su ciascuna replica di lettura e e (2) impostare i flag sull'istanza principale.Disabilitando
cloudsql.logical_decodingocloudsql.enable_pglogicalnella istanza principale non causa la disabilitazione dei flag su tutte le istanze replicas. Per disabilitare i flag tra le istanze, devi eseguire la invertendo i passaggi descritti sopra: (1) disabilita i flag sull'istanza principale e poi (2) disabilitare i flag su ogni replica di lettura a loro volta.