Configura l'origine

MySQL   |  PostgreSQL   |  PostgreSQL ad AlloyDB

Panoramica

Database Migration Service supporta migrazioni continue dai database di origine ai database AlloyDB 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
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14, 15, 16, 17
• 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
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

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 questi passaggi:

1. L'istanza di origine deve includere il database postgres. Se non disponi di questo database, crealo.
2. Installa il pacchetto pglogical sull'istanza di origine e assicurati che sia incluso nella variabile shared_preload_libraries.
   1. Consulta Installare il pacchetto pglogical sull'istanza di origine per il tuo ambiente.

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 e template1
• Per le origini Amazon RDS: template0, template1 e rdsadmin
• Per le origini Cloud SQL: database modello template0 e 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 estensioni pglogical 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 manualmente la migrazione delle istruzioni UPDATE e DELETE.

   Consulta Debug e altri strumenti per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie. Per ogni tabella del database che non ha una chiave primaria e non fa parte dei database di cui non è stata eseguita la migrazione, devi modificare la tabella in modo che abbia una chiave primaria o seguire questa procedura. Per le tabelle senza chiavi primarie, vengono migrati solo lo snapshot iniziale e le 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. Ruolo ALTER USER USER with REPLICATION

Installa il pacchetto pglogical sull'istanza di origine

Questa sezione descrive come configurare il pacchetto pglogical, inclusa la configurazione dei 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 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 la tua 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 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 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 se 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 modificate, 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 deve 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 max_replication_slots è impostato su 10 e stai già utilizzando due mittenti, il numero di processi mittente WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, assicurati di aumentare il numero di mittenti 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 di invio WAL in esecuzione simultanea.

   • 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 nell'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 modificate, 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.

   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.

Amazon RDS PostgreSQL

1. Installa l'estensione pglogical sul database di origine. Per saperne di più, consulta la sezione Utilizzo delle estensioni PostgreSQL con Amazon RDS per PostgreSQL nella documentazione di Amazon RDS.

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

   • 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à disattivato.

   • Imposta il parametro max_replication_slots. Questo parametro definisce il numero massimo di slot di replica supportati dall'istanza di origine. 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 se 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 le impostazioni di parallelismo del dump dei dati aggiustate, 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 a 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 su 10 e stai già utilizzando due mittenti, il numero di processi mittente WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, 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 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 del dump dei dati modificate, 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.

3. 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.

4. 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 logica e la decodifica 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 di 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 supportati dall'istanza di origine. 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 se 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 del dump dei dati modificate, 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.

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

   Ad esempio, se il flag max_replication_slots è impostato su 10 e utilizzi già due mittenti, il numero di processi mittente WAL in esecuzione contemporaneamente sarà 10 + 2 = 12. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, 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.

4. Imposta il flag di origine max_worker_processes su 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 le impostazioni di parallelismo del dump dei dati aggiustate, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker).

   Il valore predefinito di questo flag è 8.

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

Abilita il monitoraggio del ritardo di replica per PostgreSQL versione precedente alla 9.6

Se esegui la migrazione da una versione di PostgreSQL precedente alla 9.6, la metrica Ritardo di replica non è disponibile per impostazione predefinita. Esistono tre alternative che consentono di tracciare questa metrica per garantire un tempo di inattività minimo durante la promozione del database:

1. Opzione 1: abilita Database Migration Service a 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 a 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};

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

3. 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 riflette la metrica del ritardo di replica nei grafici o nelle risposte API.