Utilizzo di un database SQL compatibile con My come fonte per AWS DMS - AWS Database Migration Service
Migrazioni SQL da My a My SQLUtilizzo di My SQL come fonteUtilizzo di My SQL autogestito come fonteUtilizzo AWS-ha gestito My SQL come fonteLimitazioni relative a My SQL come fonteSupporto per transazione XAImpostazioni degli endpointTipi di dati di origine per My SQL

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 SQL compatibile con My come fonte per AWS DMS

Puoi migrare i dati da qualsiasi database SQL compatibile con My (My, SQL MariaDB o Amazon Aurora My) utilizzando SQL AWS Servizio di migrazione del Database.

Per informazioni sulle versioni di My SQL that AWS DMS supporta come fonte, vedereFonti per AWS DMS.

È possibile utilizzarlo SSL per crittografare le connessioni tra l'endpoint SQL compatibile con My e l'istanza di replica. Per ulteriori informazioni sull'utilizzo SSL con un endpoint compatibile con My, SQL consulta. Utilizzo di SSL con AWS Database Migration Service

Nelle sezioni seguenti, il termine «gestione automatica» si applica a qualsiasi database installato in locale o su Amazon. EC2 Il termine»AWS-managed» si applica a qualsiasi database su AmazonRDS, Amazon Aurora o Amazon S3.

Per ulteriori dettagli sull'utilizzo dei database compatibili con My SQL e AWS DMS, vedere le seguenti sezioni.

Migrazione da My SQL a My utilizzando SQL AWS DMS

Per una migrazione eterogenea, in cui si esegue la migrazione da un motore di database diverso da My SQL a un database, SQL AWS DMS è quasi sempre lo strumento di migrazione migliore da utilizzare. Tuttavia, per una migrazione omogenea, in cui si esegue la migrazione da un database personale a un SQL database personaleSQL, si consiglia di utilizzare un progetto di migrazione dei dati omogeneo. omogeneous data migations utilizza strumenti di database nativi per fornire prestazioni e precisione di migrazione dei dati migliori rispetto a AWS DMS.

Utilizzo di qualsiasi database compatibile con My come origine per SQL AWS DMS

Prima di iniziare a utilizzare un SQL database My come fonte per AWS DMS, assicurati di avere i seguenti prerequisiti. Questi prerequisiti si applicano ai sistemi autogestiti o AWS-fonti gestite.

È necessario disporre di un account per AWS DMS che ha il ruolo di amministratore di replica. Il ruolo richiede i seguenti privilegi:

  • REPLICATIONCLIENT— Questo privilegio è richiesto solo per le CDC attività. In altre parole, le full-load-only attività non richiedono questo privilegio.

  • REPLICATIONSLAVE— Questo privilegio è richiesto solo per le CDC attività. In altre parole, le full-load-only attività non richiedono questo privilegio.

  • SUPER— Questo privilegio è richiesto solo nelle mie SQL versioni precedenti alla 5.6.6.

Il AWS DMS l'utente deve inoltre disporre dei SELECT privilegi per le tabelle di origine destinate alla replica.

Utilizzo di un database autogestito SQL compatibile con My come origine per AWS DMS

È possibile utilizzare i seguenti database autogestiti SQL compatibili con My come fonti per AWS DMS:

  • My Community Edition SQL

  • La mia edizione SQL standard

  • La mia edizione SQL Enterprise

  • La mia edizione SQL Cluster Carrier Grade

  • MariaDB Community Edition

  • MariaDB Enterprise Edition

  • MariaDB Column Store

Per utilizzarloCDC, assicurati di abilitare la registrazione binaria. Per abilitare la registrazione binaria, è necessario configurare i seguenti parametri nel file My SQL my.ini (Windows) o my.cnf (UNIX).

Parametro

Valore

server_id

Imposta questo parametro su un valore uguale o maggiore di 1.

log-bin

