Panoramica
Prima di scegliere di eseguire la migrazione dei tuoi 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.Ad esempio,
pglogical
fornisce una funzionepglogical.replicate_ddl_command
che consente di eseguire il DDL su in entrambi il database di origine e la replica in un punto coerente. L'utente che esegue questo comando sull'origine deve già esistere nella 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 sulla 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 di acquisizione dei dati modificati (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 delle viste. Per compilare le visualizzazioni, esegui il seguente comando:
REFRESH MATERIALIZED VIEW view_name
.Gli stati
SEQUENCE
(ad esempiolast_value
) nella nuova destinazione Cloud SQL potrebbero variare dagli statiSEQUENCE
di origine.Le tabelle
UNLOGGED
eTEMPORARY
non sono e non possono essere riprodutte.Il tipo di dati Object di grandi dimensioni non è supportato. Ulteriori dettagli nella sezione sulla fedeltà della migrazione.
È possibile eseguire la migrazione solo di estensioni e linguaggi procedurali supportati da Cloud SQL 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 fluido, verifica che gli oggetti o le 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 eventuali impostazionicron
associate all'estensione) non viene migrata da Database Migration Service, ma è supportata nelle destinazioni Cloud SQL per PostgreSQL. Se utilizzi l'estensionepg_cron
nei tuoi database di origine, puoi reinstallarla nell'istanza di destinazione al termine della migrazione.
Database Migration Service non supporta la migrazione da 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.
- Non è possibile eseguire la migrazione delle funzioni definite dall'utente scritte in C, ad eccezione delle funzioni 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 relative versioni non sono supportate, il test o l'avvio del job di migrazione non andrà a buon fine.
La migrazione dei database aggiunti dopo l'avvio del job non viene eseguita.
- Non puoi selezionare oggetti di database specifici (ad esempio database, tabelle o schemi) durante la migrazione utilizzando Database Migration Service.
Database Migration Service esegue la migrazione di tutte le tabelle e di tutti gli schemi, ad eccezione dei seguenti:
- Lo schema di informazioni (
information_schema
) - Tutti gli schemi che iniziano con
pg
(ad esempiopg_catalog
, che contiene le tabelle di sistema e tutti i tipi di dati, le funzioni e gli operatori incorporati ed esiste automaticamente in tutti i database). Di conseguenza, non viene eseguita la migrazione delle informazioni su utenti e ruoli utente. Consulta l'elenco completo degli schemi che iniziano conpg
.
- Lo schema di informazioni (
Se i database criptati richiedono chiavi di crittografia gestite dal cliente per decriptarli e se Database Migration Service non ha accesso alle chiavi, non è possibile eseguire la migrazione dei database.
Tuttavia, se i dati dei clienti sono criptati dall'estensione
pgcrypto
, è possibile eseguirne la migrazione con Database Migration Service (in quanto Cloud SQL supporta l'estensione).Database Migration Service supporta anche la migrazione dei dati dai database Amazon Aurora o Amazon RDS criptati perché questi database gestiscono la decrittografia in modo trasparente nei loro servizi. Per ulteriori informazioni, consulta 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 di modifiche DDL, se necessario. Fai attenzione a non apportare modifiche alla configurazione del database o alle strutture delle tabelle che potrebbero interrompere il processo di migrazione o influire sull'integrità dei dati.
Il comportamento degli attivatori dipende dalla modalità di configurazione. Il comportamento predefinito è che non si attiveranno, ma se sono stati configurati utilizzando l'istruzione
ALTER EVENT TRIGGER
oALTER TABLE
e lo stato dell'attivatore è impostato su replica o sempre, si attiveranno sulla replica durante la replica.Le funzioni con il delimitatore 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 impostazione della sicurezza solo ad alcuni utenti. A tale scopo, l'utente deve revocare i privilegi PUBLIC predefiniti e concedere il privilegio di esecuzione in modo selettivo.Cloud SQL non supporta gli spazi tabella personalizzati. Tutti i dati all'interno degli spazi tabella personalizzati vengono migrati allo spazio tabella
pg_default
nell'istanza di destinazione Cloud SQL.
Limitazioni per le migrazioni alle istanze di destinazione esistenti
- L'istanza di destinazione esistente deve essere vuota o contenere solo i dati di configurazione di 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 a eseguire il job di migrazione. Consulta Cancellare i 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 in cui è attivato Private Service Connect non è supportata.
- Dopo aver promosso un'istanza, devi attivare il recupero point-in-time.
- Se l'istanza ha impostazioni di backup personalizzate (ad esempio una posizione di backup personalizzata), dopo averla promossa devi personalizzare di nuovo le impostazioni di backup. Durante la procedura di promozione, Cloud SQL reimposta le impostazioni di backup sui valori predefiniti.
- Per gli utenti di Terraform: Database Migration Service modifica le impostazioni di backup e recupero dell'istanza di destinazione. Ciò potrebbe causare un'incongruenza tra le impostazioni dell'istanza di destinazione e la configurazione di 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.