Panoramica
Database Migration Service supporta migrazioni continue dai database di origine ai database di destinazione AlloyDB.
I database di origine supportati per PostgreSQL includono:
- Amazon RDS 9.6.10 e versioni successive, 10.5 e versioni successive, 11.1 e versioni successive, 12, 13, 14, 15
- Amazon Aurora 10.11 e versioni successive, 11.6 e versioni successive, 12.4 e versioni successive, 13.3 e versioni successive, 14, 15
- PostgreSQL autogestito (on-premise o su qualsiasi VM cloud di tua proprietà) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15
- Cloud SQL 9.6, 10, 11, 12, 13, 14, 15
Per configurare l'origine è necessario configurare sia l'istanza di origine che i database di origine sottostanti.
Configura l'istanza di origine
Per configurare l'istanza di origine, segui i passaggi riportati di seguito:
- L'istanza di origine deve includere il database
postgres
. Se non disponi di questo database, crealo. - Installa il pacchetto
pglogical
sull'istanza di origine e assicurati che sia incluso nella variabileshared_preload_libraries
.- Per il tuo ambiente, consulta Installa il pacchetto
pglogical
sull'istanza di origine.
- Per il tuo ambiente, consulta Installa il pacchetto
Configura i database di origine
Database Migration Service esegue la migrazione di tutti i database nell'istanza di origine, con esclusione dei seguenti database:
- Per le origini on-premise: database modello
template0
etemplate1
- Per le origini Amazon RDS:
template0
,template1
erdsadmin
- Per le origini Cloud SQL: database modello
template0
etemplate1
Esegui le operazioni indicate di seguito su ogni database nell'istanza di origine non menzionato sopra:
Solo per le origini PostgreSQL versione 9.4, installa le seguenti estensioni
pglogical
su ogni database dell'istanza di origine:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
Per tutte le altre versioni, installa solo l'estensione
pglogical
su ogni database nell'istanza di origine:CREATE EXTENSION IF NOT EXISTS pglogical
.Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione dello snapshot iniziale e delle istruzioni
INSERT
durante la fase CDC. Devi eseguire manualmente la migrazione delle istruzioniUPDATE
eDELETE
.L'USER che stai utilizzando per connetterti all'istanza di origine (che verrà configurato come utente nella pagina Profili di connessione) deve disporre di determinati privilegi su ogni database di cui viene eseguita la migrazione e sul database
postgres
predefinito. Puoi creare un nuovo utente o riutilizzarne uno esistente. Per impostare questi privilegi, connettiti all'istanza ed esegui i seguenti comandi:GRANT USAGE on SCHEMA SCHEMA to USER
su tutti gli schemi (a parte lo schema di informazioni e gli schemi che iniziano con "pg_") in ogni database di cui eseguire la migrazione.GRANT USAGE on SCHEMA pglogical to PUBLIC;
su ogni database di cui eseguire la migrazione.GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER
su tutti i database per recuperare le informazioni di replica dai database di origine.GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER
su tutti gli schemi (a parte lo schema di informazioni e gli schemi che iniziano con "pg_") in ogni database di cui eseguire la migrazione.GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER
su tutti gli schemi (a parte lo schema di informazioni e gli schemi che iniziano con "pg_") in ogni database di cui eseguire la migrazione.- Se l'origine è Amazon RDS, esegui il seguente comando:
GRANT rds_replication to USER
- Se l'origine non è Amazon RDS, esegui il seguente comando:
- Ruolo
ALTER USER USER with REPLICATION
- Ruolo
Installa il pacchetto pglogical
sull'istanza di origine
Questa sezione descrive come configurare il pacchetto pglogical
,
inclusa la configurazione per i parametri max_replication_slots
,
max_wal_senders
e max_worker_processes
.
Puoi anche ottenere i valori corretti per questi parametri
eseguendo un test del job di migrazione quando lo crei.
Durante questo test, Database Migration Service può verificare le impostazioni e suggerire i valori corretti.
PostgreSQL on-premise o autogestito
- Installa il pacchetto pglogical sul server.
- Connettiti all'istanza e imposta i seguenti parametri, se necessario:
shared_preload_libraries
deve includerepglogical
.Per impostare questo parametro, esegui il comando
ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';
.Imposta
wal_level
sulogical
.Per impostare questo parametro, esegui il comando
ALTER SYSTEM SET wal_level = 'logical';
.Imposta
wal_sender_timeout
su0
.Per impostare questo parametro, esegui il comando
ALTER SYSTEM SET wal_sender_timeout = 0;
, dove0
disattiva il meccanismo di timeout utilizzato per terminare le connessioni di replica inattive.max_replication_slots definisce il numero massimo di slot di replica che l'istanza di origine può supportare. Deve essere impostato su almeno il numero di abbonamenti che si prevede di collegare, più alcune riserve per la sincronizzazione della tabella.
Database Migration Service richiede uno slot per ogni database di cui viene eseguita la migrazione (ovvero tutti i database nell'istanza di origine).
Ad esempio, se nell'istanza di origine sono presenti 5 database e sono stati creati 2 job di migrazione per l'origine, il numero di slot di replica deve essere almeno 5 * 2 = 10, più il numero di slot di replica già utilizzati. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati adeguate, assicurati di aumentare il numero di slot di replica e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.
Per impostare questo parametro, esegui il comando
ALTER SYSTEM SET max_replication_slots = #;
, dove # rappresenta il numero massimo di slot di replica.max_wal_senders debe essere impostato su un valore almeno pari a
max_replication_slots
, più il numero di mittenti già utilizzati nell'istanza.Ad esempio, se il parametro
Per impostare questo parametro, esegui il comandomax_replication_slots
è impostato su10
e utilizzi già due mittenti, il numero di processi di mittenti WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare le impostazioni di parallelismo del dump dei dati regolate, assicurati di aumentare il numero di mittenti e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.ALTER SYSTEM SET max_wal_senders = #;
, dove # rappresenta il numero di processi di mittenti WAL in esecuzione contemporaneamente.max_worker_processes deve essere impostato su un valore almeno pari al numero di database di cui Database Migration Service eseguirà la migrazione (ovvero tutti i database dell'istanza di origine), più il numero di
max_worker_processes
già utilizzati nell'istanza.Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati adeguate, assicurati di aumentare il numero di processi worker e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.
Per impostare questo parametro, esegui il comando
ALTER SYSTEM SET max_worker_processes = #;
, dove # rappresenta il numero di database di cui verrà eseguita la migrazione.
- Per applicare le modifiche alla configurazione, riavvia l'istanza di origine.
Amazon RDS PostgreSQL
- Installa l'estensione
pglogical
sul database di origine. Per ulteriori informazioni, consulta Utilizzo delle estensioni PostgreSQL con Amazon RDS per PostgreSQL nella documentazione di Amazon RDS. Configura l'istanza di origine utilizzando gruppi di parametri.
- Crea un nuovo gruppo di parametri. Nel gruppo di parametri:
- Assicurati che il parametro
shared_preload_libraries
includapglogical
. - Imposta il parametro
rds.logical_replication
su1
. In questo modo, verranno attivati i log WAL a livello logico. - Imposta il parametro
wal_sender_timeout
su 0. Verrà disattivato il meccanismo di timeout utilizzato per terminare le connessioni di replica inattive. Imposta il parametro max_replication_slots. Questo parametro definisce il numero massimo di slot di replica che l'istanza di origine può supportare. Deve essere impostato su almeno il numero di abbonamenti che si prevede di collegare, più alcune riserve per la sincronizzazione delle tabelle.
Database Migration Service richiede uno slot per ogni database di cui viene eseguita la migrazione (ovvero tutti i database nell'istanza di origine).
Ad esempio, se nell'istanza di origine sono presenti 5 database e verranno creati 2 job di migrazione per l'origine, il numero di slot di replica deve essere almeno 5 * 2 = 10, oltre al numero di slot di replica già utilizzati. Se prevedi di utilizzare le impostazioni di parallelismo del dump dei dati regolate, assicurati di aumentare il numero di slot di replica e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.
Il valore predefinito di questo parametro è 10.
Imposta il parametro max_wal_senders su un valore almeno pari a
max_replication_slots
, più il numero di mittenti già utilizzati nell'istanza.Ad esempio, se il parametro
max_replication_slots
è impostato su10
e utilizzi già due mittenti, il numero di processi di mittenti WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati regolate, assicurati di aumentare il numero di mittenti e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.Il valore predefinito di questo parametro è 10.
Imposta il parametro di origine max_worker_processes su almeno lo stesso numero di database di cui verrà eseguita la migrazione da parte di Database Migration Service (ovvero tutti i database nell'istanza di origine), oltre al numero di
max_worker_processes
già utilizzati nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati adeguate, assicurati di aumentare il numero di processi worker e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.Il valore predefinito di questo parametro è 8.
Collega il gruppo di parametri all'istanza. Se stai creando una nuova istanza, puoi trovare questa opzione in Configurazione aggiuntiva. In caso contrario, modifica l'istanza per allegare il gruppo di parametri.
Per applicare le modifiche alla configurazione, riavvia l'istanza di origine.
Cloud SQL per PostgreSQL
Abilita la replica logica e la decodifica per il database di origine configurando i seguenti flag.
- Imposta i flag
cloudsql.logical_decoding
ecloudsql.enable_pglogical
suon
. Imposta il flag max_replication_slots. Questo flag definisce il numero massimo di slot di replica che l'istanza di origine può supportare. Deve essere impostato su almeno il numero di abbonamenti che si prevede di collegare, più alcune riserve per la sincronizzazione delle tabelle.
Database Migration Service richiede uno slot per ogni database di cui viene eseguita la migrazione (ovvero tutti i database nell'istanza di origine).
Ad esempio, se nell'istanza di origine sono presenti 5 database e verranno creati 2 job di migrazione per l'origine, il numero di slot di replica deve essere almeno 5 * 2 = 10, oltre al numero di slot di replica già utilizzati. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati adeguate, assicurati di aumentare il numero di slot di replica e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.
Il valore predefinito di questo flag è 10.
Imposta il flag max_wal_senders su un valore almeno pari a
max_replication_slots
, più il numero di mittenti già utilizzati nell'istanza.Ad esempio, se il flag
max_replication_slots
è impostato su10
e utilizzi già due mittenti, il numero di processi di mittenti WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati adeguate, assicurati di aumentare il numero di mittenti e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.Il valore predefinito di questo flag è 10.
Imposta il flag di origine max_worker_processes su almeno lo stesso numero di database di cui eseguirà la migrazione Database Migration Service (ovvero tutti i database nell'istanza di origine), più il numero di
max_worker_processes
già utilizzato nell'istanza. Se prevedi di utilizzare le impostazioni di parallelismo del dump dei dati aggiustato, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker).Il valore predefinito di questo flag è 8.
- Riavvia l'istanza di origine in modo che le modifiche alla configurazione apportate ai flag vengano applicate.
Attivare il monitoraggio del ritardo di replica per la versione PostgreSQL precedente alla 9.6
Se esegui la migrazione da una versione di PostgreSQL precedente alla 9.6, la metrica del ritardo di replica non è disponibile per impostazione predefinita. Esistono tre alternative che consentono di monitorare questa metrica per garantire un tempo di inattività minimo durante la promozione del database:
Opzione 1: consenti a Database Migration Service di monitorare il ritardo della replica concedendo l'accesso a una query specifica. Utilizzando un utente con il privilegio
SUPERUSER
, svolgi i seguenti passaggi:Definisci la seguente funzione per consentire a Database Migration Service di eseguire query sul ritardo della replica.
CREATE OR REPLACE FUNCTION pg_stat_replication_user() RETURNS TABLE ( pid integer , usesysid oid , username name , application_name text , client_addr inet , client_hostname text , client_port integer , backend_start timestamp with time zone , backend_xmin xid , state text , sent_location pg_lsn , write_location pg_lsn , flush_location pg_lsn , replay_location pg_lsn , sync_priority integer , sync_state text ) LANGUAGE SQL SECURITY DEFINER AS $$ SELECT * FROM pg_catalog.pg_stat_replication; $$;
Concedi l'autorizzazione
EXECUTE
a USER eseguendo i seguenti comandi:REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};
Opzione 2: concedi il privilegio
SUPERUSER
direttamente al USER utilizzato per connetterti all'istanza di origine. In questo modo, Database Migration Service potrà leggere direttamente il ritardo nella replica.Opzione 3: monitora il ritardo di replica in modo indipendente utilizzando la seguente query:
SELECT current_timestamp, application_name, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag, pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag FROM pg_stat_replication WHERE application_name like 'cloudsql%';
In questa opzione, il servizio di migrazione del database non riflette la metrica del ritardo di replica nei grafici o nelle risposte dell'API.