Imposta il percorso del file di log binario, ad esempio log-bin=E:\MySql_Logs\BinLog. Non includere l'estensione del file.

binlog_format

Imposta questo parametro su ROW. Si consiglia questa impostazione per la replica perché, in alcuni casi, quando binlog_format è impostato su STATEMENT, si possono verificare incoerenze della replica dei dati sulla destinazione. Il motore di database scrive dati incoerenti simili sulla destinazione quando binlog_format è impostato su MIXED perché passa automaticamente alla registrazione basata su STATEMENT, il che può comportare la scrittura di dati non coerenti sul database di destinazione.

expire_logs_days

Imposta questo parametro su un valore uguale o maggiore di 1. Per prevenire un utilizzo eccessivo di spazio su disco, si consiglia di non utilizzare il valore predefinito di 0.

binlog_checksum

Imposta questo parametro sulla DMS versione 3.4.7 o precedente. NONE

binlog_row_image

Imposta questo parametro su FULL.

log_slave_updates

Imposta questo parametro su TRUE se stai utilizzando una replica di lettura My SQL o MariaDB come sorgente.

Se si utilizza una replica di lettura My SQL o MariaDB come origine per DMS un'attività di migrazione utilizzando la modalità Migra dati esistenti e replica le modifiche in corso, esiste la possibilità di perdita di dati. DMSnon scriverà una transazione durante il pieno caricamento o nelle seguenti condizioni: CDC

  • La transazione era stata salvata nell'istanza principale prima dell'inizio dell'DMSattività.

  • La transazione era stata salvata nella replica solo dopo l'avvio dell'DMSattività, a causa del ritardo tra l'istanza principale e la replica.

Maggiore è il ritardo tra l'istanza principale e la replica, maggiore è il rischio di perdita di dati.

Se l'origine utilizza il motore di database NDB (in cluster), è necessario configurare i seguenti parametri per l'attivazione CDC nelle tabelle che utilizzano tale motore di archiviazione. Aggiungi queste modifiche nel file My SQL my.ini (Windows) o my.cnf (UNIX).

Parametro

Valore

ndb_log_bin

Imposta questo parametro su ON. Questo valore garantisce che le modifiche nelle tabelle cluster vengono registrate nel log binario.

ndb_log_update_as_write

Imposta questo parametro su OFF. Questo valore impedisce di scrivere UPDATE istruzioni come INSERT istruzioni nel log binario.

ndb_log_updated_only

Imposta questo parametro su OFF. Questo valore garantisce che il log binario contiene l'intera riga e non soltanto le colonne modificate.

Utilizzando un AWS-managed Il mio database SQL compatibile come fonte per AWS DMS

È possibile utilizzare quanto segue AWS-ha gestito i miei database SQL compatibili come fonti per AWS DMS:

  • My Community Edition SQL

  • MariaDB Community Edition

  • Edizione compatibile con Amazon Aurora My SQL

