Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Configura il database PostgreSQL di origine per le migrazioni continue

Questa pagina descrive come configurare le istanze del database di origine per le migrazioni PostgreSQL omogenee continue ai cluster AlloyDB per PostgreSQL. Per informazioni dettagliate sulle versioni di origine supportate, consulta Database di origine e di destinazione supportati. Se vuoi utilizzare le migrazioni rapide, segui la guida Utilizza le migrazioni rapide. Le migrazioni rapide forniscono un flusso di migrazione semplificato che utilizza la replica pgnative e la connettività specializzata basata sulle interfacce Private Service Connect. Per saperne di più, consulta Informazioni sulle migrazioni con avvio rapido nella documentazione principale di Database Migration Service.

Questa pagina include procedure autonome per ogni origine supportata:

PostgreSQL autogestito (on-premise o su una VM di Compute Engine)
Amazon RDS per PostgreSQL
Amazon Aurora per PostgreSQL
Cloud SQL per PostgreSQL

Configura un'origine PostgreSQL self-hosted

Per configurare un'istanza di origine PostgreSQL in hosting autonomo (on-premise o ospitata su una VM di Compute Engine) per la migrazione continua, completa i seguenti passaggi:

Per le origini PostgreSQL in hosting autonomo, Database Migration Service esegue la migrazione di tutti i database nell'istanza di origine, ad eccezione dei database dei modelli template0 e template1.
Assicurati che l'istanza di origine includa il database postgres predefinito. Se questo database non esiste, crealo prima di configurare la migrazione.
Configura l'autenticazione del client di rete nel file pg_hba.conf. Aggiungi voci che consentano le connessioni di replica e l'accesso al database dall'intervallo di indirizzi IP del cluster AlloyDB per PostgreSQL di destinazione, dall'intervallo CIDR del VPC o dal bastion host SSH inverso:
```
# Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
```
Ricarica la configurazione di PostgreSQL per applicare le regole pg_hba.conf:
```
SELECT pg_reload_conf();
```
Verifica le estensioni PostgreSQL installate nei database di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da AlloyDB per PostgreSQL. Verifica che gli oggetti del database di origine e le query dell'applicazione non facciano riferimento a estensioni non supportate. Rimuovi le estensioni e i riferimenti non supportati dai database di origine prima di procedere.
L' estensione pg_cron non viene migrata automaticamente da Database Migration Service, ma è supportata nelle destinazioni AlloyDB per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nel cluster AlloyDB per PostgreSQL di destinazione dopo aver promosso la migrazione.

Crea un account utente dedicato per la migrazione nell'istanza di origine e concedigli i privilegi necessari:

Connettiti all'istanza di origine utilizzando un account amministratore, crea l'utente e assegna il ruolo di replica:

CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;

Concedi all'account utente di migrazione le autorizzazioni richieste per il database postgres predefinito e per ogni database di cui vuoi eseguire la migrazione. Esegui i seguenti comandi su ogni database per ogni schema, ad eccezione dello schema di informazioni e degli schemi che iniziano con pg_:

GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";

Installa l'estensione pglogical su ogni database di cui vuoi eseguire la migrazione, esclusi template0 e template1:
- Per PostgreSQL versione 9.4: esegui i seguenti comandi:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Per PostgreSQL 9.5 e versioni successive: esegui questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Verifica che le tabelle abbiano chiavi primarie. Per le migrazioni continue, la replica logica di PostgreSQL richiede che le tabelle abbiano chiavi primarie per replicare le operazioni UPDATE e DELETE durante la fase Change Data Capture (CDC):
- Le tabelle con una chiave primaria replicano automaticamente tutte le operazioni INSERT, UPDATE e DELETE.
- Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione solo dello snapshot iniziale e delle istruzioni INSERT successive durante la fase CDC. Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.
  Ti consigliamo di aggiungere chiavi primarie alle tabelle che non ne hanno prima di iniziare la migrazione. Per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie o come eseguire manualmente la migrazione delle operazioni UPDATE e DELETE, consulta Debug e altri strumenti.
  
  In alternativa, puoi provare a utilizzare il flusso di migrazione con avvio rapido: uno scenario di migrazione semplificato in cui puoi utilizzare REPLICA IDENTITY per eseguire la migrazione delle tabelle senza chiavi primarie. Per saperne di più, consulta la guida Utilizza le migrazioni rapide.
