Panoramica
Prima di scegliere di eseguire la migrazione dei database a Cloud SQL, assicurati di prendere in considerazione le limitazioni note per questo scenario di migrazione.
Le limitazioni note per l'utilizzo di un database PostgreSQL come origine includono:
L'estensione
pglogical
non supporta la replica delle colonne generate per PostgreSQL 12 e versioni successive.Le modifiche alle strutture delle tabelle (DDL) non vengono replicate tramite i comandi DDL standard, ma solo con i comandi eseguiti utilizzando l'estensione
pglogical
utilizzata per la replica. Ciò include modifiche ai tipi dienum
.Ad esempio,
pglogical
fornisce una funzionepglogical.replicate_ddl_command
che consente l'esecuzione del DDL sia sul database di origine sia sulla replica in un punto coerente. L'utente che esegue questo comando sull'origine deve già esistere sulla replica.Per replicare i dati per le nuove tabelle, devi utilizzare il comando
pglogical.replication_set_add_table
per aggiungere le nuove tabelle ai set di replica esistenti.Per saperne di più sulla replica DDL durante la migrazione, consulta la sezione relativa alla fedeltà della migrazione.
Per le tabelle senza chiavi primarie, Database Migration Service supporta la migrazione degli snapshot iniziali e delle istruzioni
INSERT
durante la fase Change Data Capture (CDC). Devi eseguire manualmente la migrazione delle istruzioniUPDATE
eDELETE
.Database Migration Service non esegue la migrazione dei dati dalle viste materializzate, ma solo dello schema della vista. Per popolare le visualizzazioni, esegui il comando seguente:
REFRESH MATERIALIZED VIEW view_name
.Gli stati
SEQUENCE
(ad esempiolast_value
) nella nuova destinazione Cloud SQL potrebbero variare rispetto agli statiSEQUENCE
dell'origine.Le tabelle
UNLOGGED
eTEMPORARY
non vengono replicate e non possono essere replicate.Il tipo di dati Large Object non è supportato. Per ulteriori dettagli, consulta la sezione Fidelizzazione della migrazione.
Possono essere migrate solo le estensioni e i linguaggi procedurali che Cloud SQL supporta per PostgreSQL. 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 questi riferimenti dal database di origine prima di procedere.
L'estensione
pg_cron
(o qualsiasi impostazionecron
associata all'estensione) non viene migrata da Database Migration Service, ma è supportata nelle destinazioni Cloud SQL per PostgreSQL. Se utilizzi l'estensionepg_cron
nei database di origine, puoi reinstallarla nell'istanza di destinazione al termine della migrazione.
Database Migration Service non supporta la migrazione dalle repliche di lettura in modalità di recupero.
Database Migration Service non supporta le origini Amazon RDS a cui è applicato il pacchetto di estensioni AWS SCT.
- Le funzioni definite dall'utente scritte in C non possono essere migrate, ad eccezione di quelle installate nel database PostgreSQL quando installi le estensioni supportate da Cloud SQL.
Se nel database di origine esistono altre estensioni e linguaggi procedurali o se le loro versioni non sono supportate, il test o l'avvio del job di migrazione non andrà a buon fine.
I database aggiunti dopo l'avvio del job di migrazione non vengono migrati.
- Non puoi selezionare tabelle o schemi specifici quando esegui la migrazione utilizzando Database Migration Service.
Database Migration Service esegue la migrazione di tutte le tabelle e gli schemi, ad eccezione di quanto segue:
- Lo schema di informazioni (
information_schema
). - Qualsiasi tabella che inizia con
pg
, ad esempiopg_catalog
. Per l'elenco completo dei cataloghi PostgreSQL che iniziano conpg
, consulta la sezione Cataloghi di sistema PostgreSQL nella documentazione di PostgreSQL. - Le informazioni sugli utenti e sui ruoli utente non vengono migrate.
- Lo schema di informazioni (
Se i database criptati richiedono chiavi di crittografia gestite dal cliente per essere decriptati e se Database Migration Service non ha accesso alle chiavi, i database non possono essere migrati.
Tuttavia, se i dati dei clienti sono criptati dall'estensione
pgcrypto
, possono essere migrati con Database Migration Service (perché Cloud SQL supporta l'estensione).Database Migration Service supporta anche la migrazione dei dati da database Amazon Aurora o Amazon RDS criptati perché questi database gestiscono la decrittografia in modo trasparente nei loro servizi. Per ulteriori informazioni, vedi Crittografia delle risorse Amazon Aurora e Crittografia delle risorse Amazon RDS.
Il database Cloud SQL di destinazione è scrivibile durante la migrazione per consentire l'applicazione delle modifiche DDL, se necessario. Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere la procedura di migrazione o influire sull'integrità dei dati.
Il comportamento dei trigger dipende dalla loro configurazione. Il comportamento predefinito è che non vengono attivati, ma se sono stati configurati utilizzando l'istruzione
ALTER EVENT TRIGGER
oALTER TABLE
e lo stato del trigger è impostato su replica o always, vengono attivati sulla replica durante la replica.Le funzioni con definizioni di sicurezza verranno create da
cloudsqlexternalsync
nella replica Cloud SQL. Quando viene eseguito da qualsiasi utente, viene eseguito con i privilegi dicloudsqlexternalsync
che ha i ruolicloudsqlsuperuser
ecloudsqlreplica
. È preferibile limitare l'utilizzo di una funzione di definizione della sicurezza solo ad alcuni utenti. A questo scopo, l'utente deve revocare i privilegi PUBLIC predefiniti e concedere il privilegio di esecuzione in modo selettivo.Cloud SQL non supporta i tablespace personalizzati. Tutti i dati all'interno degli spazi delle tabelle personalizzati vengono migrati nello spazio delle tabelle
pg_default
nell'istanza di destinazione Cloud SQL.
Limitazioni per le migrazioni a istanze di destinazione esistenti
- L'istanza di destinazione esistente deve essere vuota o contenere solo
dati di configurazione del sistema. La migrazione a istanze di destinazione esistenti
che contengono dati utente (ad esempio tabelle) non è supportata.
Se riscontri problemi a causa di dati aggiuntivi nell'istanza di destinazione esistente, cancella i database nell'istanza di destinazione e riprova il job di migrazione. Consulta Cancella dati aggiuntivi dall'istanza di destinazione esistente.
- Puoi configurare un solo job di migrazione per istanza di destinazione.
- Puoi eseguire la migrazione solo a istanze Cloud SQL autonome. La migrazione alle repliche del server esterno non è supportata.
- La migrazione dei dati a un'istanza Cloud SQL con Private Service Connect abilitato non è supportata.
- Dopo aver promosso un'istanza, devi attivare il recupero point-in-time.
- Se la tua istanza ha impostazioni di backup personalizzate (ad esempio, una posizione di backup personalizzata), dopo aver promosso l'istanza, devi personalizzare nuovamente le impostazioni di backup. Durante il processo di promozione, Cloud SQL reimposta le impostazioni di backup ai valori predefiniti.
- Per gli utenti di Terraform: Database Migration Service modifica le impostazioni di backup e ripristino dell'istanza di destinazione. Ciò potrebbe comportare che le impostazioni dell'istanza di destinazione siano diverse dalla configurazione Terraform utilizzata per il provisioning. Se riscontri questo problema, segui le indicazioni riportate in Diagnostica dei problemi.
Quote
- In qualsiasi momento, possono esistere fino a 2000 profili di connessione e 1000 job di migrazione. Per creare spazio, è possibile eliminare i job di migrazione (compresi quelli completati) e i profili di connessione.