Quando si utilizza un AWS-managed Il mio database SQL compatibile come fonte per AWS DMS, assicurati di disporre dei seguenti prerequisiti per: CDC

  • Per abilitare i log binari per My SQL e RDS RDS per MariaDB, abilita i backup automatici a livello di istanza. Per abilitare i log binari per un cluster Aurora SQL My, modifica la binlog_format variabile nel gruppo di parametri.

    Per ulteriori informazioni sulla configurazione dei backup automatici, consulta Working with automatic backup nella Amazon RDS User Guide.

    Per ulteriori informazioni sulla configurazione della registrazione binaria per un SQL database Amazon RDS for My, consulta Impostazione del formato di registrazione binaria nella Amazon RDS User Guide.

    Per ulteriori informazioni sulla configurazione della registrazione binaria per un cluster Aurora SQL My, vedi Come si attiva la registrazione binaria per il mio cluster Amazon Aurora My? SQL .

  • Se prevedi di utilizzarloCDC, attiva la registrazione binaria. Per ulteriori informazioni sulla configurazione della registrazione binaria per un SQL database Amazon RDS for My, consulta Impostazione del formato di registrazione binaria nella Amazon RDS User Guide.

  • Assicurati che i log binari siano disponibili per AWS DMS. Perché AWS-managed I database SQL compatibili eliminano i log binari il prima possibile, è necessario aumentare il periodo di tempo in cui i log rimangono disponibili. Ad esempio, per aumentare il periodo di conservazione dei log binari a 24 ore, esegui il comando seguente. 

    
 call mysql.rds_set_configuration('binlog retention hours', 24);

  • Imposta il parametro binlog_format su "ROW".

    Nota

    Su My SQL o MariaDBbinlog_format, è un parametro dinamico, quindi non è necessario riavviare il computer per rendere effettivo il nuovo valore. Tuttavia, il nuovo valore verrà applicato solo alle nuove sessioni. Se si passa binlog_format su ROW per scopi di replica, il database può comunque creare log binari successivi utilizzando il formato MIXED, se tali sessioni sono iniziate prima della modifica del valore. Questo può impedire AWS DMS dall'acquisire correttamente tutte le modifiche nel database di origine. Quando modifichi l'binlog_formatimpostazione su un database MariadB o SQL My, assicurati di riavviare il database per chiudere tutte le sessioni esistenti o riavvia qualsiasi applicazione che DML esegue operazioni (Data Manipulation Language). Forzando il database a riavviare tutte le sessioni dopo aver modificato il binlog_format parametro ROW si assicurerà che il database scriva tutte le successive modifiche al database di origine utilizzando il formato corretto, in modo che AWS DMS è in grado di acquisire correttamente tali modifiche.

  • Imposta il parametro binlog_row_image su "Full".

  • Imposta il binlog_checksum parametro sulla DMS versione 3.4.7 o precedente. "NONE" Per ulteriori informazioni sull'impostazione dei parametri in Amazon RDS MySQL, consulta Working with automation backup nella Amazon RDS User Guide.

  • Se utilizzi una replica di lettura Amazon RDS My SQL o Amazon RDS MariaDB come origine, abilita i backup sulla replica di lettura e assicurati che il parametro sia impostato su. log_slave_updates TRUE

Limitazioni all'utilizzo di un database My come fonte SQL per AWS DMS

