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 esempio,last_value
) nella nuova destinazione AlloyDB potrebbero variare rispetto agli statiSEQUENCE
di 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 supportati da AlloyDB per PostgreSQL.
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 durante l'installazione delle estensioni supportate da AlloyDB.
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é AlloyDB 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 AlloyDB 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
alloydbexternalsync
in AlloyDB primary. Quando viene eseguito da qualsiasi utente, viene eseguito con i privilegi dialloydbexternalsync
che ha i ruolialloydbsuperuser
ealloydbreplica
. È 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.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 a cluster di destinazione esistenti
- 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.
- Puoi configurare un solo job di migrazione per cluster di destinazione.
- La migrazione a cluster con cluster secondari 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 la 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.