Configura l'origine

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

Panoramica

Database Migration Service supporta migrazioni continue dai database di origine ai database Cloud SQL di destinazione.

I database di origine supportati per PostgreSQL includono:

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17, 18.
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16, 17, 18.
• PostgreSQL autogestito (on-premise o su qualsiasi VM cloud di cui hai il controllo totale) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17, 18.
• Cloud SQL per PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17, 18.
• Database di Microsoft Azure per il server flessibile PostgreSQL: 11+

Per configurare l'origine è necessario configurare sia l'istanza di origine che i database di origine sottostanti.

Configurare l'istanza di origine

Per configurare l'istanza di origine:

1. Per le origini Cloud SQL: se esegui la migrazione da un'istanza Cloud SQL che utilizza una connessione IP privato a un'istanza Cloud SQL che utilizza un intervallo di indirizzi IP non RFC 1918, aggiungi l'intervallo non RFC 1918 alla configurazione di rete dell'istanza Cloud SQL di origine. Consulta Configurare le reti autorizzate nella documentazione di Cloud SQL.
2. L'istanza di origine deve includere il database postgres. Se non hai questo database, crealo.

3. Installa il pacchetto pglogical sull'istanza di origine e assicurati che sia incluso nella variabile shared_preload_libraries. Consulta Installare il pglogical pacchetto sull'istanza di origine per il tuo ambiente.

4. Verifica le estensioni nell'istanza di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da Cloud SQL. La presenza di queste estensioni non blocca la migrazione, ma per garantire un processo di migrazione senza problemi, verifica che i tuoi oggetti o applicazioni non facciano riferimento a estensioni non supportate. Ti consigliamo di rimuovere queste estensioni e i riferimenti dal database di origine prima di procedere.

