Creazione di attività per la replica continua mediante AWS DMS

Puoi creare un'attività AWS DMS che acquisisca le modifiche in corso dal datastore di origine. Puoi eseguire tale acquisizione durante la migrazione dei dati. Puoi inoltre creare un'attività che acquisisce le modifiche in corso dopo aver completato la migrazione iniziale (di caricamento completo) a un datastore di destinazione supportato. Questo processo è denominato replica continua o Change Data Capture (CDC). AWS DMS utilizza questo processo quando replica le modifiche in corso da un datastore di origine. Questo processo funziona raccogliendo le modifiche nei log di database mediante l'API nativa del motore di database.

Nota

Puoi eseguire la migrazione delle viste solo utilizzando le attività di caricamento completo. Se l'attività è solo CDC o di caricamento completo che avvia CDC dopo il completamento, la migrazione include solo le tabelle dall'origine. Utilizzando un'attività di solo caricamento completo, puoi eseguire la migrazione delle viste o una combinazione di tabelle e viste. Per ulteriori informazioni, consulta Specifica della selezione delle tabelle e delle regole di trasformazione tramite JSON.

Ogni motore di origine ha requisiti di configurazione specifici per esporre questo flusso di modifica a un determinato account utente. La maggior parte dei motori richiede alcune configurazioni aggiuntive per consentire al processo di acquisizione di utilizzare i dati delle modifiche in modo significativo, senza perdita di dati. Ad esempio, Oracle richiede l'aggiunta di log supplementare e MySQL richiede la registrazione binaria a livello di riga (registrazione binaria).

Per leggere le modifiche in corso dal database di origine, AWS DMS utilizza le operazioni API specifiche del motore per leggere le modifiche dai log delle transazioni del motore di origine. Di seguito sono riportati alcuni esempi del modo in cui AWS DMS esegue tale operazione:

• Per Oracle, AWS DMS utilizza l'API Oracle LogMiner o l'API Binary Reader (API bfile) per leggere le modifiche in corso. AWS DMS legge le modifiche in corso dai log di archivio o redo online in base al numero di modifica sistema (SCN, System Change Number).

• Per Microsoft SQL Server, AWS DMS utilizza MS-Replication o MS-CDC per scrivere le informazioni nel log delle transazioni di SQL Server. Utilizza quindi le funzioni fn_dump_dblog() o fn_dblog() in SQL Server per leggere le modifiche nel log delle transazioni in base al numero di sequenza dei log (LSN, Log Sequence Number).

• Per MySQL, AWS DMS legge le modifiche dai log binari basati su riga (binlog) e migra tali modifiche alla destinazione.

• Per PostgreSQL, AWS DMS imposta slot di replica logica e utilizza il plugin test_decoding per leggere le modifiche dall'origine e migrarle alla destinazione.

• Per Amazon RDS come origine, è consigliabile assicurarsi che i backup siano abilitati per configurare CDC. È inoltre consigliabile assicurarsi che il database di origine sia configurato in modo da mantenere i log delle modifiche per un periodo di tempo sufficiente; in genere, 24 ore sono sufficienti. Per le impostazioni specifiche di ciascun endpoint, consulta le seguenti risorse:

  • Amazon RDS per Oracle: Configurazione di una fonte Oracle gestita per AWSAWS DMS.

  • Amazon RDS per MySQL e Aurora MySQL: Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS.

  • Amazon RDS per SQL Server: Configurazione della replica continua su un'istanza database di SQL Server nel cloud.

  • Amazon RDS per PostgreSQL e Aurora PostgreSQL: PostgreSQL mantiene automaticamente il WAL richiesto.

Esistono due tipi di attività di replica continua:

• Pieno carico e CDC: l'attività esegue la migrazione dei dati esistenti, quindi aggiorna il database di destinazione in base alle modifiche al database di origine.

• sola CDC: l'attività migra le modifiche in corso una volta che sono presenti dati nel database di destinazione.

Esecuzione della replica a partire da un punto di inizio CDC

Puoi avviare un'attività di replica continua di AWS DMS (solo CDC) da diversi punti. Questi sono i seguenti:

• Da un'ora di inizio CDC personalizzata: puoi utilizzare la AWS Management Console o AWS CLI per fornire a AWS DMS un timestamp relativo al momento in cui desideri che la replica venga avviata. AWS DMS avvia quindi un'attività di replica continua a partire da quest'ora di inizio CDC personalizzata. AWS DMS converte il timestamp specificato (in UTC) in un punto di inizio nativo, ad esempio un LSN per SQL Server o un SCN per Oracle. AWS DMS utilizza metodi specifici del motore per determinare il punto in cui avviare l'attività di migrazione in base al flusso di modifica del motore di origine.

  Nota

  Solo impostando l'attributo di connessione StartFromContext sul timestamp richiesto, Db2 come origine offre un orario di inizio CDC personalizzato.

  PostgreSQL come origine non supporta un'ora di inizio CDC personalizzata. Questo è dovuto al fatto che il motore di database PostgreSQL non dispone di un modo per mappare un timestamp a un LSN o SCN come Oracle e SQL Server.

• Da un punto di inizio nativo CDC: puoi inoltre iniziare da un punto nativo nel log delle transazioni del motore di origine. In alcuni casi, potresti preferire questo approccio perché un timestamp può indicare più punti nativi nel log delle transazioni. AWS DMS supporta questa funzionalità per i seguenti endpoint di origine:

  • SQL Server

  • PostgreSQL

  • Oracle

  • MySQL

  • MariaDB

Quando l'attività viene creata, AWS DMS contrassegna il punto di inizio del CDC e non può essere modificato. Per usare un punto di inizio del CDC diverso, devi creare una nuova attività.

Determinazione di un punto di inizio nativo CDC

Un punto di inizio nativo CDC è un punto nel log del motore di database che definisce un'ora in cui puoi iniziare l'operazione CDC. Ad esempio, supponiamo che un dump del blocco dei dati venga applicato alla destinazione. Puoi cercare il punto di inizio nativo per l'attività di sola replica continua. Per evitare incongruenze nei dati, scegli con attenzione il punto di inizio per l'attività di sola replica. DMS acquisisce le transazioni iniziate dopo il punto di inizio del CDC scelto.

Di seguito sono riportati alcuni esempi di come puoi individuare il punto di inizio nativo CDC dai motori di origine supportati:

SQL Server

In SQL Server, un numero di sequenza di log (LSN, Log Sequence Number) è composto da tre parti:

• Numero di sequenza del file di log virtuale (VLF, Virtual Log File)

• Offset di avvio di un blocco di log

• Numero slot

Di seguito è riportato un LSN di esempio: 00000014:00000061:0001

Per ottenere il punto di inizio per un'attività di migrazione SQL Server in base alle impostazioni di backup del log delle transazioni, utilizza la funzione fn_dump_dblog() o fn_dblog() in SQL Server.

Per utilizzare il punto di inizio nativo del CDC con SQL Server, crea una pubblicazione su qualsiasi tabella che partecipa alla replica continua. AWS DMS crea la pubblicazione automaticamente quando si utilizza CDC senza usare un punto di inizio nativo del CDC.

PostgreSQL

Per il database di origine PostgreSQL puoi utilizzare un checkpoint di ripristino CDC. Questo valore del checkpoint viene generato in vari punti quando viene eseguita un'attività di replica in corso per il database di origine (l'attività padre). Per ulteriori informazioni sui checkpoint in generale, consulta Utilizzo di un checkpoint come punto di inizio CDC.

Per identificare il checkpoint da utilizzare come punto di partenza nativo, utilizzare la visualizzazione pg_replication_slots del database o i dettagli della panoramica dell'attività principale dalla pagina AWS Management Console.

Per trovare i dettagli generali per l'attività padre sulla console

1. Accedere alla AWS Management Console e aprire la console AWS DMS all’indirizzo https://console.aws.amazon.com/dms/v2/.

   Se hai eseguito l'accesso come utente IAM, verifica di disporre delle autorizzazioni appropriate per accedere a AWS DMS. Per ulteriori informazioni sulle autorizzazioni richieste, consulta Autorizzazioni IAM necessarie per utilizzare AWS DMS.

2. Dal riquadro di navigazione, scegliere Attività di migrazione del database.

3. Scegliere l'attività principale dall'elenco nella pagina Attività di migrazione del database . Verrà visualizzata la pagina dell'attività principale che mostra i dettagli della panoramica.

4. Individuare il valore del checkpoint in Change data capture (CDC), posizione iniziale Change Data Capture (CDC) e punto di ripristino Change Data Capture (CDC).

   Il valore appare simile all'esempio seguente:

   checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

   Qui, il componente 4AF/B00000D0 è quanto necessario per specificare questo punto di avvio CDC nativo. Impostare il parametro CdcStartPosition API DMS su questo valore quando si crea l'attività CDC per avviare la replica in questo punto iniziale per l'origine PostgreSQL. Per ulteriori informazioni sull'utilizzo dell'AWS CLI per creare quest'attività CDC, consulta Abilitazione del CDC con un' AWS istanza DB PostgreSQL gestita con AWS DMS.