Quando utilizzate un SQL database My come fonte, tenete presente quanto segue:

  • Change Data Capture (CDC) non è supportato per Amazon RDS My SQL 5.5 o versioni precedenti. Per Amazon RDS MySQL, devi utilizzare la versione 5.6, 5.7 o 8.0 per abilitarlo. CDC CDCè supportato per le sorgenti My 5.5 autogestite. SQL

  • PerCDC, CREATE TABLEADD COLUMN, e per la DROP COLUMN modifica del tipo di dati della colonna, e renaming a column sono supportati. Tuttavia DROP TABLE, RENAME TABLE e gli aggiornamenti apportati ad altri attributi, come il valore predefinito della colonna, la nullabilità delle colonne, il set di caratteri e così via, non sono supportati.

  • Per le tabelle partizionate sull'origine, quando imposti la modalità di preparazione della tabella di Target su Elimina tabelle sulla destinazione, AWS DMS crea una tabella semplice senza partizioni sulla destinazione My. SQL Per migrare le tabelle partizionate in una tabella partizionata sulla destinazione, precrea le tabelle partizionate sul database My di destinazione. SQL

  • L'utilizzo di un'ALTER TABLE table_name ADD COLUMN column_nameistruzione per aggiungere colonne all'inizio (FIRST) o al centro di una tabella () non è supportato. AFTER Le colonne vengono sempre aggiunte alla fine della tabella.

  • CDCnon è supportato quando il nome di una tabella contiene caratteri maiuscoli e minuscoli e il motore di origine è ospitato su un sistema operativo con nomi di file senza distinzione tra maiuscole e minuscole. Un esempio è Microsoft Windows o OS X che utilizzano HFS +.

  • Puoi usare Aurora My SQL -Compatible Edition Serverless v1 a pieno carico, ma non puoi usarlo per. CDC Questo perché non puoi abilitare i prerequisiti per My. SQL Per ulteriori informazioni, consulta Parameter groups and Aurora Serverless v1.

    Supporta Aurora My SQL -Compatible Edition Serverless v2. CDC

  • L'INCREMENTattributo AUTO _ su una colonna non viene migrato in una colonna del database di destinazione.

  • L'acquisizione delle modifiche quando i log binari non sono archiviati su uno storage a blocchi standard non è supportata. Ad esempio, CDC non funziona quando i log binari sono archiviati su Amazon S3.

  • AWS DMS crea tabelle di destinazione con il motore di archiviazione InnoDB per impostazione predefinita. Se è necessario utilizzare un motore di storage diverso da InnoDB, occorre creare manualmente la tabella ed eseguirvi la migrazione utilizzando la modalità nessuna azione.

  • Non puoi usare Aurora Le mie SQL repliche come fonte per AWS DMS a meno che la modalità DMS dell'attività di migrazione non sia Migrazione dei dati esistenti, solo a pieno carico.

  • Se l'origine SQL compatibile con My viene interrotta durante il caricamento completo, AWS DMS l'operazione non si interrompe con un errore. L'attività termina correttamente, ma la destinazione potrebbe non essere sincronizzata con l'origine. In questo caso, riavvia l'attività o ricarica le tabelle interessate.

  • Gli indici creati su una parte di un valore di colonna non vengono migrati. Ad esempio, l'indice CREATE INDEX first_ten_chars ON customer (name (10)) non viene creato sulla destinazione.

  • In alcuni casi, l'attività è configurata per non essere replicata LOBs (» SupportLobs "è false nelle impostazioni dell'attività oppure l'opzione Non includere LOB colonne è stata scelta nella console attività). In questi casi, AWS DMS non migra alcuna LONGTEXT colonna MEDIUMBLOBLONGBLOB,MEDIUMTEXT, e verso la destinazione.

    BLOB, TINYBLOBTEXT, e TINYTEXT le colonne non sono interessate e vengono migrate verso la destinazione.

  • Le tabelle di dati temporali o le tabelle con versioni di sistema non sono supportate nei database di origine e di destinazione di MariaDB.

  • In caso di migrazione tra due cluster Amazon RDS Aurora My, l'endpoint Aurora SQL SQL My source deve essere un'RDSistanza di lettura/scrittura, non un'istanza di replica.

  • AWS DMS attualmente non supporta la migrazione delle visualizzazioni per MariadB.

  • AWS DMS non supporta le DDL modifiche alle tabelle partizionate per My. SQL Per saltare la sospensione della tabella per le DDL modifiche alle partizioni duranteCDC, imposta su. skipTableSuspensionForPartitionDdl true

  • AWS DMS supporta solo transazioni XA nella versione 3.5.0 e successive. Le versioni precedenti non supportano le transazioni XA. AWS DMS non supporta le transazioni XA nella versione 10.6 di MariadB. Per ulteriori informazioni, consulta la sezione seguente: Supporto per transazione XA.

  • AWS DMS non viene utilizzato GTIDs per la replica, anche se i dati di origine li contengono.

  • AWS DMS non supporta il log binario SQL avanzato di Aurora My.

  • AWS DMS non supporta la compressione delle transazioni di log binario.

  • AWS DMS non propaga UPDATE CASCADE gli eventi ON DELETE CASCADE e ON per i miei SQL database utilizzando il motore di archiviazione InnoDB. Per questi eventi, My SQL non genera eventi binlog per riflettere le operazioni a cascata sulle tabelle secondarie. Di conseguenza, AWS DMS non può replicare le modifiche corrispondenti alle tabelle secondarie. Per ulteriori informazioni, consulta Indici, chiavi esterne o aggiornamenti o eliminazioni a cascata non migrati.

  • AWS DMS non acquisisce le modifiche alle colonne calcolate (VIRTUALeGENERATED ALWAYS). Per ovviare a questa limitazione, esegui queste operazioni:

    • Pre-crea la tabella di destinazione nel database di destinazione e crea il AWS DMS attività con l'DO_NOTHINGimpostazione o TRUNCATE_BEFORE_LOAD caricamento completo.

    • Aggiungi una regola di trasformazione per rimuovere la colonna calcolata dall'ambito dell'attività. Per informazioni sulle regole di trasformazione, consulta Operazioni e regole di trasformazione.