Origini che eseguono PostgreSQL 9.5 e versioni precedenti: la metrica del ritardo di replica non è disponibile per le istanze di origine che eseguono versioni di PostgreSQL precedenti alla 9.6. Se vuoi utilizzare questa metrica per monitorare l'avanzamento della migrazione, consulta Abilita il ritardo di replica.
Installa il pacchetto pglogical e configura i parametri WAL e di replica sul server PostgreSQL:
1. Installa il pacchetto pglogical sul sistema operativo host del server di database. Per i pacchetti e le istruzioni di installazione per la tua distribuzione, consulta il repository GitHub pglogical.
2. Connettiti all'istanza PostgreSQL utilizzando un account amministratore e imposta i seguenti parametri:
  1. Imposta shared_preload_libraries in modo che includa 'pglogical':
```
ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
```
    Nota: se nella tua istanza sono già caricate altre librerie, aggiungi 'pglogical' all'elenco separato da virgole esistente. Per visualizzare le librerie esistenti, esegui SHOW shared_preload_libraries;.
  2. Imposta wal_level su 'logical':
```
ALTER SYSTEM SET wal_level = 'logical';
```
    Consulta wal_level nella documentazione di PostgreSQL.
  3. Imposta wal_sender_timeout su 0:
```
ALTER SYSTEM SET wal_sender_timeout = 0;
```
    Il valore 0 disattiva il meccanismo di timeout che termina le connessioni di replica inattive. Consulta wal_sender_timeout.
  4. Imposta max_replication_slots su un valore almeno pari al numero di database di cui eseguire la migrazione moltiplicato per il numero di job di migrazione, più le riserve per la sincronizzazione delle tabelle:
    Ad esempio, se nell'istanza di origine sono presenti 5 database e crei 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 nell'origine da altre attività. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, assicurati di aumentare il numero di slot di replica e di verificare la configurazione quando crei il job di migrazione.
```
ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;
```
    Il valore predefinito di questo parametro è 10. Consulta max_replication_slots.
  5. Imposta 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 su 10 e stai già utilizzando 2 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 di verificare la configurazione quando crei il job di migrazione.
```
ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;
```
    Il valore predefinito di questo parametro è 10. Consulta max_wal_senders.
  6. Imposta max_worker_processes su un valore almeno pari al numero di database di cui eseguire la migrazione più i processi worker esistenti nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker):
```
ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;
```
    Il valore predefinito di questo parametro è 8. Consulta max_worker_processes.
  Nota: in alternativa, puoi rendere permanenti queste modifiche aggiungendo i parametri direttamente al file di configurazione postgresql.conf:
```
shared_preload_libraries = 'pglogical'
wal_level = 'logical'
wal_sender_timeout = 0
max_replication_slots = MAX_REPLICATION_SLOTS
max_wal_senders = MAX_WAL_SENDERS
max_worker_processes = MAX_WORKER_PROCESSES
```
Riavvia il server PostgreSQL in modo che le modifiche alla configurazione vengano applicate.

Configura un'origine Amazon RDS per PostgreSQL

Per configurare un'istanza di origine Amazon RDS per PostgreSQL per la migrazione continua, completa i seguenti passaggi:

Per le origini Amazon RDS per PostgreSQL, Database Migration Service esegue la migrazione di tutti i database nell'istanza di origine, ad eccezione dei database dei modelli template0, template1 e del database interno AWS rdsadmin.
Assicurati che l'istanza di origine includa il database postgres predefinito. Se questo database non esiste, crealo prima di configurare la migrazione.
Configura le regole in entrata del gruppo di sicurezza VPC di Amazon RDS. Consenti le connessioni TCP in entrata sulla porta 5432 dall'intervallo di indirizzi IP del cluster AlloyDB per PostgreSQL di destinazione, dall'intervallo CIDR VPC o dalla VM bastion host SSH inverso.
Verifica le estensioni PostgreSQL installate nei database di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da AlloyDB per PostgreSQL. Verifica che gli oggetti del database di origine e le query dell'applicazione non facciano riferimento a estensioni non supportate. Rimuovi le estensioni e i riferimenti non supportati dai database di origine prima di procedere.
L' estensione pg_cron non viene migrata automaticamente da Database Migration Service, ma è supportata nelle destinazioni AlloyDB per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nel cluster AlloyDB per PostgreSQL di destinazione dopo aver promosso la migrazione.
Crea un account utente dedicato per la migrazione nell'istanza di origine e concedigli i privilegi necessari:
1. Connettiti all'istanza di origine utilizzando un account amministratore, crea l'utente e concedi il ruolo rds_replication gestito da AWS:
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Concedi all'account utente di migrazione le autorizzazioni richieste per il database postgres predefinito e per ogni database di cui vuoi eseguire la migrazione. Esegui i seguenti comandi su ogni database per ogni schema, ad eccezione dello schema di informazioni e degli schemi che iniziano con pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installa l'estensione pglogical su ogni database di cui vuoi eseguire la migrazione, esclusi template0, template1 e rdsadmin. Esegui questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Per ulteriori dettagli sui requisiti, consulta Utilizzo delle estensioni PostgreSQL con Amazon RDS per PostgreSQL nella documentazione di AWS.