Oracle

Un numero di modifica sistema (SCN, System Change Number) è un timestamp interno logico utilizzato dai database Oracle. Gli SCN ordinano gli eventi che si verificano all'interno del database, operazione necessaria per soddisfare le proprietà ACID di una transazione. I database Oracle utilizzano gli SCN per contrassegnare la posizione in cui tutte le modifiche sono state scritte su disco in modo che un'operazione di ripristino non applichi modifiche già scritte. Oracle utilizza inoltre gli SCN per contrassegnare il punto in cui non esiste alcuna operazione redo per un set di dati in modo che sia possibile arrestare il ripristino.

Per ottenere l'SCN corrente in un database Oracle, esegui il comando seguente.

SELECT CURRENT_SCN FROM V$DATABASE

Se usi l'SCN o il timestamp per avviare un'attività di CDC, perdi i risultati di tutte le transazioni aperte e non riesci a migrare i risultati. Le transazioni aperte sono transazioni avviate prima della posizione di inizio dell'attività e confermate dopo la posizione di inizio dell'attività. È possibile identificare l'SCN e il timestamp per avviare un'attività di CDC in un punto che includa tutte le transazioni aperte. Per ulteriori informazioni, consulta Transactions nella documentazione online di Oracle. Con la versione 3.5.1 e successive, AWS DMS supporta le transazioni aperte per un'attività di sola CDC utilizzando l'impostazione dell'endpoint openTransactionWindow se si utilizza l'SCN o il timestamp per avviare l'attività.

Quando si utilizza l'impostazione openTransactionWindow, è necessario fornire la finestra, espressa in minuti, per gestire le transazioni aperte. AWS DMSsposta la posizione di acquisizione e trova la nuova posizione per avviare l'acquisizione dei dati. AWS DMS utilizza la nuova posizione iniziale per scansionare tutte le transazioni aperte dai log redo Oracle richiesti o dai log redo archiviati.

MySQL

Prima del rilascio di MySQL versione 5.6.3, il numero di sequenza di log (LSN, Log Sequence Number) per MySQL era un valore intero a 4 byte senza segno. In MySQL versione 5.6.3, quando il limite delle dimensioni del file di log redo aumentava da 4 GB a 512 GB, il valore LSN diventava un numero intero a 8 byte senza segno. L'aumento riflette il fatto che erano richiesti byte aggiuntivi per archiviare informazioni di dimensioni ulteriori. Le applicazioni create su MySQL 5.6.3 o versioni successive che utilizzano valori LSN devono utilizzare variabili a 64 bit piuttosto che a 32 bit per archiviare e confrontare i valori LSN. Per ulteriori informazioni sui valori LSN MySQL, consulta la documentazione di MySQL.

Per ottenere il valore LSN corrente in un database MySQL, esegui il comando seguente.

mysql> show master status;

La query restituisce un nome file binlog, la posizione e diversi altri valori. Il punto di inizio nativo CDC è una combinazione del nome del file binlog e della posizione, ad esempio mysql-bin-changelog.000024:373. In questo esempio, mysql-bin-changelog.000024 è il nome del file binlog e 373 è la posizione in cui AWS DMS deve iniziare ad acquisire le modifiche.

Utilizzo di un checkpoint come punto di inizio CDC

Un'attività di replica continua migra le modifiche e AWS DMS memorizza nella cache le informazioni di checkpoint specifiche per AWS DMS di tanto in tanto. Il checkpoint che AWS DMS crea contiene le informazioni necessarie affinché il motore di replica conosca il punto di ripristino per il flusso di modifica. Puoi utilizzare il checkpoint per tornare indietro nella cronologia delle modifiche e ripristinare un'attività di migrazione non riuscita. Puoi anche utilizzare un checkpoint per iniziare un'altra attività di replica continua per un'altra destinazione in qualunque momento.

Puoi ottenere le informazioni di checkpoint in uno dei seguenti tre modi:

• Esegui l'operazione API DescribeReplicationTasks e visualizza i risultati. Puoi filtrare le informazioni in base all'attività e cercare il checkpoint. Puoi recuperare il checkpoint più recente quando l'attività è in stato arrestato o non riuscito. Queste informazioni vengono perse in caso di eliminazione dell'attività.

