Quali sono le best practice da utilizzare durante la migrazione dei database PostgreSQL a un database RDS per PostgreSQL di destinazione utilizzando AWS DMS?

Breve descrizione

Quando esegui la migrazione di database omogenei utilizzando AWS DMS, copia i dati iniziali utilizzando gli strumenti nativi del tuo motore, come pg_dump. Quindi, esegui pg_restore sulla destinazione. È inoltre possibile utilizzare la replica logica e il comando COPY (COPIA). Per maggiori informazioni, consulta l'articolo Best practices for migrating PostgreSQL databases to Amazon RDS and Amazon Aurora (Best practice per la migrazione dei database PostgreSQL ad Amazon RDS e Amazon Aurora).

Per eseguire la migrazione da un database RDS per PostgreSQL a un altro database RDS per PostgreSQL, acquisisci uno snapshot e poi ripristinalo come destinazione. Per ulteriori informazioni, consulta Migrazione di uno snapshot di un'istanza database di RDS per PostgreSQL a un cluster di database Aurora PostgreSQL.

Tieni presente che la migrazione a pieno carico di tutti i tuoi dati da un database di origine a un database di destinazione utilizzando AWS DMS può richiedere molto tempo. Potrebbero verificarsi dei ritardi dovuti a fattori quali:

• Larghezza di banda
• Capacità dell'origine di inviare grandi quantità di dati
• Capacità del motore di replica di archiviare, elaborare e inoltrare carichi di massa
• Capacità della destinazione di utilizzare i dati dall'origine

In confronto, la replica delle modifiche contiene solo le modifiche dall'origine alla destinazione, quindi carichi di lavoro come questo possono essere molto leggeri.

Crea e determina il numero di sequenza del registro (LSN) corrente

Prima di eseguire un backup, è necessario ottenere un indicatore per indicare all'attività AWS DMS da dove iniziare la migrazione delle modifiche.

Nel database PostgreSQL di origine, esegui queste query per creare e determinare il numero LSN corrente.

Crea lo slot di replica:

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

Ottieni il numero LSN corrente:

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

Il comando Restart_LSN indica all'attività AWS DMS da dove iniziare la migrazione delle modifiche dall'origine alla destinazione.

Risoluzione

Utilizza queste best practice per la migrazione dei dati da PostgreSQL a PostgreSQL utilizzando le attività AWS DMS.

Non utilizzare chiavi esterne e trigger durante la migrazione a pieno carico

Quando è in corso la migrazione a pieno carico, assicurati che le chiavi esterne e i trigger non siano inclusi nella migrazione. AWS DMS esegue la migrazione delle tabelle in ordine alfabetico, ma non sa distinguere tra le tabelle padre e le tabelle figlio. Pertanto, AWS DMS potrebbe tentare prima di migrare le tabelle figlio. AWS DMS interrompe poi la migrazione delle tabelle a causa di una violazione della chiave esterna. Quindi, sopprimi o non includere le chiavi esterne sulla destinazione durante la migrazione.

I trigger non devono mai essere presenti su una destinazione durante la migrazione perché eseguono diversi processi che potrebbero danneggiare i dati sulla destinazione. Aggiungi eventuali trigger alla conversione.

Attiva la modalità LOB completa durante la migrazione dei dati JSON

Quando esegui la migrazione di LOB sotto forma di JSON, attiva la modalità LOB completa in modo che il formato JSON non venga troncato. Se utilizzi la modalità LOB limitata, è possibile che si verifichi un troncamento dei dati. Quindi, AWS DMS si assicura che la tabella abbia esito negativo perché il formato JSON è errato.

Assicurati che il campo della chiave primaria non sia un tipo di dati TEXT

Verifica che il campo della chiave primaria non sia TEXT, soprattutto se è attivata la modalità LOB completa. Potresti riscontrare DUPLICATI di NULL perché AWS DMS tratta il tipo di dati TEXT come LOB. Pertanto, durante la migrazione a pieno carico, AWS DMS tenta di rendere la chiave primaria NULL e quindi segnala un duplicato perché ci sono molte colonne di testo con lo stesso valore. L'errore non viene mai trattato come "NULL non consentito sulla chiave primaria", ma come duplicato. Questo può essere un problema difficile da scoprire e risolvere, quindi conferma sempre che il campo della chiave primaria non sia TEXT per evitare che si verifichi.