Nota: l'estensione pglogical può registrare le credenziali di accesso in testo normale nei log del database nell'istanza di origine. Questo è un comportamento noto dell'estensione stessa e non è correlato a Database Migration Service o AlloyDB per PostgreSQL.
Verifica che le tabelle abbiano chiavi primarie. Per le migrazioni continue, la replica logica di PostgreSQL richiede che le tabelle abbiano chiavi primarie per replicare le operazioni UPDATE e DELETE durante la fase Change Data Capture (CDC):
- Le tabelle con una chiave primaria replicano automaticamente tutte le operazioni INSERT, UPDATE e DELETE.
- Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione solo dello snapshot iniziale e delle istruzioni INSERT successive durante la fase CDC. Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.
  Ti consigliamo di aggiungere chiavi primarie alle tabelle che non ne hanno prima di iniziare la migrazione. Per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie o come eseguire manualmente la migrazione delle operazioni UPDATE e DELETE, consulta Debug e altri strumenti.
  
  In alternativa, puoi provare a utilizzare il flusso di migrazione con avvio rapido: uno scenario di migrazione semplificato in cui puoi utilizzare REPLICA IDENTITY per eseguire la migrazione delle tabelle senza chiavi primarie. Per saperne di più, consulta la guida Utilizza le migrazioni rapide.
Configura un gruppo di parametri DB personalizzato e collegalo alla tua istanza:
1. Crea un gruppo di parametri personalizzato (consulta Utilizzo dei gruppi di parametri DB nella documentazione di AWS) e configura i seguenti parametri:
  1. Imposta shared_preload_libraries in modo da includere pglogical.
  2. Imposta rds.logical_replication su 1. Questo parametro attiva il logging WAL logico in Amazon RDS. Consulta Replica logica per Amazon RDS per PostgreSQL.
  3. Imposta wal_sender_timeout su 0. Il valore 0 disattiva il meccanismo di timeout che termina le connessioni di replica inattive.
  4. Imposta max_replication_slots su un valore almeno pari al numero di database di cui eseguire la migrazione moltiplicato per il numero di job di migrazione, più le riserve per la sincronizzazione delle tabelle:
    Ad esempio, se nell'istanza di origine sono presenti 5 database e crei 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 nell'origine da altre attività. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, assicurati di aumentare il numero di slot di replica e di verificare la configurazione quando crei il job di migrazione.
    
    Il valore predefinito di questo parametro è 10.
  5. Imposta 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 su 10 e stai già utilizzando 2 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 di verificare la configurazione quando crei il job di migrazione.
    
    Il valore predefinito di questo parametro è 10.
  6. Imposta max_worker_processes su un valore almeno pari al numero di database di cui eseguire la migrazione più i processi worker esistenti nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker):
    Il valore predefinito di questo parametro è 8.
2. Collega il gruppo di parametri all'istanza DB RDS. 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.
Riavvia l'istanza Amazon RDS in modo che le modifiche al gruppo di parametri vengano applicate.

Configura un'origine Amazon Aurora PostgreSQL

Per configurare un cluster di origine Amazon Aurora PostgreSQL per la migrazione continua, completa i seguenti passaggi:

Per le origini Amazon Aurora per PostgreSQL, Database Migration Service esegue la migrazione di tutti i database nel cluster di origine, ad eccezione dei database modello template0, template1 e del database interno AWS rdsadmin.
Assicurati che il cluster di origine includa il database postgres predefinito. Se questo database non esiste, crealo prima di configurare la migrazione.
Configura le regole in entrata del gruppo di sicurezza VPC del cluster Amazon Aurora. Consenti le connessioni TCP in entrata sulla porta 5432 dall'intervallo di indirizzi IP del cluster AlloyDB per PostgreSQL di destinazione, dall'intervallo CIDR VPC o dalla VM bastion host SSH inverso.
Verifica le estensioni PostgreSQL installate nei database di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da AlloyDB per PostgreSQL. Verifica che gli oggetti del database di origine e le query dell'applicazione non facciano riferimento a estensioni non supportate. Rimuovi le estensioni e i riferimenti non supportati dai database di origine prima di procedere.
L' estensione pg_cron non viene migrata automaticamente da Database Migration Service, ma è supportata nelle destinazioni AlloyDB per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nel cluster AlloyDB per PostgreSQL di destinazione dopo aver promosso la migrazione.
Crea un account utente dedicato per la migrazione nel cluster di origine e concedigli i privilegi necessari:
1. Connettiti al cluster di origine utilizzando un account amministratore, crea l'utente e concedi il ruolo rds_replication gestito da AWS:
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Concedi all'account utente di migrazione le autorizzazioni richieste per il database postgres predefinito e per ogni database di cui vuoi eseguire la migrazione. Esegui i seguenti comandi su ogni database per ogni schema, ad eccezione dello schema di informazioni e degli schemi che iniziano con pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installa l'estensione pglogical su ogni database di cui vuoi eseguire la migrazione, esclusi template0, template1 e rdsadmin:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Nota: l'estensione pglogical può registrare le credenziali di accesso in testo normale nei log del database nell'istanza di origine. Questo è un comportamento noto dell'estensione stessa e non è correlato a Database Migration Service o AlloyDB per PostgreSQL.
Verifica che le tabelle abbiano chiavi primarie. Per le migrazioni continue, la replica logica di PostgreSQL richiede che le tabelle abbiano chiavi primarie per replicare le operazioni UPDATE e DELETE durante la fase Change Data Capture (CDC):
- Le tabelle con una chiave primaria replicano automaticamente tutte le operazioni INSERT, UPDATE e DELETE.
- Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione solo dello snapshot iniziale e delle istruzioni INSERT successive durante la fase CDC. Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.
  Ti consigliamo di aggiungere chiavi primarie alle tabelle che non ne hanno prima di iniziare la migrazione. Per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie o come eseguire manualmente la migrazione delle operazioni UPDATE e DELETE, consulta Debug e altri strumenti.
  
  In alternativa, puoi provare a utilizzare il flusso di migrazione con avvio rapido: uno scenario di migrazione semplificato in cui puoi utilizzare REPLICA IDENTITY per eseguire la migrazione delle tabelle senza chiavi primarie. Per saperne di più, consulta la guida Utilizza le migrazioni rapide.
Configura un gruppo di parametri del cluster di database personalizzato e collegalo al cluster:
1. Crea un gruppo di parametri del cluster di database personalizzato e configura i seguenti parametri:
  1. Imposta shared_preload_libraries in modo da includere pglogical.
  2. Imposta rds.logical_replication su 1. Questo parametro attiva il logging WAL logico.
  3. Imposta wal_sender_timeout su 0. Il valore 0 disattiva il meccanismo di timeout che termina le connessioni di replica inattive.
  4. Imposta max_replication_slots su un valore almeno pari al numero di database di cui eseguire la migrazione moltiplicato per il numero di job di migrazione, più le riserve per la sincronizzazione delle tabelle:
    Ad esempio, se nell'istanza di origine sono presenti 5 database e crei 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 nell'origine da altre attività. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, assicurati di aumentare il numero di slot di replica e di verificare la configurazione quando crei il job di migrazione.
    
    Il valore predefinito di questo parametro è 10.
  5. Imposta 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 su 10 e stai già utilizzando 2 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 di verificare la configurazione quando crei il job di migrazione.
    
    Il valore predefinito di questo parametro è 10.
  6. Imposta max_worker_processes su un valore almeno pari al numero di database di cui eseguire la migrazione più i processi worker esistenti nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker):
    Il valore predefinito di questo parametro è 8.
2. Collega il gruppo di parametri del cluster di database al cluster di database Aurora.
Riavvia il cluster di database Amazon Aurora in modo che le modifiche al gruppo di parametri vengano applicate.

Configura un'origine Cloud SQL per PostgreSQL

Per configurare un'istanza di origine Cloud SQL per PostgreSQL per la migrazione continua, completa i seguenti passaggi:

Per le origini Cloud SQL per PostgreSQL, Database Migration Service esegue la migrazione di tutti i database nell'istanza di origine, ad eccezione dei database modello template0 e template1.
Assicurati che l'istanza di origine includa il database postgres predefinito. Se questo database non esiste, crealo prima di configurare la migrazione.
Se esegui la migrazione da un'istanza di origine Cloud SQL configurata con un indirizzo IP privato a un cluster AlloyDB per PostgreSQL di destinazione che utilizza un intervallo IP di indirizzi non RFC 1918, aggiungi l'intervallo non RFC 1918 alle reti autorizzate dell'istanza di origine. Per saperne di più, consulta Configura le reti autorizzate.
Verifica le estensioni PostgreSQL installate nei database di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da AlloyDB per PostgreSQL. Verifica che gli oggetti del database di origine e le query dell'applicazione non facciano riferimento a estensioni non supportate. Rimuovi le estensioni e i riferimenti non supportati dai database di origine prima di procedere.
L' estensione pg_cron non viene migrata automaticamente da Database Migration Service, ma è supportata nelle destinazioni AlloyDB per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nel cluster AlloyDB per PostgreSQL di destinazione dopo aver promosso la migrazione.
Crea un account utente dedicato per la migrazione nell'istanza di origine e concedigli i privilegi necessari:
1. Segui i passaggi della pagina Crea un utente nella documentazione di Cloud SQL per creare l'account utente.
2. Concedi il ruolo cloudsqlsuperuser all'account utente di migrazione:
```
GRANT cloudsqlsuperuser TO "MIGRATION_USER_ACCOUNT_NAME";
```
3. Concedi all'account utente di migrazione le autorizzazioni richieste per il database postgres predefinito e per ogni database di cui vuoi eseguire la migrazione. Esegui i seguenti comandi su ogni database per ogni schema, ad eccezione dello schema di informazioni e degli schemi che iniziano con pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Installa l'estensione pglogical su ogni database di cui vuoi eseguire la migrazione, esclusi template0 e template1. Esegui questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Verifica che le tabelle abbiano chiavi primarie. Per le migrazioni continue, la replica logica di PostgreSQL richiede che le tabelle abbiano chiavi primarie per replicare le operazioni UPDATE e DELETE durante la fase Change Data Capture (CDC):
- Le tabelle con una chiave primaria replicano automaticamente tutte le operazioni INSERT, UPDATE e DELETE.
- Per le tabelle senza chiavi primarie, Database Migration Service esegue la migrazione dello snapshot iniziale e delle istruzioni INSERT successive durante la fase CDC. Devi eseguire manualmente la migrazione delle istruzioni UPDATE e DELETE.
  Ti consigliamo di aggiungere chiavi primarie alle tabelle che non ne hanno prima di iniziare la migrazione. Per scoprire come generare una query per elencare le tabelle in un database PostgreSQL senza chiavi primarie o come eseguire manualmente la migrazione delle operazioni UPDATE e DELETE, consulta Debug e altri strumenti.
  
  In alternativa, puoi provare a utilizzare il flusso di migrazione con avvio rapido: uno scenario di migrazione semplificato in cui puoi utilizzare REPLICA IDENTITY per eseguire la migrazione delle tabelle senza chiavi primarie. Per saperne di più, consulta la guida Utilizza le migrazioni rapide.
Configura i seguenti flag di database nell'istanza di origine Cloud SQL:
1. Imposta cloudsql.logical_decoding su on.
2. Imposta cloudsql.enable_pglogical su on.
3. Imposta wal_sender_timeout su 0. Il valore 0 disattiva il meccanismo di timeout che termina le connessioni di replica inattive.
4. Imposta max_replication_slots su un valore almeno pari al numero di database di cui eseguire la migrazione moltiplicato per il numero di job di migrazione, più le riserve per la sincronizzazione delle tabelle.
  Ad esempio, se nell'istanza di origine sono presenti 5 database e crei 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 nell'origine da altre attività. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, assicurati di aumentare il numero di slot di replica e di verificare la configurazione quando crei il job di migrazione.
  
  Il valore predefinito di questo flag è 10.
5. Imposta 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 su 10 e stai già utilizzando 2 mittenti, il numero di processi di invio 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 di verificare la configurazione quando crei il job di migrazione.
  
  Il valore predefinito di questo flag è 10.
6. Imposta max_worker_processes su un valore almeno pari al numero di database di cui eseguire la migrazione più i processi worker esistenti nell'istanza. Se prevedi di utilizzare impostazioni di parallelismo del dump dei dati modificate, tieni conto di due processi worker aggiuntivi per connessione (fino a un massimo di 20 worker).
  Il valore predefinito di questo flag è 8.
Per saperne di più sulla modifica dei flag, consulta Configura i flag di database nella documentazione di Cloud SQL.
Riavvia l'istanza Cloud SQL di origine in modo che le modifiche ai flag di database possano essere applicate.

Passaggi successivi

Per procedure dettagliate complete sulla migrazione, consulta Inizia a utilizzare le migrazioni di AlloyDB per PostgreSQL.
Per pianificare la connettività di rete tra le istanze di origine e di destinazione, consulta Considerazioni sul networking.