Supporto per transazione XA

Una transazione Extended Architecture (XA) è una transazione che può essere utilizzata per raggruppare una serie di operazioni da più risorse transazionali in un'unica transazione globale affidabile. Una transazione XA utilizza un protocollo di commit in due fasi. In generale, l'acquisizione delle modifiche mentre sono presenti transazioni XA aperte potrebbe portare alla perdita di dati. Se il database non utilizza transazioni XA, puoi ignorare questa autorizzazione e la configurazione IgnoreOpenXaTransactionsCheck utilizzando il valore predefinito TRUE. Per iniziare la replica da un'origine che contiene transazioni XA, effettua le seguenti operazioni:

  • Assicurarsi che AWS DMS l'utente dell'endpoint dispone delle seguenti autorizzazioni:

    grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';

  • Configura l'impostazione dell'endpoint IgnoreOpenXaTransactionsCheck su false.

Nota

AWS DMS non supporta le transazioni XA su MariaDB Source DB versione 10.6.

Impostazioni degli endpoint quando si utilizza My come fonte per SQL AWS DMS

È possibile utilizzare le impostazioni degli endpoint per configurare il database My SQL source in modo simile all'utilizzo di attributi di connessione aggiuntivi. Le impostazioni vengono specificate quando si crea l'endpoint di origine utilizzando il AWS DMS console o utilizzando il create-endpoint comando in AWS CLI, con la --my-sql-settings '{"EndpointSetting": "value", ...}' JSON sintassi.

La tabella seguente mostra le impostazioni degli endpoint che è possibile utilizzare con My SQL come sorgente.

Nome Descrizione
EventsPollInterval

Specifica la frequenza di controllo del log binario per nuove modifiche/eventi quando il database è inattivo.

Valore predefinito: 5

Valori validi: 1-60

Esempio: --my-sql-settings '{"EventsPollInterval": 5}'

Nell'esempio, AWS DMS verifica le modifiche nei log binari ogni cinque secondi.
ExecuteTimeout

In AWS DMS versioni 3.4.7 e successive, imposta il timeout dell'istruzione client per un endpoint My SQL source, in secondi.

Valore predefinito: 60

Esempio: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone

Speciifica il fuso orario per il database My di origine. SQL

Esempio: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript

Speciifica uno script da eseguire immediatamente dopo AWS DMS si connette all'endpoint. L'attività di migrazione continua a essere eseguita indipendentemente dal fatto che l'SQListruzione abbia esito positivo o negativo.

Valori validi: una o più SQL istruzioni valide, contrassegnate da un punto e virgola.

Esempio: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSrcMetadataOnMismatch

Esegue la pulizia e crea nuovamente le informazioni dei metadati delle tabelle sull'istanza di replica se si verifica una mancata corrispondenza. Ad esempio, in una situazione in cui l'esecuzione di un alter DDL sulla tabella potrebbe generare informazioni diverse sulla tabella memorizzata nella cache dell'istanza di replica. booleano.

Valore predefinito: false

Esempio: --my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl

AWS DMS non supporta le DDL modifiche per le tabelle partizionate per My. SQL In AWS DMS versioni 3.4.6 e successive, impostandola per true saltare la sospensione della tabella per le modifiche alle partizioni durante. DDL CDC AWS DMS ignora partitioned-table-related DDL e continua a elaborare ulteriori modifiche al registro binario.

Valore predefinito: false

Esempio: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck

In AWS DMS le versioni 3.5.0 e successive specificano se le attività devono ignorare le transazioni XA aperte all'avvio. Imposta su false se l'origine ha transazioni XA.

Valore predefinito: true

Esempio: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

Tipi di dati di origine per My SQL

La tabella seguente mostra i tipi di dati di origine del mio SQL database supportati durante l'utilizzo AWS DMS e la mappatura predefinita di AWS DMS tipi di dati.

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 su AWS DMS tipi di dati, vedereTipi di dati per AWS Database Migration Service.

I miei tipi di SQL dati

AWS DMS tipi di dati

INT

INT4

BIGINT

INT8

MEDIUMINT

INT4

TINYINT

INT1

SMALLINT

INT2

UNSIGNED TINYINT

UINT1

UNSIGNED SMALLINT

UINT2

UNSIGNED MEDIUMINT

UINT4

UNSIGNED INT

UINT4

UNSIGNED BIGINT

UINT8

DECIMAL(10)

NUMERIC(10,0)

BINARY

BYTES(1)

BIT

BOOLEAN

BIT(64)

BYTES(8)

BLOB

BYTES(65535)

LONGBLOB

BLOB

MEDIUMBLOB

BLOB

TINYBLOB

BYTES(255)

DATE

DATE

DATETIME

DATETIME

DATETIMEsenza un valore tra parentesi viene replicato senza millisecondi. DATETIMEcon un valore tra parentesi compreso tra 1 e 5 (ad esempio) viene replicato in millisecondi. DATETIME(5)

Quando si replica una DATETIME colonna, il tempo rimane lo stesso sulla destinazione. Non viene convertito in. UTC

TIME

STRING

TIMESTAMP

DATETIME

Quando si replica una TIMESTAMP colonna, l'ora viene convertita in UTC sulla destinazione.

YEAR

INT2

DOUBLE

REAL8

FLOAT

REAL(DOUBLE)

Se i FLOAT valori non rientrano nell'intervallo seguente, usa una trasformazione a cui mappareFLOAT. STRING Per ulteriori informazioni sulle trasformazioni, consulta Operazioni e regole di trasformazione.

L'FLOATintervallo supportato è compreso tra -1,79E+308 e -2,23E-308, 0 e 2,23E-308 fino a 1,79E+308

VARCHAR(45)

WSTRING(45)

VARCHAR(2000)

WSTRING(2000)

VARCHAR(4000)

WSTRING(4000)

VARBINARY(4000)

BYTES(4000)

VARBINARY(2000)

BYTES(2000)

CHAR

WSTRING

TEXT

WSTRING

LONGTEXT

NCLOB

MEDIUMTEXT

NCLOB

TINYTEXT

WSTRING(255)

GEOMETRY

BLOB

POINT

BLOB

LINESTRING

BLOB

POLYGON

BLOB

MULTIPOINT

BLOB

MULTILINESTRING

BLOB

MULTIPOLYGON

BLOB

GEOMETRYCOLLECTION

BLOB

ENUM

WSTRING (length)

Ecco length è la lunghezza del valore più lungo in. ENUM

SET

WSTRING (length)

Ecco, length è la lunghezza totale di tutti i valori contenuti inSET, virgole incluse.

JSON

CLOB
Nota

In alcuni casi, è possibile specificare i tipi di TIMESTAMP dati DATETIME e con un valore «zero» (ovvero 0000-00-00). In tal caso, assicuratevi che il database di destinazione nell'attività di replica supporti valori «zero» per i DATETIME tipi di dati e. TIMESTAMP In caso contrario, tali valori vengono registrati come null nella destinazione.