Consenti ad AWS DMS di creare tabelle di destinazione

Se è in corso la migrazione a pieno carico, consenti ad AWS DMS di creare tabelle sulla destinazione. Quando AWS DMS crea tabelle, crea anche i campi corrispondenti senza valori DEFAULT per le colonne. I valori predefiniti sulle colonne possono causare comportamenti imprevisti in AWS DMS. Ad esempio, SERIAL impedisce la migrazione di AWS DMS perché questo campo desidera creare automaticamente un valore. Guarda questo esempio:

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

Se la destinazione è strutturata come questo esempio, i componenti interni di PostgreSQL vogliono generare il valore della colonna ID. Tuttavia, l'origine contiene anche un valore per INSERT che causa un problema. Quindi assicurati che i DEFAULT non facciano parte della destinazione durante la migrazione.

Definisci le partizioni come tabelle di origine nelle mappature delle tabelle delle attività

Quando esegui la migrazione di tabelle partizionate, assicurati di definire le partizioni come tabelle di origine nelle mappature delle tabelle delle attività, non come tabelle padre. Questo perché i registri WAL conservano le informazioni della tabella partizionata. Le tabelle padre devono essere utilizzate solo durante la migrazione a pieno carico, quindi non utilizzare le tabelle padre per la fase CDC. Se definisci le tabelle padre durante il CDC, potresti riscontrare errori duplicati che influiscono sulla migrazione.

Inoltre, quando esegui la mappatura delle tabelle di destinazione, assicurati che tutte le partizioni vengano rimappate sulla tabella padre. Ciò significa che la tabella padre viene utilizzata per la distribuzione automatica nelle sue partizioni.

Definisci tutti i facet sull'origine quando utilizzi PGLOGICAL

Quando utilizzi PGLOGICAL per la migrazione, assicurati di definire ogni facet richiesto nell'origine. Se salti un'area, noterai un comportamento imprevisto. I problemi che si verificano a seguito di ciò sono molto difficili da risolvere, quindi verifica di aver definito queste aree prima di iniziare la migrazione con PGLOGICAL.

Per Amazon RDS, definisci i seguenti elementi:

Gruppo di parametri:

shared_preload_libraries = pglocical

Livello del database:

create extension pglogical;

Per on-premise, definisci i seguenti elementi:

postgresql.conf:

shared_preload_libraries = pglogical

Livello del database:

create extension pglogical;

Assicurati che tutti i plugin PG definiti nell'origine siano definiti sulla destinazione

Assicurati che tutti i plugin PG che definisci sull'origine siano definiti anche sulla destinazione. Ciò contribuisce alla compatibilità e all'elaborazione regolare dei dati.

Assicurati che le attività non rimangano nello stato Stop/Error (Arresto/Errore)

Quando le attività impiegano molto tempo negli stati Stop (Arresto) o Error (Errore), lo spazio di archiviazione si riempie nello slot di replica.

Elimina dall'origine gli slot di replica creati manualmente

Se hai creato manualmente degli slot di replica, eliminali dall'origine al termine della migrazione. Se gli slot di replica rimangono nell'origine, si accumulano in termini di dimensioni e lo spazio di archiviazione si riempie.

Migra le tabelle con una chiave primaria o un indice univoco

È consigliabile assicurarsi che le tabelle di cui si esegue la migrazione dispongano di una chiave primaria o un indice univoco. Se una tabella non dispone di una chiave primaria, le istruzioni UPDATE (AGGIORNA) e DELETE (ELIMINA) potrebbero non essere applicate alla tabella perché non sono registrate nei registri WAL. Per le tabelle senza chiave primaria, utilizza REPLICATE IDENTITY FULL, ma tieni presente che questo genera molte informazioni nei registri.

---

Informazioni correlate

Using a PostgreSQL database as an AWS DMS source (Utilizzo di un database PostgreSQL come origine AWS DMS)

Targets for data migration (Destinazioni per la migrazione dei dati)