Le limitazioni note per l'utilizzo di un database PostgreSQL come origine includono:
L'estensione
pglogicalnon 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
pglogicalutilizzata per la replica. Sono incluse le modifiche aienumtipi.Ad esempio,
pglogicalfornisce una funzionepglogical.replicate_ddl_commandche consente di eseguire il 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_tableper aggiungere le nuove tabelle ai set di replica esistenti.Per scoprire di più sulla replica DDL durante la migrazione in corso, 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
INSERTdurante la fase Change Data Capture (CDC). Devi eseguire manualmente la migrazione delle istruzioniUPDATEeDELETE.Database Migration Service non esegue la migrazione dei dati dalle viste materializzate, ma solo dello schema della vista. Per popolare le viste, esegui il comando seguente:
REFRESH MATERIALIZED VIEW view_name.Gli stati
SEQUENCE(ad esempiolast_value) nella nuova destinazione AlloyDB potrebbero variare rispetto agli statiSEQUENCEdi origine.Le tabelle
UNLOGGEDeTEMPORARYnon vengono e non possono essere replicate.Il tipo di dati Large Object non è supportato. Ulteriori dettagli nella sezione sulla fedeltà della migrazione.
È possibile eseguire la migrazione solo delle estensioni e dei linguaggi procedurali supportati da AlloyDB per PostgreSQL.
Database Migration Service non supporta la migrazione da repliche di lettura in modalità di recupero.
Database Migration Service non supporta le origini Amazon RDS in 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 AlloyDB.
Se nel database di origine esistono altre estensioni e linguaggi procedurali o se le relative versioni non sono supportate, il job di migrazione non andrà a buon fine quando lo testi o lo avvii.
I database aggiunti dopo l'avvio del job di migrazione non vengono migrati.
Quando esegui la migrazione utilizzando Database Migration Service, non puoi selezionare tabelle o schemi specifici. Database Migration Service esegue la migrazione di tutte le tabelle e di tutti gli schemi, ad eccezione di quanto segue:
- Lo schema di informazioni (
information_schema). - Tutte le tabelle che iniziano con
pg, ad esempiopg_catalog. Per l'elenco completo dei cataloghi PostgreSQL che iniziano conpg, consulta Cataloghi di sistema PostgreSQL nella documentazione di PostgreSQL. - Le informazioni su utenti e ruoli utente non vengono migrate.
- 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 eseguire la migrazione dei dati con Database Migration Service (perché AlloyDB per PostgreSQL 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 decriptografia in modo trasparente nei relativi servizi. Per saperne di più, consulta Criptare le risorse Amazon Aurora e Criptare le risorse Amazon RDS.
Il database AlloyDB per PostgreSQL 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 il processo 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 TRIGGERoALTER TABLEe lo stato del trigger è impostato su replica o always, verranno attivati sulla replica durante la replica.Le funzioni con security definer verranno create da
alloydbexternalsyncnella primaria AlloyDB. Quando viene eseguita da qualsiasi utente, verrà eseguita con i privilegi dialloydbexternalsync, che ha i ruolialloydbsuperuserealloydbreplica. È preferibile limitare l'utilizzo di una funzione security definer solo ad alcuni utenti. Per farlo, l'utente deve revocare i privilegi PUBLIC predefiniti e poi concedere il privilegio di esecuzione in modo selettivo.Il metodo di connettività delle interfacce Private Service Connect è supportato solo per la migrazione alle istanze di destinazione esistenti. Se vuoi utilizzare la connettività IP privata ed eseguire la migrazione a una nuova istanza di destinazione, utilizza il peering VPC.
Limitazioni per le migrazioni ai cluster di destinazione esistenti
- Puoi configurare un solo job di migrazione attivo per cluster di destinazione.
- Il cluster di destinazione esistente deve essere vuoto o contenere solo dati di configurazione del sistema. La migrazione a un cluster di destinazione esistente che contiene dati utente (ad esempio tabelle) non è supportata.
- La migrazione ai cluster con istanze del pool di lettura è supportata.
Per saperne di più sui cluster e sulle istanze AlloyDB per PostgreSQL, consulta Panoramica di AlloyDB per PostgreSQL.
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.