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à.

Creazione di attività per la replica continua mediante AWS DMS

È possibile creare un' AWS DMS attività che acquisisca le modifiche in corso dal data store 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 acquisizione dei dati di modifica (CDC). AWS DMS utilizza questo processo per replicare le modifiche in corso da un data store di origine. Questo processo funziona raccogliendo le modifiche nei log di database mediante l'API nativa del motore di database.

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 azioni API specifiche del motore per leggere le modifiche dai registri delle transazioni del motore di origine. Di seguito sono riportati alcuni esempi di come ciò avviene: AWS DMS

Esistono due tipi di attività di replica continua:

Esecuzione della replica a partire da un punto di inizio CDC

È possibile avviare un'attività di replica AWS DMS continua (solo modifica dell'acquisizione dei dati) da diversi punti. Questi sono i seguenti:

Quando l'attività viene creata, AWS DMS segna il punto di inizio del CDC e non può essere modificata. 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:

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 sui checkpoint specifiche di volta in volta. AWS DMS 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:

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

Con l'introduzione dei punti di partenza nativi del CDC, AWS DMS puoi anche interrompere un'attività nei seguenti punti:

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à.

Esecuzione della replica bidirezionale

È possibile utilizzare AWS DMS le attività 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.

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:

Creazione di attività di replica bidirezionale

Per abilitare la replica AWS DMS bidirezionale, configura 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.

Da utilizzare AWS DMS per creare un'istanza di un nuovo set di dati (database) sul nodo B dal nodo A, procedi come segue:

Prevenire il loopback

Per impedire il loopback, supponiamo 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"
  },

. . .
}

Limitazioni della replica bidirezionale

La replica bidirezionale per presenta le seguenti limitazioni: AWS DMS