• Visualizza la tabella dei metadati denominata awsdms_txn_state sull'istanza di destinazione. Puoi eseguire query alla tabella per ottenere le informazioni sul checkpoint. Per creare la tabella dei metadati, imposta il parametro TaskRecoveryTableEnabled su Yes al momento della creazione di un'attività. Questa impostazione consente a AWS DMS di scrivere in modo continuo le informazioni sul checkpoint nella tabella dei metadati di destinazione. Queste informazioni vengono perse in caso di eliminazione di un'attività.

  Di seguito è riportato un esempio di checkpoint nella tabella dei metadati: checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121

• Dal riquadro di navigazione, scegli Attività di migrazione del database e seleziona l'attività principale dall'elenco visualizzato nella pagina Attività di migrazione del database. Viene visualizzata la pagina dell'attività principale che mostra i dettagli della panoramica. Individuare il valore del checkpoint in Change data capture (CDC), posizione iniziale Change Data Capture (CDC) e punto di ripristino Change Data Capture (CDC). Il valore di checkpoint è simile all'esempio seguente:

  checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

Arresto di un'attività in un punto temporale di commit o del server

Con l'introduzione dei punti di inizio nativi CDC, AWS DMS può inoltre arrestare un'attività nei seguenti punti:

• Un'ora di commit sull'origine

• Un'ora del server sull'istanza di replica

Puoi modificare un'attività e impostare un'ora in UTC per eseguire l'arresto in base alle esigenze. L'attività viene arrestata automaticamente in base all'ora di commit o del server che hai impostato. Oppure, se conosci un'ora appropriata per arrestare l'attività di migrazione al momento della creazione dell'attività, puoi impostare un'ora di arresto quando crei l'attività.

Nota

L'inizializzazione di tutte le risorse la prima volta che si avvia una nuova replica AWS DMS serverless può richiedere fino a 40 minuti. Tieni presente che l'opzione server_time è applicabile solo dopo il completamento dell'inizializzazione delle risorse.

Esecuzione della replica bidirezionale

È possibile utilizzare le attività AWS DMS per eseguire la replica bidirezionale tra due sistemi. Nella replica bidirezionale, si replicano i dati dalla stessa tabella (o insieme di tabelle) tra due sistemi in entrambe le direzioni.

Ad esempio, è possibile copiare una tabella EMPLOYEE dal database A al database B e replicare le modifiche alla tabella dal database A al database B. È inoltre possibile replicare le modifiche alla tabella EMPLOYEE dal database B al database A. Pertanto, si sta eseguendo la replica bidirezionale.

Nota

La replicaAWS DMS bidirezionale non è intesa come una soluzione multimaster completa, che include un nodo primario, la risoluzione dei conflitti e così via.

Utilizzare la replica bidirezionale per situazioni in cui i dati su nodi diversi siano segregati operativamente. In altre parole, si supponga di avere un elemento di dati modificato da un'applicazione che opera sul nodo A e che il nodo A esegua la replica bidirezionale con il nodo B. Tale elemento di dati sul nodo A non viene mai modificato da nessuna applicazione che opera sul nodo B.

AWS DMS supporta la replica bidirezionale su questi motori di database:

• Oracle

• SQL Server

• MySQL

• PostgreSQL

• Amazon Aurora edizione compatibile con MySQL

• Amazon Aurora edizione compatibile con PostgreSQL

Creazione di attività di replica bidirezionale

Per abilitare la replica AWS DMS bidirezionale, configurare gli endpoint di origine e di destinazione per entrambi i database (A e B). Ad esempio, configurare un endpoint di origine per il database A, un endpoint di origine per il database B, un endpoint di destinazione per il database A e un endpoint di destinazione per il database B.

Quindi creare due attività: un'attività per l'origine A per spostare i dati nella destinazione B e un'altra attività per l'origine B per spostare i dati nella destinazione A. Inoltre, assicurarsi che ogni attività sia configurata con la prevenzione del loopback. Ciò impedisce che modifiche identiche vengano applicate alle destinazioni di entrambe le attività, danneggiando così i dati di almeno una di esse. Per ulteriori informazioni, consulta Prevenire il loopback.

Per un approccio più semplice, iniziare con set di dati identici nel database A e nel database B. Quindi creare due attività solo CDC, un'attività per replicare i dati da A a B e un'altra attività per replicare i dati da B ad A.

Per utilizzare AWS DMS per creare l'istanza di un nuovo set di dati (database) sul nodo B dal nodo A, effettuare le operazioni seguenti:

1. Utilizzare un'attività di caricamento completo e CDC per spostare i dati dal database A a B. Assicurarsi che nessuna applicazione stia modificando i dati nel database B durante questo periodo.

2. Quando il caricamento completo è completo e prima che le applicazioni siano autorizzate a modificare i dati nel database B, prendere nota dell'ora o della posizione di avvio del CDC del database B. Per istruzioni, vedere Esecuzione della replica a partire da un punto di inizio CDC.

3. Creare un'attività solo CDC che sposta i dati dal database B ad A utilizzando l'ora di inizio o la posizione di avvio del CDC.

Nota

Solo un'attività in una coppia bidirezionale può essere a caricamento completo e CDC.

Prevenire il loopback

Per comprendere come prevenite il loopback, si supponga che in un'attività T1 AWS DMS legga i log delle modifiche dal database di origine A e applichi le modifiche al database di destinazione B.

Successivamente, una seconda attività, T2, legge i log delle modifiche dal database di origine B e li applica nuovamente al database di destinazione A. Prima di T2, DMS deve assicurarsi che le stesse modifiche apportate al database di destinazione B dal database di origine A non siano apportate al database di origine A. In altre parole, DMS deve assicurarsi che queste modifiche non vengano riecheggiate (in loop) al database di destinazione A. In caso contrario, i dati nel database A possono essere danneggiati.

Per evitare il loopback delle modifiche, aggiungere le seguenti impostazioni di attività a ogni attività di replica bidirezionale. In questo modo si assicura che il danneggiamento dei dati di loopback non si verifichi in entrambe le direzioni.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": Boolean,
    "SourceSchema": String,
    "TargetSchema": String
  },

. . .
}

Le impostazioni dell'attività LoopbackPreventionSettings determinano se una transazione è nuova o un'eco dall'attività di replica opposta. Quando AWS DMS applica una transazione a un database di destinazione, aggiorna una tabella DMS (awsdms_loopback_prevention) con un'indicazione della modifica. Prima di applicare ciascuna transazione a una destinazione, DMS ignora qualsiasi transazione che includa un riferimento a questa tabella awsdms_loopback_prevention. Pertanto, non applica la modifica.

Includere queste impostazioni di attività in ogni attività di replica in una coppia bidirezionale. Queste impostazioni consentono la prevenzione del loopback. Specificano inoltre lo schema per ogni database di origine e di destinazione nell'attività che include la tabella awsdms_loopback_prevention per ciascun endpoint.

Per consentire a ciascuna attività di identificare tale eco e scartarla, impostare EnableLoopbackPrevention su true. Per specificare uno schema all'origine che includa awsdms_loopback_prevention, impostare SourceSchema sul nome dello schema nel database di origine. Per specificare uno schema nella destinazione che include la stessa tabella, impostare TargetSchema il nome dello schema nel database di destinazione.

Nell'esempio seguente, le impostazioni SourceSchema e TargetSchema per un'attività di replica T1 e la relativa attività di replica opposta T2 sono specificate con impostazioni opposte.

Le impostazioni per l'attività T1 sono le seguenti.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "LOOP-DATA",
    "TargetSchema": "loop-data"
  },

. . .
}

Le impostazioni per l'attività opposta T2 sono le seguenti.

{
. . .

  "LoopbackPreventionSettings": {
    "EnableLoopbackPrevention": true,
    "SourceSchema": "loop-data",
    "TargetSchema": "LOOP-DATA"
  },

. . .
}

Nota

Quando si utilizza l'AWS CLI, utilizzare solo i comandi create-replication-task o modify-replication-task per configurare LoopbackPreventionSettings nelle attività di replica bidirezionali.

Limitazioni della replica bidirezionale

La replica bidirezionale per AWS DMS presenta le seguenti limitazioni:

• La prevenzione loopback tiene traccia solo delle istruzioni del linguaggio di manipolazione dei dati (DML). AWS DMS non supporta la prevenzione del loopback del linguaggio di definizione dei dati (DDL). A tale scopo, configurare una delle attività in una coppia bidirezionale per filtrare le istruzioni DDL.

• Le attività che utilizzano la prevenzione del loopback non supportano il commit delle modifiche nei batch. Per configurare un'attività con la prevenzione del loopback, assicurarsi di impostare BatchApplyEnabled su false.

• La replica bidirezionale DMS non include il rilevamento o la risoluzione dei conflitti. Per rilevare le incongruenze dei dati, utilizzare la convalida dei dati su entrambe le attività.