5. Per le origini che utilizzano l'estensione pg_cron: L'estensione pg_cron (o qualsiasi impostazione cron associata all'estensione) non viene migrata da Database Migration Service, ma è supportata nelle destinazioni Cloud SQL per PostgreSQL. Se utilizzi l'estensione pg_cron nei database di origine, puoi reinstallarla sull'istanza di destinazione al termine della migrazione.

Configurare 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 PostgreSQL on-premise: database modello template0 e template1
• Per le origini Amazon RDS: template0, template1 e rdsadmin
• Per le origini Cloud SQL: database modello template0 e template1
• Per le origini Microsoft Azure: azure_maintenance, azure_sys, template0, template1

Esegui le operazioni indicate di seguito su ogni database nell'istanza di origine non menzionato sopra:

1. Solo per le origini PostgreSQL versione 9.4, installa le seguenti pglogical estensioni su ogni database nell'istanza di origine:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. Per tutte le altre versioni, installa solo l'estensione pglogical su ogni database nell'istanza di origine: CREATE EXTENSION IF NOT EXISTS pglogical.

3. Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione degli snapshot iniziali e delle istruzioni INSERT durante la fase CDC. Devi eseguire la migrazione manuale delle istruzioni UPDATE e DELETE.

   Consulta Debugging e altri strumenti per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie. Per ogni tabella di database che non ha una chiave primaria e non fa parte dei database di cui non viene eseguita la migrazione, devi modificare la tabella in modo che abbia una chiave primaria o seguire questa procedura. Per le tabelle senza chiavi primarie, viene eseguita la migrazione solo dello snapshot iniziale e delle istruzioni INSERT.

4. 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:

   1. 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.
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; su ogni database di cui eseguire la migrazione.
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER su tutti i database per recuperare le informazioni di replica dai database di origine.
   4. 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.
   5. 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.
   6. Se l'origine è Amazon RDS, esegui il seguente comando:
      1. GRANT rds_replication to USER
   7. Se l'origine non è Amazon RDS, esegui il seguente comando:
      1. ALTER USER USER with REPLICATION ruolo

Installare il pacchetto pglogical sull'istanza di origine

Questa sezione descrive come configurare il pacchetto pglogical e i parametri applicabili, a seconda dell'istanza di origine.

Nota: puoi ottenere i valori corretti per questi parametri eseguendo un test del job di migrazione quando crei il job di migrazione. Durante questo test, Database Migration Service può verificare le impostazioni e suggerire i valori corretti.

PostgreSQL on-premise o autogestito

1. Installa il pacchetto pglogical sul server.
2. Connettiti all'istanza e imposta i seguenti parametri, se necessario:

   • shared_preload_libraries deve includere pglogical.

     Per impostare questo parametro, esegui il comando ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';.

     Per ottenere le librerie esistenti per l'istanza, esegui il comando show shared_preload_libraries.

   • Imposta wal_level su logical.

     Per impostare questo parametro, esegui il comando ALTER SYSTEM SET wal_level = 'logical';.

   • Imposta wal_sender_timeout su 0.

     Per impostare questo parametro, esegui il comando ALTER SYSTEM SET wal_sender_timeout = 0;, dove 0 disabilita 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 almeno sul numero di abbonamenti che si prevede di connettere, 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 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 di dump dei dati modificate, assicurati di aumentare il numero di slot di replica e verificare 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 deve essere impostato a un valore almeno pari a max_replication_slots, più il numero di sender già utilizzati nell'istanza.

     Ad esempio, se il parametro max_replication_slots è impostato su 10 e utilizzi già 2 sender, il numero di processi sender WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di sender 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_wal_senders = #;, dove # rappresenta il numero di processi sender WAL in esecuzione contemporaneamente.

   • max_worker_processes deve essere impostato a un valore almeno pari al numero di database di cui Database Migration Service eseguirà la migrazione (ovvero tutti i database nell'istanza di origine), più il numero di max_worker_processes già utilizzati nell'istanza.

     Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di processi worker e verificare 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.

   I parametri che stai impostando in questo passaggio si applicano a un server di database PostgreSQL in esecuzione. Puoi anche rendere permanenti queste modifiche aggiungendo le seguenti righe di codice al file postgresql.conf:

   • shared_preload_libraries = 'pglogical';
   • wal_level = 'logical';
   • wal_sender_timeout = 0;
   • max_replication_slots = #;
   • max_wal_senders = #;
   • max_worker_processes = #;
3. Per applicare le modifiche alla configurazione, riavvia l'istanza di origine.

Database di Microsoft Azure per PostgreSQL

Per configurare l'origine Database di Microsoft Azure per PostgreSQL:

1. Installa il pacchetto pglogical sul server.

2. Solo per le origini PostgreSQL versione 9.4, installa le seguenti pglogical estensioni su ogni database nell'istanza di origine:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

3. Per tutte le altre versioni, installa l'estensione pglogical su ogni database nell'istanza di origine: CREATE EXTENSION IF NOT EXISTS pglogical.

4. Configura i parametri del server richiesti sull'origine utilizzando il portale di Microsoft Azure. Per saperne di più, consulta Configurare i parametri del server in Database di Azure per PostgreSQL e Parametri del server in Database di Azure per PostgreSQL nella documentazione di Microsoft.

   Configura i seguenti parametri:

   • Imposta shared_preload_libraries in modo che includa pglogical.
   • Imposta azure.extensions in modo che includa pglogical.
   • Imposta wal_level su logical.

   • Imposta max_replication_slots almeno sul numero di abbonamenti che si prevede di connettere, più alcune riserve per la sincronizzazione delle tabelle.

     Il parametro max_replication_slots definisce il numero massimo di slot di replica che l'istanza di origine può supportare.

     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 di dump dei dati modificate, assicurati di aumentare il numero di slot di replica e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

   • Imposta max_wal_senders a un valore almeno pari a max_replication_slots, più il numero di sender già utilizzati nell'istanza.

     Ad esempio, se il parametro max_replication_slots è impostato su 10 e utilizzi già 2 sender, il numero di processi sender WAL in esecuzione contemporaneamente sarà 10 + 2 = 12.

     Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di sender e verifica la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

   • Imposta max_worker_processes a un valore almeno pari al numero di database di cui Database Migration Service eseguirà la migrazione (ovvero tutti i database nell'istanza di origine), più il numero di max_worker_processes già utilizzati nell'istanza.

     Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di processi worker e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

5. Controlla il valore dell'impostazione require_secure_transport.

   Per impostazione predefinita, i database di Microsoft Azure richiedono la crittografia SSL/TLS per tutte le connessioni in entrata. A seconda del valore di require_secure_transport, utilizza una delle seguenti impostazioni di crittografia quando crei il profilo di connessione di origine:

   • Se require_secure_transport è impostato su on, seleziona Basic, TLS o mTLS.
   • Se require_secure_transport è impostato su off, seleziona Nessuno.
6. Per applicare le modifiche alla configurazione, riavvia l'istanza di origine.

Amazon RDS PostgreSQL

1. Installa l'estensione pglogical sul database di origine.

   Per saperne di più, consulta Utilizzare le estensioni PostgreSQL con Amazon RDS per PostgreSQL nella documentazione di Amazon RDS.

2. Configura l'istanza di origine utilizzando i gruppi di parametri.

   1. Crea un nuovo gruppo di parametri. Nel gruppo di parametri:
   • Assicurati che il parametro shared_preload_libraries includa pglogical.
   • Imposta il parametro rds.logical_replication su 1. In questo modo, i log WAL verranno abilitati a livello "logico".
   • Imposta il parametro wal_sender_timeout su 0. In questo modo, il meccanismo di timeout utilizzato per terminare le connessioni di replica inattive verrà disabilitato.

   • Imposta il max_replication_slots parametro. Questo parametro definisce il numero massimo di slot di replica che l'istanza di origine può supportare. Deve essere impostato almeno sul numero di abbonamenti che si prevede di connettere, 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, più il numero di slot di replica già utilizzati. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di slot di replica e verificare 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 a un valore almeno pari a max_replication_slots, più il numero di sender già utilizzati nell'istanza.

     Ad esempio, se il parametro max_replication_slots è impostato su 10 e utilizzi già 2 sender, il numero di processi sender WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di sender e verificare 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 a un valore almeno pari al numero di database di cui Database Migration Service eseguirà la migrazione (ovvero tutti i database nell'istanza di origine), più il numero di max_worker_processes già utilizzati nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di processi worker e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

     Il valore predefinito di questo parametro è 8.

   2. 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 collegare il gruppo di parametri.

3. Per applicare le modifiche alla configurazione, riavvia l'istanza di origine.

Nota: l'estensione pglogical può registrare le credenziali in testo normale nell'istanza di origine. Questo comportamento è causato dall'estensione stessa e non è correlato a Database Migration Service o Cloud SQL.

Cloud SQL per PostgreSQL

Abilita la replica e la decodifica logiche per il database di origine configurando i seguenti flag:

Tutte le impostazioni in questa sezione vengono configurate utilizzando i flag in Cloud SQL. Per abilitare i flag in Cloud SQL, consulta Configurare i flag del database.

1. Imposta i flag cloudsql.logical_decoding e cloudsql.enable_pglogical su on.

2. 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 almeno sul numero di abbonamenti che si prevede di connettere, 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, più il numero di slot di replica già utilizzati. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di slot di replica e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

   Il valore predefinito di questo flag è 10.

3. Imposta il flag max_wal_senders a un valore almeno pari a max_replication_slots, più il numero di sender già utilizzati nell'istanza.

   Ad esempio, se il flag max_replication_slots è impostato su 10 e utilizzi già 2 sender, il numero di processi sender WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di sender e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

   Il valore predefinito di questo flag è 10.

4. Imposta il flag di origine max_worker_processes a un valore almeno pari al numero di database di cui Database Migration Service eseguirà la migrazione (ovvero tutti i database nell'istanza di origine), più il numero di max_worker_processes già utilizzati nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo di dump dei dati modificate, assicurati di aumentare il numero di processi worker e verificare la configurazione eseguendo il test del job di migrazione quando crei il job di migrazione.

   Il valore predefinito di questo flag è 8.

5. Imposta il parametro wal_sender_timeout su 0. Il valore 0 disabilita il meccanismo di timeout che termina le connessioni di replica inattive.

6. Riavvia l'istanza di origine in modo che le modifiche alla configurazione apportate ai flag possano essere applicate.

Abilitare il monitoraggio del ritardo di replica per la versione di 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. Le seguenti alternative 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 di replica concedendo l'accesso a una query specifica. Utilizzando un utente con il privilegio SUPERUSER, esegui le seguenti operazioni:

  1. Definisci la seguente funzione per consentire a Database Migration Service di eseguire query per il ritardo di 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;
     $$;
     

  2. Concedi l'autorizzazione EXECUTE al USER eseguendo i seguenti comandi:

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• Opzione 2: concedi il privilegio SUPERUSER direttamente all'USER utilizzato per connetterti all'istanza di origine. In questo modo, Database Migration Service potrà leggere direttamente il ritardo di replica.

• Opzione 3: monitora il ritardo di replica in modo indipendente utilizzando la seguente query:

  Per le versioni di PostgreSQL precedenti alla 10, esegui questo comando come superuser.

      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, Database Migration Service non rifletterà la metrica del ritardo di replica nei grafici o nelle risposte API.