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 standard. 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 sezioni per ogni origine supportata:

PostgreSQL autogestito (on-premise o su una VM di Compute Engine)
Amazon RDS per PostgreSQL
Amazon Aurora per PostgreSQL
Database di Microsoft Azure per il server flessibile PostgreSQL
Cloud SQL per PostgreSQL

Configura un'origine PostgreSQL autogestita

Per configurare un'istanza di origine PostgreSQL autogestita (on-premise o ospitata su una VM di Compute Engine) per il processo di migrazione, procedi come segue:

Per le origini PostgreSQL autogestite, 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'indirizzo IP in uscita di Cloud SQL di destinazione, dall'intervallo CIDR 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 Cloud SQL. 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 Cloud SQL per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nell'istanza 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 questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Per PostgreSQL versione 9.5 e 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';
```
    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 eseguendo il test del job di migrazione 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 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 eseguendo il test del job di migrazione 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.
  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 il processo di migrazione, procedi come segue:

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 modello 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'indirizzo IP in uscita di Cloud SQL 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 Cloud SQL. 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 Cloud SQL per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nell'istanza 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, ad eccezione di template0, template1 e rdsadmin:
- Per PostgreSQL versione 9.4: esegui questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Per PostgreSQL versione 9.5 e successive: esegui questo comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Per maggiori 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 Cloud SQL.
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.
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 del database 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 eseguendo il test del job di migrazione 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 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 eseguendo il test del job di migrazione 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 di database 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 per PostgreSQL

Per configurare un cluster di origine Amazon Aurora PostgreSQL per il processo di migrazione, procedi come segue:

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 dei modelli 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'indirizzo IP in uscita di Cloud SQL 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 Cloud SQL. 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 Cloud SQL per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nell'istanza 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 Cloud SQL.
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 eseguendo il test del job di migrazione 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 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 eseguendo il test del job di migrazione 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 Microsoft Azure Database for PostgreSQL Flexible Server

Per configurare un'istanza di origine del server flessibile di Microsoft Azure Database for PostgreSQL per il processo di migrazione, procedi come segue:

Per le origini Microsoft Azure Database for PostgreSQL Flexible Server, Database Migration Service esegue la migrazione di tutti i database nell'istanza di origine, ad eccezione dei database di sistema e dei modelli di Azure: azure_maintenance, azure_sys, 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 le impostazioni del firewall e di SSL/TLS di Azure:
1. Nelle impostazioni della rete di Azure, aggiungi regole firewall che consentano connessioni TCP in entrata sulla porta 5432 dall'indirizzo IP in uscita di Cloud SQL di destinazione, dall'intervallo CIDR VPC o dalla VM bastion host SSH inversa.
2. Verifica il valore del parametro del server require_secure_transport. Per impostazione predefinita, i database Azure richiedono la crittografia SSL/TLS per le connessioni in entrata. A seconda dell'impostazione require_secure_transport, seleziona 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.
Verifica le estensioni PostgreSQL installate nei database di origine. Database Migration Service non esegue la migrazione delle estensioni non supportate da Cloud SQL. 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 Cloud SQL per PostgreSQL. Se utilizzi pg_cron nel database di origine, reinstallalo e configuralo nell'istanza di destinazione dopo aver promosso la migrazione.