Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Utilizzo di un database PostgreSQL come origine AWS DMS
È possibile migrare i dati da uno o più database PostgreSQL utilizzando. AWS DMS Con un database PostgreSQL come origine, puoi eseguire la migrazione dei dati a un altro database PostgreSQL o a uno degli altri database supportati.
Per informazioni sulle versioni di PostgreSQL supportate come sorgente, AWS DMS consulta. Fonti per AWS DMS
AWS DMS supporta PostgreSQL per questi tipi di database:
-
Database locali
-
Database su un' EC2 istanza Amazon
-
Database su un'istanza database Amazon RDS
-
Database su un'istanza database basata su Amazon Aurora edizione compatibile con PostgreSQL
-
Database su un'istanza database basata su Amazon Aurora edizione serverless compatibile con PostgreSQL
Nota
DMS supporta Amazon Aurora PostgreSQL serverless V1 come origine per solo pieno carico. Tuttavia puoi usare Amazon Aurora PostgreSQL serverless V2 come origine per le attività di pieno carico, pieno carico e CDC nonché sola CDC.
Versione di origine PostgreSQL |
AWS DMS versione da usare |
---|---|
9.x, 10.x, 11.x, 12.x |
Usa qualsiasi AWS DMS versione disponibile. |
13.x |
Usa AWS DMS la versione 3.4.3 e successive. |
14.x |
Usa AWS DMS la versione 3.4.7 e successive. |
15.x |
Usa la AWS DMS versione 3.5.1 e successive. |
16.x |
Usa AWS DMS la versione 3.5.3 e successive. |
Puoi utilizzare il protocollo Secure Sockets Layer (SSL) per crittografare le connessioni tra l'endpoint PostgreSQL e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint PostgreSQL, consulta Utilizzo di SSL con AWS Database Migration Service.
Come requisito di sicurezza aggiuntivo, quando si utilizza PostgreSQL come origine, l'account utente specificato deve essere un utente registrato nel database PostgreSQL.
Per configurare un database PostgreSQL come endpoint di origine, procedi AWS DMS come segue:
-
Crea un utente PostgreSQL con le autorizzazioni appropriate per fornire l' AWS DMS accesso al tuo database di origine PostgreSQL.
Nota
-
Se il database di origine PostgreSQL è autogestito, consulta Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS per ulteriori informazioni.
-
Se il database di origine PostgreSQL è gestito da Amazon RDS, consulta Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS per ulteriori informazioni.
-
-
Crea un endpoint do origine PostgreSQL conforme alla configurazione del database PostgreSQL scelta.
-
Crea un'attività o una serie di attività per migrare le tabelle.
Per creare un' full-load-onlyattività, non è necessaria alcuna ulteriore configurazione dell'endpoint.
Prima di creare un'attività per l'acquisizione dei dati di modifica (un'attività di sola CDC o pieno carico e CDC), consulta Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS o Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS.
Argomenti
Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS
Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS
Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica
Migrazione da Babelfish per Amazon Aurora PostgreSQL utilizzando AWS DMS
Rimozione di AWS DMS artefatti da un database sorgente PostgreSQL
Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS
Utilizzo dell'impostazione dell' MapBooleanAsBoolean endpoint PostgreSQL
Limitazioni all'utilizzo di un database PostgreSQL come origine DMS
Utilizzo di database PostgreSQL autogestiti come sorgente in AWS DMS
Con un database PostgreSQL autogestito come origine, puoi migrare i dati su un altro database PostgreSQL o su uno degli altri database di destinazione supportati da. AWS DMS L'origine del database può essere un database locale o un motore autogestito in esecuzione su un'istanza Amazon EC2 . È possibile utilizzare un'istanza database sia per le attività di pieno carico che per l'acquisizione dei dati di modifica (CDC).
Prerequisiti per l'utilizzo di un database PostgreSQL autogestito come sorgente AWS DMS
Prima di migrare i dati da un database di origine PostgreSQL autogestito, procedi come segue:
-
Assicurati di utilizzare un database PostgreSQL versione 9.4.x o successiva.
-
Per le attività di pieno carico e CDC o le attività di sola CDC, fornisci le autorizzazioni di superuser per l'account utente specificato per il database di origine PostgreSQL. Le autorizzazioni di superuser sono necessarie all'account utente per accedere alle funzioni specifiche della replica nell'origine. Per le attività solo pieno carico, l'account utente richiede le autorizzazioni SELECT sulle tabelle per eseguirne la migrazione.
-
Aggiungere l'indirizzo IP del server di AWS DMS replica al file di
pg_hba.conf
configurazione e abilitare la replica e le connessioni socket. Di seguito è riportato un esempio.# Replication Instance host all all 12.3.4.56/00 md5 # Allow replication connections from localhost, by a user with the # replication privilege. host replication dms 12.3.4.56/00 md5
Il file di configurazione di PostgreSQL
pg_hba.conf
controlla l'autenticazione client. (HBA sta per autenticazione basata su host) Il file è solitamente memorizzato nella directory dei dati del cluster di database. -
Se stai configurando un database come origine per la replica logica usando see AWS DMS Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS
Nota
Alcune AWS DMS transazioni rimangono inattive per qualche tempo prima che il motore DMS le utilizzi nuovamente. Il parametro idle_in_transaction_session_timeout
in PostgreSQL versione 9.6 e successive consente di mandare in timeout e in errore le transazioni inattive. Non terminare le transazioni inattive quando utilizzi AWS DMS.
Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS
AWS DMS supporta l'acquisizione dei dati di modifica (CDC) mediante la replica logica. Per abilitare la replica logica su un database di origine PostgreSQL autogestito, imposta i seguenti parametri e valori nel file di configurazione postgresql.conf
:
-
Imposta
wal_level = logical
. -
Imposta
max_replication_slots
su un valore maggiore di 1.Imposta il valore
max_replication_slots
in base al numero di attività che desideri eseguire. Ad esempio, per eseguire cinque attività dovrai impostare un minimo di cinque slot. Gli slot si aprono automaticamente non appena viene avviata un'attività e restano aperti anche quando l'attività non è più in esecuzione. Assicurati di eliminare manualmente gli slot aperti. Tieni presente che DMS rilascia automaticamente gli slot di replica che ha creato quando l'attività viene eliminata. -
Imposta
max_wal_senders
su un valore maggiore di 1.Il parametro
max_wal_senders
imposta il numero di attività simultanee che è possibile eseguire. -
Il parametro
wal_sender_timeout
termina le connessioni di replica che sono inattive per un tempo maggiore del numero specificato di millisecondi. L'impostazione predefinita per un database PostgreSQL on-premise è di 60.000 millisecondi (60 secondi). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è un'opzione valida per DMS.Quando si imposta
wal_sender_timeout
su un valore diverso da zero, un'attività DMS con CDC richiede un minimo di 10.000 millisecondi (10 secondi) e non riesce se il valore è inferiore a 10.000. Mantieni il valore inferiore a 5 minuti per evitare ritardi durante un failover multi-AZ di un'istanza di replica DMS.
Alcuni parametri sono statici e possono essere impostati solo all'avvio del server. Qualsiasi modifica alle relative voci nel file di configurazione (per un database autogestito) o nel gruppo di parametri di database (per un database RDS per PostgreSQL) viene ignorata fino al riavvio del server. Per ulteriori informazioni, consultare la documentazione di PostgreSQL
Per ulteriori informazioni sull'abilitazione della CDC, consulta Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica.
Utilizzo di database PostgreSQL AWS gestiti come sorgente DMS
È possibile utilizzare un'istanza database PostgreSQL AWS gestita come origine per. AWS DMSÈ possibile eseguire attività di pieno carico e acquisizione dei dati di modifica (CDC) utilizzando un'origine PostgreSQL gestita da AWS.
Prerequisiti per l'utilizzo di un AWS database PostgreSQL gestito come sorgente DMS
Prima di migrare i dati da un database AWS di origine PostgreSQL gestito, procedi come segue:
-
Si consiglia di utilizzare un account AWS utente con le autorizzazioni minime richieste per l'istanza DB PostgreSQL come account utente per l'endpoint di origine PostgreSQL per. AWS DMS L'utilizzo di un account master è sconsigliato. L'account deve avere il ruolo
rds_superuser
e il ruolords_replication
. Il ruolords_replication
fornisce le autorizzazioni per gestire gli slot logici e per eseguire lo streaming dei dati utilizzando gli slot logici.Assicurati di creare diversi oggetti dall'account utente master per l'account che utilizzi. Per informazioni sulla creazione di questi oggetti, consulta Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master.
-
Se il database di origine è in un cloud privato virtuale (VPC), seleziona il gruppo di sicurezza VPC che fornisce accesso all'istanza database in cui risiede il database. Ciò è necessario affinché l'istanza di replica DMS si connetta correttamente all'istanza database di origine. Quando il database e l'istanza di replica DMS si trovano nello stesso VPC, aggiungi il gruppo di sicurezza appropriato alle relative regole in entrata.
Nota
Alcune AWS DMS transazioni rimangono inattive per qualche tempo prima che il motore DMS le utilizzi nuovamente. Il parametro idle_in_transaction_session_timeout
in PostgreSQL versione 9.6 e successive consente di mandare in timeout e in errore le transazioni inattive. Non terminare le transazioni inattive quando utilizzi AWS DMS.
Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS
AWS DMS supporta CDC sui database Amazon RDS PostgreSQL quando l'istanza DB è configurata per utilizzare la replica logica. La tabella seguente riassume la compatibilità della replica logica di ciascuna versione di PostgreSQL AWS gestita.
Non è possibile utilizzare le repliche di lettura RDS PostgreSQL per CDC (replica continua).
Versione PostgreSQL |
AWS DMS supporto a pieno carico |
AWS DMS supporto CDC |
---|---|---|
Aurora PostgreSQL versione 2.1 compatibile con PostgreSQL 10.5 (o versioni precedenti) |
Sì |
No |
Aurora PostgreSQL versione 2.2 compatibile con PostgreSQL 10.6 (o versioni successive) |
Sì |
Sì |
RDS per PostgreSQL compatibile con PostgreSQL 10.21 (o versioni successive) |
Sì |
Sì |
Per abilitare la replica logica per un'istanza database RDS per PostgreSQL
-
Usa l'account utente AWS principale per l'istanza DB PostgreSQL come account utente per l'endpoint di origine PostgreSQL. L'account utente master dispone dei ruoli necessari che consentono di configurare il CDC.
Se utilizzi un account diverso dall'account utente master, è necessario creare diversi oggetti dall'account utente master per l'account che utilizzi. Per ulteriori informazioni, consulta Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master.
-
Imposta il parametro
rds.logical_replication
su 1 nel gruppo di parametri del cluster di database. Questo parametro statico richiede un riavvio dell'istanza database per avere effetto. Come parte dell'applicazione di questo parametro AWS DMS imposta i parametriwal_level
,max_wal_senders
,max_replication_slots
emax_connections
. Queste modifiche ai parametri possono aumentare la generazione dei WAL (Write Ahead Log), quindi impostare solords.logical_replication
quando si utilizzano slot di replica logica. -
Il parametro
wal_sender_timeout
termina le connessioni di replica che sono inattive per un tempo maggiore del numero specificato di millisecondi. L'impostazione predefinita per un database PostgreSQL AWS gestito è 30000 millisecondi (30 secondi). L'impostazione del valore su 0 (zero) disabilita il meccanismo di timeout ed è un'opzione valida per DMS.Quando si imposta
wal_sender_timeout
su un valore diverso da zero, un'attività DMS con CDC richiede un minimo di 10.000 millisecondi (10 secondi) e non riesce se il valore è compreso tra 0 e 10.000. Mantieni il valore inferiore a 5 minuti per evitare ritardi durante un failover multi-AZ di un'istanza di replica DMS. -
Assicurati che il valore del parametro
max_worker_processes
nel gruppo di parametri del cluster di database sia uguale o superiore ai valori totali combinati dimax_logical_replication_workers
,autovacuum_max_workers
emax_parallel_workers
. Un numero elevato di processi di lavoro in background potrebbe influire sui carichi di lavoro delle applicazioni su istanze di piccole dimensioni. Quindi, monitora le prestazioni del database se imposti un valore dimax_worker_processes
superiore a quello predefinito. -
Quando si utilizza Aurora PostgreSQL come sorgente con CDC, impostare su.
synchronous_commit
ON
Migrazione di un database Amazon RDS per PostgreSQL senza utilizzare l'account utente master
In alcuni casi, si può decidere di non utilizzare l'account utente master per l'istanza di database Amazon RDS PostgreSQL che si sta utilizzando come origine. In questi casi, è necessario creare diversi oggetti per acquisire gli eventi DDL (Data Definition Language). Puoi creare questi oggetti nell'account diverso dall'account master e quindi creare un trigger nell'account utente master.
Nota
Se configuri l'impostazione dell'endpoint CaptureDdls
su false
nell'endpoint di origine, non è necessario creare la tabella e il trigger seguenti nel database di origine.
Per creare questi oggetti, utilizza la procedura seguente.
Per creare oggetti
-
Scegli lo schema in cui devono essere creati gli oggetti. Lo schema predefinito è
public
. Verifica che lo schema esista e che l'account
vi possa accedere.OtherThanMaster
-
Accedi all'istanza database PostgreSQL utilizzando l'account utente diverso dall'account master, qui l'account
.OtherThanMaster
-
Crea la tabella
awsdms_ddl_audit
eseguendo il comando seguente, sostituendo
nel codice e il nome dello schema da utilizzare.objects_schema
CREATE TABLE
objects_schema
.awsdms_ddl_audit ( c_key bigserial primary key, c_time timestamp, -- Informational c_user varchar(64), -- Informational: current_user c_txn varchar(16), -- Informational: current transaction c_tag varchar(24), -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE' c_oid integer, -- For future use - TG_OBJECTID c_name varchar(64), -- For future use - TG_OBJECTNAME c_schema varchar(64), -- For future use - TG_SCHEMANAME. For now - holds current_schema c_ddlqry text -- The DDL query associated with the current DDL event ); -
Crea la funzione
awsdms_intercept_ddl
eseguendo il comando seguente, sostituendo
nel codice e il nome dello schema da utilizzare.objects_schema
CREATE OR REPLACE FUNCTION
objects_schema
.awsdms_intercept_ddl() RETURNS event_trigger LANGUAGE plpgsql SECURITY DEFINER AS $$ declare _qry text; BEGIN if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then SELECT current_query() into _qry; insert intoobjects_schema
.awsdms_ddl_audit values ( default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry ); delete fromobjects_schema
.awsdms_ddl_audit; end if; END; $$; -
Esci dall'account
e collegati con un account che disponga del ruoloOtherThanMaster
rds_superuser
. -
Crea il trigger evento
awsdms_intercept_ddl
utilizzando il seguente comando.CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE
objects_schema
.awsdms_intercept_ddl(); -
Assicurati che tutti gli utenti e i ruoli che accedono a questi eventi dispongano delle autorizzazioni DDL necessarie. Per esempio:
grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public;
Una volta completata la procedura precedente, puoi creare l'endpoint di origine AWS DMS
utilizzando l'account
.OtherThanMaster
Nota
Questi eventi sono attivati dalle istruzioni CREATE TABLE
, ALTER
TABLE
e DROP TABLE
.
Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica
Puoi usare la funzionalità di replica logica nativa di PostgreSQL per abilitare l'acquisizione dei dati di modifica (CDC) durante la migrazione del database per le origini PostgreSQL. Puoi utilizzare questa funzionalità con un'istanza database SQL PostgreSQL autogestita e Amazon RDS per PostgreSQL. Questo approccio riduce i tempi di inattività e aiuta a garantire che il database di destinazione sia sincronizzato con il database PostgreSQL di origine.
AWS DMS supporta CDC per tabelle PostgreSQL con chiavi primarie. Se una tabella non dispone di una chiave primaria, i log write-ahead (WAL) non includono un'immagine precedente della riga di database. In questo caso, DMS non è in grado di aggiornare la tabella. Puoi utilizzare impostazioni di configurazione aggiuntive e l'identità di replica della tabella come soluzione alternativa. Tuttavia, questo approccio può generare log aggiuntivi. Ti consigliamo di utilizzare l'identità di replica delle tabelle come soluzione alternativa solo dopo attenti test. Per ulteriori informazioni, consulta Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS.
Nota
REPLICA IDENTITY FULL è supportato con un plug-in di decodifica logica, ma non è supportato con un plug-in pglogical. Per ulteriori informazioni, consulta la documentazione di pglogical
Per attività a pieno carico e solo CDC e CDC, AWS DMS utilizza slot di replica logici per conservare i log WAL per la replica fino alla decodifica dei log. Al riavvio (non alla ripresa) di un'attività di pieno carico e CDC o un'attività di sola CDC, lo slot di replica viene ricreato.
Nota
Per la decodifica logica, DMS utilizza il plug-in test_decoding o pglogical. Se il plug-in pglogical è disponibile su un database PostgreSQL di origine, DMS crea uno slot di replica utilizzando pglogical, altrimenti viene utilizzato un plug-in test_decoding. Per ulteriori informazioni sul plug-in test-decoding, consulta la documentazione di PostgreSQL
Se il parametro di database max_slot_wal_keep_size
è impostato su un valore non predefinito e restart_lsn
dello slot di replica è inferiore al numero LSN corrente di oltre questa dimensione, l'attività DMS ha esito negativo a causa della rimozione dei file WAL richiesti.
Configurazione del plug-in pglogical
Implementato come estensione PostgreSQL, il plug-in pglogical è un sistema e un modello di replica logica per la replica dei dati selettiva. La tabella seguente identifica le versioni del database PostgreSQL di origine che supportano il plug-in pglogical.
Origine PostgreSQL |
Supporta pglogical |
---|---|
PostgreSQL 9.4 autogestito o versioni successive |
Sì |
Amazon RDS PostgreSQL 9.5 o versioni precedenti |
No |
Amazon RDS PostgreSQL 9.6 o versioni successive |
Sì |
Aurora PostgreSQL da 1.x a 2.5.x |
No |
Aurora PostgreSQL 2.6.x o versioni successive |
Sì |
Aurora PostgreSQL 3.3.x o versioni successive |
Sì |
Prima di configurare pglogical per l'uso con AWS DMS, abilita innanzitutto la replica logica per l'acquisizione dei dati di modifica (CDC) sul tuo database di origine PostgreSQL.
-
Per informazioni sull'abilitazione della replica logica per CDC su database di origine PostgreSQL autogestiti, consulta Abilitazione del CDC utilizzando un database PostgreSQL autogestito come sorgente AWS DMS.
-
Per informazioni sull'abilitazione della replica logica per CDC su database di origine PostgreSQL gestiti da AWS, consulta Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS.
Dopo aver abilitato la replica logica sul database di origine PostgreSQL, segui i passaggi riportati di seguito per configurare pglogical per l'uso con DMS.
Per utilizzare il plugin pglogical per la replica logica su un database sorgente PostgreSQL con AWS DMS
-
Crea un'estensione pglogical sul database PostgreSQL di origine:
-
Imposta il parametro corretto:
-
Per i database PostgreSQL autogestiti, imposta il parametro di database
shared_preload_libraries= 'pglogical'
. -
Per i database PostgreSQL su Amazon RDS e Amazon Aurora edizione compatibile con PostgreSQL, imposta il parametro
shared_preload_libraries
supglogical
nello stesso gruppo di parametri RDS.
-
-
Riavvia il database di origine PostgreSQL.
-
Sul database PostgreSQL, esegui il comando
create extension pglogical;
.
-
-
Per verificare che pglogical sia stato installato, esegui il comando seguente:
select * FROM pg_catalog.pg_extension
È ora possibile creare un' AWS DMS attività che esegua l'acquisizione dei dati di modifica per l'endpoint del database di origine PostgreSQL.
Nota
Se non abiliti pglogical sul database di origine PostgreSQL, AWS DMS utilizza il plug-in test_decoding
per impostazione predefinita. Quando pglogical è abilitato per la decodifica logica, utilizza pglogical per impostazione predefinita. AWS DMS Tuttavia, puoi impostare l'attributo aggiuntivo di connessione PluginName
per utilizzare il plug-in test_decoding
.
Utilizzo dei punti di avvio CDC nativi per impostare un carico CDC di un endpoint di origine PostgreSQL
Per abilitare i punti di avvio CDC nativi con PostgreSQL come origine è necessario impostare l'attributo aggiuntivo di connessione slotName
sul nome di uno slot di replica logica esistente quando si crea l'endpoint. Questo slot di replica logica contiene le modifiche in corso dal momento della creazione dell'endpoint, quindi supporta la replica da un punto precedente nel tempo.
PostgreSQL scrive le modifiche al database nei file WAL che vengono scartati solo quando AWS DMS legge correttamente le modifiche dallo slot di replica logica. Utilizzando gli slot di replica logica è possibile proteggere le modifiche registrate dall'eliminazione prima che vengano utilizzate dal motore di replica.
Tuttavia, a seconda della velocità di modifica e utilizzo, le modifiche presenti in uno slot di replica logica possono causare un utilizzo elevato del disco. Ti consigliamo di impostare gli allarmi relativi all'utilizzo dello spazio nell'istanza PostgreSQL di origine quando vengono utilizzati gli slot di replica logica. Per ulteriori informazioni sull'impostazione dell'attributo di connessione aggiuntivo slotName
, consulta Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS.
La seguente procedura percorre questo approccio in modo più dettagliato.
Per utilizzare un punto di avvio CDC nativo per impostare un caricamento CDC di un endpoint di origine PostgreSQL
-
Identificare lo slot di replica logica utilizzato da un'attività di replica precedente (un'attività padre) che si desidera utilizzare come punto iniziale. Quindi interrogare la visualizzazione
pg_replication_slots
sul database di origine per assicurarsi che questo slot non abbia connessioni attive. In tal caso, risolvile e chiudile prima di procedere.Per i passaggi seguenti, si supponga che lo slot di replica logica sia
abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef
. -
Creare un nuovo endpoint di origine che include la seguente impostazione dell'attributo di connessione aggiuntivo:
slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;
-
Crea una nuova attività solo CDC utilizzando la console o l'API. AWS CLI AWS DMS Ad esempio, utilizzando l'interfaccia a riga di comando è possibile eseguire il seguente comando
create-replication-task
.aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test --source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 --target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 --replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE --migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" --replication-task-settings "file://task-pg.json"
Nel comando precedente vengono impostate le seguenti opzioni:
-
L'opzione
source-endpoint-arn
è impostata sul nuovo valore creato nella fase 2. -
L'opzione
replication-instance-arn
è impostata sullo stesso valore dell'attività padre della fase 1. -
Le opzioni
table-mappings
ereplication-task-settings
sono impostate sugli stessi valori dell'attività padre della fase 1. -
L'opzione
cdc-start-position
è impostata su un valore di posizione iniziale. Per trovare questa posizione iniziale, interrogare la visualizzazionepg_replication_slots
nel database di origine o visualizzare i dettagli della console per l'attività padre nel passaggio 1. Per ulteriori informazioni, consulta Determinazione di un punto di inizio nativo CDC.
Per abilitare la modalità di avvio CDC personalizzata durante la creazione di una nuova attività solo CDC utilizzando la AWS DMS console, procedi come segue:
Nella sezione Impostazioni delle attività scegli Abilita la modalità di avvio CDC personalizzata per Modalità di avvio CDC per le transazioni di origine.
Per Punto di avvio CDC personalizzato per le transazioni di origine scegli Specifica un numero di sequenza del log. Specifica il numero di modifica del sistema o scegli Specifica un checkpoint di ripristino e fornisci un checkpoint di ripristino.
Quando viene eseguita questa attività CDC, AWS DMS genera un errore se lo slot di replica logica specificato non esiste. Genera un errore anche se l'attività non viene creata con un'impostazione valida per
cdc-start-position
. -
Quando utilizzi punti di avvio CDC nativi con il plug-in pglogical e desideri utilizzare un nuovo slot di replica, completa i passaggi di configurazione seguenti prima di creare un'attività di CDC.
Per utilizzare un nuovo slot di replica non creato in precedenza come parte di un'altra attività DMS
-
Crea uno slot di replica come illustrato di seguito:
SELECT * FROM pg_create_logical_replication_slot('
replication_slot_name
', 'pglogical'); -
Dopo che il database ha creato lo slot di replica, recupera e annota i valori restart_lsn e confirmed_flush_lsn per lo slot:
select * from pg_replication_slots where slot_name like 'replication_slot_name';
Tieni presente che il punto di avvio CDC nativo per un'attività di CDC creata dopo lo slot di replica non può essere precedente al valore confirmed_flush_lsn.
Per informazioni sui valori restart_lsn e confirmed_flush_lsn, consulta pg_replication_slots
. -
Crea un nodo pglogical.
SELECT pglogical.create_node(node_name := '
node_name
', dsn := 'your_dsn_name
'); -
Crea due set di replica utilizzando la funzione
pglogical.create_replication_set
. Il primo set di replica tiene traccia degli aggiornamenti e delle eliminazioni per le tabelle con chiavi primarie. Il secondo set di replica tiene traccia solo degli inserimenti e ha lo stesso nome del primo set di replica, con l'aggiunta del prefisso "i".SELECT pglogical.create_replication_set('
replication_slot_name
', false, true, true, false); SELECT pglogical.create_replication_set('ireplication_slot_name
', true, false, false, true); -
Aggiungi una tabella al set di repliche.
SELECT pglogical.replication_set_add_table('
replication_slot_name
', 'schemaname.tablename', true); SELECT pglogical.replication_set_add_table('ireplication_slot_name
', 'schemaname.tablename', true); -
Imposta l'attributo aggiuntivo di connessione seguente quando crei l'endpoint di origine.
PluginName=PGLOGICAL;slotName=
slot_name
;
A questo punto puoi creare un'attività di sola CDC con un punto di avvio nativo PostgreSQL utilizzando il nuovo slot di replica. Per ulteriori informazioni sul plug-in pglogical, consulta la documentazione di pglogical 3.7
Migrazione da PostgreSQL a PostgreSQL utilizzando AWS DMS
Quando si esegue la migrazione da un motore di database diverso da PostgreSQL a un database PostgreSQL, è quasi sempre lo strumento di migrazione migliore da utilizzare AWS DMS . Tuttavia, per una migrazione da un database PostgreSQL a un database PostgreSQL, gli strumenti PostgreSQL possono essere più efficaci.
Utilizzo degli strumenti nativi PostgreSQL per migrare i dati
Ti consigliamo di utilizzare gli strumenti per la migrazione dei database PostgreSQL come pg_dump
nei seguenti casi:
-
Hai una migrazione omogenea, dove effettui la migrazione da un database di origine PostgreSQL a un database PostgreSQL di destinazione.
-
Desideri migrare un intero database.
-
Gli strumenti nativi ti consentono di migrare i dati con tempi di inattività ridotti.
L'utilità pg_dump utilizza il comando COPY per creare uno schema e il dump dei dati di un database PostgreSQL. Lo script del dump generato da pg_dump carica i dati in un database con lo stesso nome e ricrea le tabelle, gli indici e le chiavi esterne. Utilizza il comando pg_restore
e il parametro -d
per ripristinare i dati in un database con un nome diverso.
Se stai migrando dati da un database di origine PostgreSQL in esecuzione su un target Amazon EC2 RDS for PostgreSQL, puoi utilizzare il plug-in pglogical.
Per ulteriori informazioni sull'importazione di un database PostgreSQL in Amazon RDS per PostgreSQL o Amazon Aurora edizione compatibile con PostgreSQL, consulta https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html.
Utilizzo di DMS per la migrazione dei dati da PostgreSQL a PostgreSQL
AWS DMS può migrare i dati, ad esempio, da un database PostgreSQL di origine locale a un'istanza Amazon RDS for PostgreSQL o Aurora PostgreSQL di destinazione. Nella maggior parte dei casi, la migrazione di tipi di dati core o di base PostgreSQL avviene correttamente.
Nota
Quando si replicano tabelle partizionate da un'origine PostgreSQL a una destinazione PostgreSQL, non è necessario menzionare la tabella padre come parte dei criteri di selezione nell'attività DMS. La menzione della tabella padre causa la duplicazione dei dati nelle tabelle figlio sulla destinazione, causando probabilmente una violazione delle chiavi primarie. Selezionando solo le tabelle figlio nella tabella che mappa i criteri di selezione, la tabella padre viene compilata automaticamente.
I tipi di dati supportati nel database di origine ma non supportati nella destinazione potrebbero non essere migrati correttamente. AWS DMS trasmette alcuni tipi di dati come stringhe se il tipo di dati è sconosciuto. Alcuni tipi di dati, ad esempio XML e JSON, possono migrare come file di piccole dimensioni, ma potrebbero non migrare correttamente se i documenti sono di grandi dimensioni.
Quando esegui la migrazione del tipo di dati, tieni presente quanto segue:
-
In alcuni casi, il tipo di dati PostgreSQL NUMERIC(p,s) non specifica la precisione e la scala. Per DMS 3.4.2 e versioni precedenti, DMS utilizza una precisione di 28 e una scala di 6 per impostazione predefinita, NUMERIC(28,6). Ad esempio, il valore 0,611111104488373 dell'origine viene convertito in 0,611111 nella destinazione PostgreSQL.
-
Una tabella con un tipo di dati ARRAY deve avere una chiave primaria. Una tabella con un tipo di dati ARRAY priva di una chiave primaria viene sospesa durante il pieno carico.
La tabella seguente mostra i tipi di dati di origine PostgreSQL e indica se possono essere migrati correttamente:
Tipo di dati | Migrazione corretta | Migrazione parziale | Nessuna migrazione | Commenti |
---|---|---|---|---|
INTEGER | X | |||
SMALLINT | X | |||
BIGINT | X | |||
NUMERIC/DECIMAL(p,s) | X | Dove 0<p<39 e 0<s | ||
NUMERIC/DECIMAL | X | Dove p>38 o p=s=0 | ||
REAL | X | |||
DOUBLE | X | |||
SMALLSERIAL | X | |||
SERIAL | X | |||
BIGSERIAL | X | |||
MONEY | X | |||
CHAR | X | Senza precisione specificata | ||
CHAR(n) | X | |||
VARCHAR | X | Senza precisione specificata | ||
VARCHAR(n) | X | |||
TEXT | X | |||
BYTEA | X | |||
TIMESTAMP | X | I valori infiniti positivi e negativi vengono troncati rispettivamente a "9999-12-31 23:59:59" e "4713-01-01 00:00:00 BC". | ||
TIMESTAMP WITH TIME ZONE | X | |||
DATE | X | |||
TIME | X | |||
TIME WITH TIME ZONE | X | |||
INTERVAL | X | |||
BOOLEAN | X | |||
ENUM | X | |||
CIDR | X | |||
INET | X | |||
MACADDR | X | |||
TSVECTOR | X | |||
TSQUERY | X | |||
XML | X | |||
POINT | X | Tipo di dati spaziali PostGIS | ||
LINE | X | |||
LSEG | X | |||
BOX | X | |||
PATH | X | |||
POLYGON | X | Tipo di dati spaziali PostGIS | ||
CIRCLE | X | |||
JSON | X | |||
ARRAY | X | Richiede la chiave primaria | ||
COMPOSITE | X | |||
RANGE | X | |||
LINESTRING | X | Tipo di dati spaziali PostGIS | ||
MULTIPOINT | X | Tipo di dati spaziali PostGIS | ||
MULTILINESTRING | X | Tipo di dati spaziali PostGIS | ||
MULTIPOLYGON | X | Tipo di dati spaziali PostGIS | ||
GEOMETRYCOLLECTION | X | Tipo di dati spaziali PostGIS |
Migrazione dei tipi di dati spaziali di PostGIS
I dati spaziali identificano le informazioni sulla geometria di un oggetto o di una posizione nello spazio. I database relazionali a oggetti PostgreSQL supportano i tipi di dati spaziali PostGIS.
Prima di migrare gli oggetti formati da dati spaziali PostgreSQL, assicurati che il plug-in PostGIS sia abilitato a livello globale. In questo modo si garantisce la AWS DMS creazione delle colonne di dati spaziali di origine esatte per l'istanza DB di destinazione PostgreSQL.
Per le AWS DMS migrazioni omogenee da PostgreSQL a PostgreSQL, supporta la migrazione di tipi e sottotipi di oggetti dati geometrici e geografici (coordinate geodetiche) di PostGIS come i seguenti:
-
POINT
-
LINESTRING
-
POLYGON
-
MULTIPOINT
-
MULTILINESTRING
-
MULTIPOLYGON
-
GEOMETRYCOLLECTION
Migrazione da Babelfish per Amazon Aurora PostgreSQL utilizzando AWS DMS
Puoi migrare le tabelle di origine PostgreSQL di Babelfish for Aurora su qualsiasi endpoint di destinazione supportato utilizzando. AWS DMS
Quando crei il tuo endpoint di AWS DMS origine utilizzando la console DMS, l'API o i comandi CLI, imposti l'origine su Amazon Aurora PostgreSQL e il nome del database su. babelfish_db
Nella sezione Endpoint Settings, assicurati che sia impostato su Babelfish e che DatabaseModesia impostato sul nome del database Babelfish T-SQL di BabelfishDatabaseNameorigine. Invece di usare la porta TCP Babelfish1433
, usa la porta TCP Aurora PostgreSQL. 5432
È necessario creare le tabelle prima di migrare i dati per assicurarsi che DMS utilizzi i tipi di dati e i metadati delle tabelle corretti. Se non crei le tabelle sulla destinazione prima di eseguire la migrazione, DMS potrebbe creare le tabelle con tipi di dati e autorizzazioni errati.
Aggiunta delle regole di trasformazione all'attività di migrazione
Quando crei un'attività di migrazione per una fonte Babelfish, devi includere regole di trasformazione che assicurino che DMS utilizzi le tabelle di destinazione precreate.
Se hai impostato la modalità di migrazione multi-database quando hai definito il tuo cluster Babelfish per PostgreSQL, aggiungi una regola di trasformazione che rinomina il nome dello schema nello schema T-SQL. Ad esempio, se il nome dello schema T-SQL è dbo
e il nome dello schema Babelfish for PostgreSQL èmydb_dbo
, rinomina lo schema utilizzando una regola di trasformazione. dbo
Per trovare il nome dello schema PostgreSQL, consulta l'architettura Babelfish nella Guida per l'utente di Amazon Aurora.
Se utilizzi la modalità a database singolo, non è necessario utilizzare una regola di trasformazione per rinominare gli schemi di database. I nomi degli schemi PostgreSQL hanno one-to-one una mappatura con i nomi degli schemi nel database T-SQL.
Il seguente esempio di regola di trasformazione mostra come rinominare il nome dello schema da back a: mydb_dbo
dbo
{ "rules": [ { "rule-type": "transformation", "rule-id": "566251737", "rule-name": "566251737", "rule-target": "schema", "object-locator": { "schema-name": "mydb_dbo" }, "rule-action": "rename", "value": "dbo", "old-value": null }, { "rule-type": "selection", "rule-id": "566111704", "rule-name": "566111704", "object-locator": { "schema-name": "mydb_dbo", "table-name": "%" }, "rule-action": "include", "filters": [] } ] }
Limitazioni per l'utilizzo di un endpoint sorgente PostgreSQL con le tabelle Babelfish
Le seguenti limitazioni si applicano quando si utilizza un endpoint sorgente PostgreSQL con tabelle Babelfish:
DMS supporta solo la migrazione dalla versione 16.2/15.6 di Babelfish e successive e dalla versione DMS 3.5.3 e successive.
DMS non replica le modifiche alla definizione delle tabelle Babelfish sull'endpoint di destinazione. Una soluzione alternativa per questa limitazione consiste nell'applicare prima le modifiche alla definizione della tabella sulla destinazione, quindi modificare la definizione della tabella sul sorgente Babelfish.
Quando si creano tabelle Babelfish con il tipo di dati BYTEA, DMS le converte nel tipo di
varbinary(max)
dati durante la migrazione a SQL Server come destinazione.DMS non supporta la modalità Full LOB per i tipi di dati binari. Utilizzate invece la modalità LOB limitata per i tipi di dati binari.
DMS non supporta la convalida dei dati per Babelfish come fonte.
Per l'impostazione delle attività della modalità di preparazione della tabella di Target, utilizza solo le modalità Non fare nulla o Truncate. Non utilizzare la modalità Rilascia tabelle nella destinazione. Quando si utilizza Drop tables on target, DMS può creare le tabelle con tipi di dati errati.
Quando si utilizza la replica continua (CDC o Full load e CDC), imposta l'attributo di connessione
PluginName
aggiuntivo (ECA) su.TEST_DECODING
-
DMS non supporta la replica (CDC o Full load e CDC) della tabella partizionata per Babelfish come sorgente.
Rimozione di AWS DMS artefatti da un database sorgente PostgreSQL
Per acquisire eventi DDL, AWS DMS crea vari artefatti nel database PostgreSQL all'avvio di un'attività di migrazione. Al termine dell'attività è possibile rimuovere gli artefatti.
Per rimuovere gli artefatti, invia le seguenti istruzioni (nell'ordine), dove {AmazonRDSMigration}
è lo schema in cui sono stati creati gli artefatti. L'eliminazione di uno schema deve essere eseguita con estrema attenzione. Non eliminare mai uno schema operativo, soprattutto uno pubblico.
drop event trigger awsdms_intercept_ddl;
Il trigger evento non appartiene a uno schema specifico.
drop function {AmazonRDSMigration}.awsdms_intercept_ddl() drop table {AmazonRDSMigration}.awsdms_ddl_audit drop schema {AmazonRDSMigration}
Impostazioni di configurazione aggiuntive quando si utilizza un database PostgreSQL come origine DMS
Puoi aggiungere ulteriori impostazioni di configurazione durante la migrazione dei dati da un database PostgreSQL in due modi:
-
Puoi aggiungere valori all'attributo di connessione aggiuntivo per acquisire eventi DDL e per specificare lo schema in cui vengono creati gli artefatti operativi del database DDL. Per ulteriori informazioni, consulta Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS.
-
Puoi sostituire i parametri della stringa di connessione. Scegli questa opzione per eseguire una delle seguenti operazioni:
-
AWS DMS Specificare i parametri interni. Questi parametri sono raramente necessari e non sono quindi visualizzati nell'interfaccia utente.
-
Specificate i valori pass-through (passthru) per il client di database specifico. AWS DMS include i parametri pass-through nella stringa di connessione passata al client del database.
-
-
Utilizzando il parametro table-level nelle versioni 9.4 e successive di
REPLICA IDENTITY
PostgreSQL, puoi controllare le informazioni scritte nei log write-ahead (). WALs In particolare, lo fa per WALs identificare le righe che vengono aggiornate o eliminate.REPLICA IDENTITY FULL
registra i vecchi valori di tutte le colonne della riga.REPLICA IDENTITY FULL
Usalo con cautela per ogni tabella poiché neFULL
genera un numero aggiuntivo WALs che potrebbe non essere necessario. Per ulteriori informazioni, consulta ALTER TABLE-REPLICA IDENTITY.
Utilizzo dell'impostazione dell' MapBooleanAsBoolean endpoint PostgreSQL
Puoi utilizzare le impostazioni degli endpoint PostgreSQL per mappare un booleano come tale dall'origine PostgreSQL a una destinazione Amazon Redshift. Per impostazione predefinita, il tipo BOOLEAN viene migrato come varchar(5). È possibile specificare MapBooleanAsBoolean
per consentire a PostgreSQL di migrare il tipo booleano come tale, come mostrato nell'esempio seguente.
--postgre-sql-settings '{"MapBooleanAsBoolean": true}'
Tieni presente che questa impostazione, affinché abbia effetto, deve essere configurata sia sull'endpoint di origine che su quello di destinazione.
Poiché MySQL non ha il tipo BOOLEAN, usa una regola di trasformazione anziché questa impostazione per la migrazione dei dati BOOLEAN su MySQL.
Impostazioni degli endpoint e attributi di connessione aggiuntivi (ECAs) quando si utilizza PostgreSQL come sorgente DMS
Puoi utilizzare le impostazioni dell'endpoint e gli attributi di connessione aggiuntivi (ECAs) per configurare il tuo database di origine PostgreSQL. Le impostazioni degli endpoint vengono specificate quando si crea l'endpoint di origine utilizzando la AWS DMS console o utilizzando il create-endpoint
comando in, con la sintassi JSON. AWS CLI--postgre-sql-settings '{"
EndpointSetting"
:
"value"
, ...
}'
La tabella seguente mostra le impostazioni degli endpoint e le impostazioni ECAs che è possibile utilizzare con PostgreSQL come sorgente.
Nome attributo | Descrizione |
---|---|
|
Per acquisire eventi DDL, AWS DMS crea vari artefatti nel database PostgreSQL all'avvio dell'attività. Successivamente puoi rimuovere gli artefatti, come descritto in Rimozione di AWS DMS artefatti da un database sorgente PostgreSQL. Se il valore è impostato su false, non è necessario creare tabelle o trigger nel database di origine. Gli eventi DDL in streaming vengono acquisiti. Valore predefinito: Valori validi: true/false Esempio: |
|
Utilizzato per controllare la modalità di replica delle transazioni monolitiche con numeri di sequenza di log () duplicati. LSNs Quando questo parametro è impostato Valore predefinito: Valori validi: false/true Esempio: |
|
Imposta lo schema in cui vengono creati gli artefatti del database DDL operativo. Valore predefinito: pubblico Valori validi: stringa Esempio: |
|
Disattiva il filtro sorgente Unicode con PostgreSQL, per i valori passati al filtro delle regole di selezione sui valori delle colonne Source Endpoint. Per impostazione predefinita, DMS esegue confronti tra i filtri di origine utilizzando una stringa Unicode, il che può far sì che le ricerche ignorino gli indici nelle colonne di testo e rallentino le migrazioni. Il supporto Unicode deve essere disabilitato solo quando si utilizza una regola di selezione, il filtro si trova su una colonna di testo del database di origine indicizzata. Valore predefinito: false Valori validi: true/false Esempio: |
|
Imposta il timeout dell'istruzione del client per l'istanza PostgreSQL in secondi. Il valore predefinito è 60 secondi. Esempio: |
|
Se è impostato su Se un'attività è impostata sulla modalità LOB limitata e questa opzione è impostata su true, l'operazione ha esito negativo invece di troncare i dati LOB. Valore predefinito: false Valori validi: booleani Esempio: |
|
Questo attributo aggiuntivo di connessione imposta il numero di righe che il cursore recupera durante l'operazione pieno carico. A seconda delle risorse disponibili nell'istanza di replica, è possibile aumentare o diminuire il valore. Valore predefinito: Valori validi: numero Esempio ECA: |
|
La funzione heartbeat WAL imita una transazione fittizia, in modo che gli slot di replica logica inattivi non si aggrappino ai vecchi log WAL che provocano situazioni di pieno spazio di archiviazione sull'origine. Questo heartbeat mantiene Valore predefinito: Valori validi: true/false Esempio: |
|
Imposta la frequenza heartbeat WAL (in minuti). Valore predefinito: Valori validi: numero Esempio: |
|
Imposta lo schema in cui vengono creati gli artefatti di heartbeat. Valore predefinito: Valori validi: stringa Esempio: |
|
Per impostazione predefinita, mappa JSONB su NCLOB. AWS DMS È possibile specificare Esempio: |
|
Per impostazione predefinita, AWS DMS mappa VARCHAR su WSTRING. È possibile specificare
Esempio: |
|
Questo parametro tratta le colonne con tipi di dati NUMERIC illimitati come STRING per eseguire correttamente la migrazione senza perdere la precisione del valore numerico. Usa questo parametro solo per la replica dall'origine PostgreSQL alla destinazione PostgreSQL o ai database con compatibilità PostgreSQL. Valore predefinito: Valori validi: Esempio: L'utilizzo di questo parametro può comportare un peggioramento delle prestazioni di replica a causa della trasformazione da valore numerico a stringa e di nuovo a valore numerico. Questo parametro è supportato per l'uso da DMS versione 3.4.4 e successive NotaUtilizza L'uso di Non utilizzare |
|
Specifica il plug-in da utilizzare per creare uno slot di replica. Valori validi: Esempio: |
|
Imposta il nome di uno slot di replica logica creato in precedenza per un caricamento CDC dell'istanza di origine PostgreSQL. Se utilizzato con il parametro di Per ulteriori informazioni su come impostare il parametro della richiesta Valori validi: stringa Esempio: |
|
Questo attributo di connessione aggiuntivo (ECA) definisce la dimensione massima di una colonna di dati definita come tipo VarChar senza un identificatore di lunghezza massima. L'impostazione predefinita è 8000 byte. Il valore massimo è 10485760 byte. |
Limitazioni all'utilizzo di un database PostgreSQL come origine DMS
Quando si utilizza un database PostgreSQL come origine per AWS DMS, si applicano le seguenti limitazioni:
-
AWS DMS non funziona con Amazon RDS for PostgreSQL 10.4 o Amazon Aurora PostgreSQL 10.4 come origine o destinazione.
-
Una tabella acquisita deve avere una chiave primaria. Se una tabella non ha una chiave primaria, ignora le operazioni di record DELETE e UPDATE per quella tabella. AWS DMS Come soluzione alternativa, consulta Abilitazione dell'acquisizione dei dati di modifica (CDC) mediante la replica logica.
Nota: non è consigliabile eseguire la migrazione senza una chiave primaria/un indice univoco, altrimenti si applicano limitazioni aggiuntive come nessuna funzionalità di applicazione in batch, funzionalità LOB completa, convalida dei dati e l'impossibilità di replicare in modo efficiente sulla destinazione Redshift.
-
AWS DMS ignora il tentativo di aggiornare un segmento di chiave primaria. In questi casi, la destinazione identifica l'aggiornamento come un'operazione che non ha aggiornato righe. Tuttavia, poiché i risultati di aggiornamento di una chiave primaria in PostgreSQL sono imprevedibili, non vengono scritti record nella tabella delle eccezioni.
-
AWS DMS non supporta l'opzione Avvia processo di modifica da Timestamp run.
-
AWS DMS non replica le modifiche risultanti da operazioni di partizione o sottopartizione (, o).
ADD
DROP
TRUNCATE
-
La replica di più tabelle con lo stesso nome, in cui ogni nome presenta una differenza tra maiuscole e minuscole (ad esempio, table1 e Table1) può causare un comportamento TABLE1 imprevedibile. A causa di questo problema, AWS DMS non supporta questo tipo di replica.
-
Nella maggior parte dei casi, AWS DMS supporta l'elaborazione delle modifiche delle istruzioni DDL CREATE, ALTER e DROP per le tabelle. AWS DMS non supporta questa elaborazione delle modifiche se le tabelle sono contenute in un blocco interno del corpo di una funzione o di una procedura o in altri costrutti annidati.
Ad esempio, la seguente modifica non viene acquisita.
CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void LANGUAGE plpgsql AS $$ BEGIN create table attu.distributors1(did serial PRIMARY KEY,name varchar(40) NOT NULL); END; $$;
-
Attualmente, i tipi di dati
boolean
in un'origine PostgreSQL vengono migrati a una destinazione SQL Server come tipo di datibit
con valori incoerenti. Come soluzione alternativa, precrea la tabella con un tipo diVARCHAR(1)
dati per la colonna (o chiedi a AWS DMS di creare la tabella). Quindi fai in modo che l'elaborazione a valle tratti una «F» come False e una «T» come True. -
AWS DMS non supporta l'elaborazione delle modifiche delle operazioni TRUNCATE.
-
Il tipo di dati OID LOB non viene migrato nella destinazione.
AWS DMS supporta il tipo di dati PostGIS solo per migrazioni omogenee.
-
Se la tua fonte è un database PostgreSQL locale o su un'istanza EC2 Amazon, assicurati che il plug-in di output test_decoding sia installato sull'endpoint di origine. Puoi trovare questo plug-in nel pacchetto contrib PostgreSQL. Per ulteriori informazioni sul plug-in di test-decoding, consulta la documentazione di PostgreSQL
. -
AWS DMS non supporta l'elaborazione delle modifiche per impostare e annullare i valori predefiniti delle colonne (utilizzando la clausola ALTER COLUMN SET DEFAULT nelle istruzioni ALTER TABLE).
-
AWS DMS non supporta l'elaborazione delle modifiche per impostare l'annullabilità delle colonne (utilizzando la clausola ALTER COLUMN [SET|DROP] NOT NULL nelle istruzioni ALTER TABLE).
-
Quando la replica logica è abilitata, il numero massimo di modifiche conservate in memoria per transazione è 4 MB. Dopodiché, le modifiche vengono riversate su disco. Di conseguenza
ReplicationSlotDiskUsage
aumenta erestart_lsn
non avanza finché la transazione non viene completata o interrotta e il rollback non termina. Poiché si tratta di una transazione lunga, il rollback può richiedere tempi lunghi. Pertanto, evita transazioni di lunga durata o molte sottotransazioni quando la replica logica è abilitata. Prova invece a suddividere la transazione in diverse transazioni più piccole.Nelle versioni 13 e successive di Aurora PostgreSQL, è possibile ottimizzare il
logical_decoding_work_mem
parametro per controllare quando le fuoriuscite di DMS modificano i dati sul disco. Per ulteriori informazioni, consulta Versare file in Aurora PostgreSQL. -
Una tabella con un tipo di dati ARRAY deve avere una chiave primaria. Una tabella con un tipo di dati ARRAY priva di una chiave primaria viene sospesa durante il pieno carico.
-
AWS DMS non supporta la replica di tabelle partizionate. Quando viene rilevata una tabella partizionata, avviene quanto segue:
-
L'endpoint fornisce un report di tabelle padre e figlio.
-
AWS DMS crea la tabella sulla destinazione come tabella normale con le stesse proprietà delle tabelle selezionate.
-
Se la tabella padre nel database di origine ha lo stesso valore di chiave primaria delle tabelle figlio, viene generato un errore di "chiavi duplicate".
-
-
Per replicare le tabelle partizionate da un'origine PostgreSQL a una destinazione PostgreSQL, crea manualmente le tabelle padre e figlio nella destinazione. Quindi definisci un'attività separata per la replica su tali tabelle. In questo caso, imposta la configurazione dell'attività su Tronca prima di caricare.
-
Il tipo di dati PostgreSQL
NUMERIC
non viene fissato nelle dimensioni. Quando si trasferiscono dati di tipoNUMERIC
ma senza precisione e dimensioni, per impostazione predefinita DMS usaNUMERIC(28,6)
(una precisione di 28 e dimensione 6). Ad esempio, il valore 0.611111104488373 dell'origine viene convertito in 0.611111 nella destinazione PostgreSQL. -
AWS DMS supporta Aurora PostgreSQL Serverless V1 come origine solo per attività a pieno carico. AWS DMS supporta Aurora PostgreSQL Serverless V2 come fonte per attività a pieno carico, a pieno carico e solo CDC e CDC.
-
AWS DMS non supporta la replica di una tabella con un indice univoco creato con una funzione di coalescenza.
-
Se la definizione della chiave primaria su origine e destinazione non corrisponde, i risultati della replica potrebbero essere imprevedibili.
-
Quando si utilizza la funzionalità di caricamento parallello, la segmentazione delle tabelle in base a partizioni o sottopartizioni non è supportata. Per ulteriori informazioni sul caricamento parallelo, consulta Utilizzo del caricamento parallelo per le tabelle, le viste e le raccolte selezionate.
-
AWS DMS non supporta i vincoli differiti.
-
AWS DMS la versione 3.4.7 supporta PostgreSQL 14.x come sorgente con queste limitazioni:
-
AWS DMS non supporta l'elaborazione delle modifiche dei commit in due fasi.
-
AWS DMS non supporta la replica logica per lo streaming di lunghe transazioni in corso.
-
-
AWS DMS non supporta CDC per Amazon RDS Proxy for PostgreSQL come sorgente.
-
Quando si utilizzano filtri di origine che non contengono una colonna di chiave primaria, le operazioni
DELETE
non verranno acquisite. -
Se il database di origine è anche la destinazione di un altro sistema di replica di terze parti, le modifiche DDL potrebbero non migrare durante CDC in quanto potrebbero impedire l'attivazione del trigger dell'evento
awsdms_intercept_ddl
. Per aggirare la situazione, modifica il trigger nel database di origine come segue:alter event trigger awsdms_intercept_ddl enable always;
-
AWS DMS non supporta il cluster di database CDC per Amazon RDS Multi-AZ per PostgreSQL come sorgente, poiché i cluster di database RDS per PostgreSQL Multi-AZ non supportano la replica logica.
Tipi di dati di origine per PostgreSQL
La tabella seguente mostra i tipi di dati sorgente PostgreSQL supportati durante l' AWS DMS utilizzo e la mappatura predefinita ai tipi di dati. AWS DMS
Per informazioni su come visualizzare il tipo di dati mappato nella destinazione, consulta la sezione relativa all'endpoint di destinazione che stai utilizzando.
Per ulteriori informazioni sui tipi di AWS DMS dati, vedere. Tipi di dati per AWS Database Migration Service
Tipi di dati PostgreSQL |
Tipi di dati DMS |
---|---|
INTEGER |
INT4 |
SMALLINT |
INT2 |
BIGINT |
INT8 |
NUMERIC (p,s) |
Se la precisione è compresa tra 0 e 38, utilizzare NUMERIC. Se la precisione è 39 o maggiore, utilizzare STRING. |
DECIMAL(P,S) |
Se la precisione è compresa tra 0 e 38, utilizzare NUMERIC. Se la precisione è 39 o maggiore, utilizzare STRING. |
REAL |
REAL4 |
DOUBLE |
REAL8 |
SMALLSERIAL |
INT2 |
SERIAL |
INT4 |
BIGSERIAL |
INT8 |
MONEY |
NUMERIC(38,4) Il tipo di dati MONEY è mappato su FLOAT in SQL Server. |
CHAR |
WSTRING (1) |
CHAR(N) |
WSTRING (n) |
VARCHAR(N) |
WSTRING (n) |
TEXT |
NCLOB |
CITEXT |
NCLOB |
BYTEA |
BLOB |
TIMESTAMP |
DATETIME |
TIMESTAMP WITH TIME ZONE |
DATETIME |
DATE |
DATE |
TIME |
TIME |
TIME WITH TIME ZONE |
TIME |
INTERVAL |
STRING (128): 1 YEAR, 2 MONTHS, 3 DAYS, 4 HOURS, 5 MINUTES, 6 SECONDS |
BOOLEAN |
CHAR (5) false o true |
ENUM |
STRING (64) |
CIDR |
STRING (50) |
INET |
STRING (50) |
MACADDR |
STRING (18) |
BIT(n) |
STRING (n) |
BIT VARYING (n) |
STRING (n) |
UUID |
STRING |
TSVECTOR |
CLOB |
TSQUERY |
CLOB |
XML |
CLOB |
POINT |
STRING (255) "(x,y)" |
LINE |
STRING (255) "(x,y,z)" |
LSEG |
STRING (255) "((x1,y1),(x2,y2))" |
BOX |
STRING (255) "((x1,y1),(x2,y2))" |
PATH |
CLOB "((x1,y1),(xn,yn))" |
POLYGON |
CLOB "((x1,y1),(xn,yn))" |
CIRCLE |
STRING (255) "(x,y),r" |
JSON |
NCLOB |
JSONB |
NCLOB |
ARRAY |
NCLOB |
COMPOSITE |
NCLOB |
HSTORE |
NCLOB |
INT4INTERVALLO |
STRING (255) |
INT8INTERVALLO |
STRING (255) |
NUMRANGE |
STRING (255) |
STRRANGE |
STRING (255) |
Utilizzo dei tipi di dati di origine LOB per PostgreSQL
Le dimensioni di colonna PostgreSQL influenzano la conversione dei tipi di dati LOB PostgreSQL in tipi di dati AWS DMS . Per utilizzare questa funzione, effettua la procedura riportata di seguito per i seguenti tipi di dati AWS DMS :
-
BLOB: imposta Limita dimensioni LOB a sul valore di Dimensione massima dei LOB (KB) al momento della creazione dell'attività.
-
CLOB — La replica gestisce ogni personaggio come un UTF8 personaggio. Pertanto, individua il testo con il maggiore numero di caratteri nella colonna
max_num_chars_text
. Utilizza questa lunghezza per specificare il valore di Limita dimensioni LOB a. Se i dati includono caratteri a 4 byte, moltiplicare per 2 per specificare il valore di Limit LOB size to (Limita dimensioni LOB a), che è espresso in byte. In questo caso, Limit LOB size to (Limita dimensioni LOB a) è uguale amax_num_chars_text
moltiplicato per 2. -
NCLOB: la replica gestisce ogni carattere come carattere a due byte. Pertanto, individua il testo con il maggiore numero di caratteri nella colonna (
max_num_chars_text
) e moltiplicarlo per 2. Questa operazione viene eseguita per specificare il valore di Limita dimensioni LOB a. In questo caso, Limit LOB size to (Limita dimensioni LOB a) è uguale amax_num_chars_text
moltiplicato per 2. Se i dati includono caratteri a 4 byte, moltiplicare ancora per 2. In questo caso, Limit LOB size to (Limita dimensioni LOB a) è uguale amax_num_chars_text
moltiplicato per 4.