Migrazioni da MySQL a MySQL Utilizzo di MySQL come origine Utilizzo di MySQL gestito dal cliente come origine Utilizzo AWS di -managed MySQL come sorgente Limitazioni su MySQL come origine Supporto per transazione XA Impostazioni degli endpoint Tipi di dati di origine per MySQL

Utilizzo di un database compatibile con MySQL come origine per AWS DMS

Puoi migrare i dati da qualsiasi database compatibile con MySQL (MySQL, MariaDB o Amazon Aurora MySQL) utilizzando Database Migration Service. AWS

Per informazioni sulle versioni di MySQL supportate da AWS DMS come origine, consulta Fonti per AWS DMS.

Puoi utilizzare il protocollo SSL per crittografare le connessioni tra l'endpoint compatibile con MySQL e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint compatibile con MySQL, 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 "gestito da AWS" si applica a qualsiasi database su Amazon RDS, Amazon Aurora o Amazon S3.

Per ulteriori dettagli sull'utilizzo di database compatibili con MySQL AWS DMS, vedere le seguenti sezioni.

Argomenti

Migrazione da MySQL a MySQL mediante AWS DMS.
Utilizzo di qualsiasi database compatibile con MySQL come fonte per AWS DMS
Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS
Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS
Limitazioni all'utilizzo di un database MySQL come fonte per AWS DMS
Supporto per transazione XA
Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS
Tipi di dati di origine per MySQL

Migrazione da MySQL a MySQL mediante AWS DMS.

Per una migrazione eterogenea, in cui si esegue la migrazione da un motore di database diverso da MySQL a un database MySQL, è quasi sempre lo strumento di migrazione migliore da utilizzare. AWS DMS Ma per una migrazione omogenea, ad esempio da un database MySQL a un database MySQL, ti consigliamo di utilizzare un progetto di migrazione di dati omogeneo. Le migrazioni di dati omogenee utilizzano strumenti di database nativi per fornire prestazioni e precisione di migrazione dei dati migliorate rispetto a AWS DMS.

Utilizzo di qualsiasi database compatibile con MySQL come fonte per AWS DMS

Prima di iniziare a utilizzare un database MySQL come sorgente AWS DMS per, assicurati di avere i seguenti prerequisiti. Questi prerequisiti si applicano sia alle fonti autogestite che a quelle gestite. AWS

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

REPLICATION CLIENT: questo privilegio è richiesto per le attività di sola CDC. In altre parole, le full-load-only attività non richiedono questo privilegio.
REPLICATION SLAVE: questo privilegio è richiesto per le attività di sola CDC. In altre parole, le full-load-only attività non richiedono questo privilegio.
SUPER: questo privilegio è richiesto solo nelle versioni di MySQL precedenti alla 5.6.6.

L' AWS DMS utente deve inoltre disporre dei privilegi SELECT per le tabelle di origine designate per la replica.

Concedi i seguenti privilegi se utilizzi valutazioni di premigrazione specifiche per MySQL.


grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher

Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS

Puoi utilizzare i seguenti database gestiti dal cliente compatibili con MySQL come origini per AWS DMS:

MySQL Community Edition
MySQL Standard Edition
MySQL Enterprise Edition
MySQL Cluster Carrier Grade Edition
MariaDB Community Edition
MariaDB Enterprise Edition
MariaDB Column Store

Per utilizzare CDC, assicurati di abilitare la registrazione binaria. Per abilitare la registrazione binaria, devi configurare i seguenti parametri nel file my.ini (Windows) o my.cnf (UNIX) di MySQL.

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 su `NONE` per la versione DMS 3.4.7 o precedente.
`binlog_row_image`	Imposta questo parametro su `FULL`.
`log_slave_updates`	Imposta questo parametro su `TRUE` se stai utilizzando come origine una replica di lettura di MySQL o di MariaDB.

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

La transazione era stata salvata nell'istanza principale prima dell'inizio dell'attività DMS.
La transazione era stata salvata nella replica solo dopo l'avvio dell'attività DMS, 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 (cluster), i parametri seguenti devono essere configurati per abilitare il CDC sulle tabelle che utilizzano il motore di storage. Aggiungi queste modifiche nel file my.ini (Windows) o my.cnf (UNIX) di MySQL.

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 la scrittura nel log binario delle istruzioni UPDATE come istruzioni INSERT.
`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.

Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS

È possibile utilizzare i seguenti database AWS gestiti compatibili con MySQL come sorgenti per: AWS DMS

MySQL Community Edition
MariaDB Community Edition
Amazon Aurora edizione compatibile con MySQL

Quando utilizzi un database compatibile con MySQL AWS gestito come fonte per AWS DMS, assicurati di avere i seguenti prerequisiti per CDC:

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

Per ulteriori informazioni sull'impostazione dei backup automatici, consulta Abilitazione dei backup automatici nella Guida per l'utente di Amazon RDS.

Per ulteriori informazioni sulla configurazione della registrazione binaria per un database Amazon RDS per MySQL, consulta Configurazione del log binario nella Guida per l'utente di Amazon RDS.

Per ulteriori informazioni sulla configurazione della registrazione binaria per un cluster MySQL Aurora, consulta Come posso attivare la registrazione binaria per il cluster Amazon Aurora MySQL edizione compatibile?
Se intendi utilizzare CDC, attiva la registrazione binaria. Per ulteriori informazioni sulla configurazione della registrazione binaria per un database Amazon RDS per MySQL, consulta Configurazione del log binario nella Guida per l'utente di Amazon RDS.
Assicuratevi che i log binari siano disponibili per. AWS DMS Poiché i database compatibili con AWS-managed MySQL 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 MySQL o MariaDB, binlog_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. Ciò potrebbe impedire la corretta acquisizione di tutte le modifiche nel AWS DMS database di origine. Quando modifichi l'impostazione binlog_format su un database MariaDB o MySQL, assicurati di riavviare il database per chiudere tutte le sessioni esistenti o riavviare qualsiasi applicazione che esegua operazioni DML (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 sia AWS DMS possibile acquisire correttamente tali modifiche.
Imposta il parametro binlog_row_image su "Full".
Imposta il binlog_checksum parametro su "NONE" DMS versione 3.4.7 o precedente. Per ulteriori informazioni sull'impostazione dei parametri in Amazon RDS MySQL, consulta Abilitazione dei backup automatici nella Guida per l'utente di Amazon RDS.
Se stai utilizzando una replica di lettura Amazon RDS MySQL o Amazon RDS MariaDB come origine, abilita i backup sulla replica di lettura e assicurati che il parametro log_slave_updates sia impostato su TRUE.

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

Quando si utilizza un database MySQL come origine, considerare quanto segue:

L'acquisizione dei dati di modifica (CDC) non è supportata per Amazon RDS MySQL 5.5 o versioni precedenti. Per Amazon RDS MySQL, è necessario utilizzare la versione 5.6, 5.7 o 8.0 per abilitare CDC. CDC è supportata per origini MySQL 5.5 autogestite.
Per CDC, CREATE TABLE, ADD COLUMN e DROP COLUMN che modificano il tipo di dati di colonne 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 si imposta la modalità di preparazione della tabella di Target su Drop tables on target, AWS DMS crea una tabella semplice senza partizioni sulla destinazione MySQL. Per eseguire la migrazione di tabelle partizionate a una tabella partizionata nella destinazione, crea in anticipo le tabelle partizionate nel database di destinazione MySQL.
L'utilizzo di un'istruzione ALTER TABLE table_name ADD COLUMN column_name per aggiungere colonne all'inizio (FIRST) o a metà di una tabella (AFTER) non è supportato. Le colonne vengono sempre aggiunte alla fine della tabella.
Il CDC non è supportato quando un nome di tabella contiene caratteri maiuscoli e minuscoli e il motore di origine è ospitato in un sistema operativo con nomi di file che non fanno distinzione tra lettere maiuscole e minuscole. Un esempio è Microsoft Windows oppure OS X che utilizza HFS +.
Puoi usare Aurora, compatibile con MySQL, Edition Serverless v1 a pieno carico, ma non puoi usarlo per CDC. perché non è possibile abilitare i prerequisiti per MySQL. Per ulteriori informazioni, consulta Parameter groups and Aurora Serverless v1.

L'edizione Serverless v2 compatibile con Aurora MySQL supporta CDC.
L'attributo AUTO_INCREMENT di una colonna non viene migrato a 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 è possibile utilizzare le repliche Aurora MySQL come origine, a AWS DMS meno che la modalità attività di migrazione DMS non sia Migra dati esistenti, solo a pieno carico.
Se l'origine compatibile con MySQL viene arrestata durante il caricamento completo, l'attività AWS DMS non si arresta 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 nella destinazione.
In alcuni casi, l'attività è configurata per non essere replicata LOBs (» SupportLobs "è false nelle impostazioni dell'attività oppure l'opzione Non includere le colonne LOB è stata scelta nella console attività). In questi casi, AWS DMS non migra alcuna colonna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT e LONGTEXT verso la destinazione.

Le colonne BLOB, TINYBLOB, TEXT e TINYTEXT non sono interessate e vengono migrate nella 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.
Se si esegue la migrazione tra due cluster Amazon RDS Aurora MySQL, l'endpoint di origine RDS Aurora MySQL deve essere un'istanza di lettura/scrittura, non un'istanza di replica.
AWS DMS attualmente non supporta la migrazione delle visualizzazioni per MariadB.
AWS DMS non supporta le modifiche DDL per le tabelle partizionate per MySQL. Per ignorare la sospensione della tabella per le modifiche DDL della partizione durante CDC, imposta skipTableSuspensionForPartitionDdl su 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 in MariadB versione 10.6 o successiva Per ulteriori informazioni, vedi quanto segue. 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 avanzato di Aurora MySQL.
AWS DMS non supporta la compressione delle transazioni di log binario.
AWS DMS non propaga gli eventi ON DELETE CASCADE e ON UPDATE CASCADE per i database MySQL utilizzando il motore di archiviazione InnoDB. Per questi eventi, MySQL non genera eventi binlog per riflettere le operazioni a cascata sulle tabelle secondarie. Di conseguenza, non AWS DMS è possibile 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:
- Crea in anticipo la tabella di destinazione nel database di destinazione e crea l'attività AWS DMS con l'impostazione dell'attività di pieno carico DO_NOTHING o TRUNCATE_BEFORE_LOAD.
- 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.
A causa della limitazione interna di MySQL AWS DMS , può BINLOGs elaborare dimensioni non superiori a 4 GB. BINLOGs più di 4 GB possono causare errori nelle attività DMS o altri comportamenti imprevedibili. È necessario ridurre le dimensioni delle transazioni per evitare transazioni superiori a 4 GB. BINLOGs

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:

Assicurati che l'utente dell' AWS DMS endpoint disponga 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 o successiva.

Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS

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

La tabella riportata di seguito mostra le impostazioni degli endpoint che è possibile utilizzare con MySQL come origine.

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`	Per AWS DMS le versioni 3.4.7 e successive, imposta il timeout dell'istruzione client per un endpoint di origine MySQL, in secondi. Valore predefinito: 60 Esempio: `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Specifica il fuso orario del database di origine MySQL. Esempio: `--my-sql-settings '{"ServerTimezone": "US/Pacific"}'`
`AfterConnectScript`	Speciifica uno script da eseguire immediatamente dopo la connessione all'endpoint. AWS DMS L'esecuzione dell'attività di migrazione continua a prescindere se l'istruzione SQL riesce o non riesce. I valori validi: una o più istruzioni SQL valide, attivate 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'alterazione DDL sulla tabella potrebbe avere come risultato informazioni diverse relative alla tabella memorizzata nella cache nell'istanza di replica. booleano. Valore predefinito: `false` Esempio: `--my-sql-settings '{"CleanSrcMetadataOnMismatch": false}'`
`skipTableSuspensionForPartitionDdl`	AWS DMS non supporta le modifiche DDL per le tabelle partizionate per MySQL. Per AWS DMS le versioni 3.4.6 e successive, impostandola in modo da `true` ignorare la sospensione della tabella per le modifiche DDL della partizione durante il 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`	Per AWS DMS le versioni 3.5.0 e successive, specifica 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 MySQL

La tabella seguente mostra i tipi di dati di origine del database MySQL supportati durante l' AWS DMS utilizzo e la AWS DMS mappatura predefinita dei 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 sui tipi di AWS DMS dati, vedere. Tipi di dati per AWS Database Migration Service

Tipi di dati MySQL	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 DATETIME senza un valore tra parentesi viene replicato senza millisecondi. DATETIME con un valore tra parentesi compreso tra 1 e 5 (ad esempio `DATETIME(5)`) viene replicato con i millisecondi. Quando si replica una colonna DATETIME, l'ora rimane la stessa sulla destinazione. Non viene convertita in UTC.
TIME	STRING
TIMESTAMP	DATETIME Quando si replica una colonna TIMESTAMP, l'ora viene convertita in UTC sulla destinazione.
ANNO	INT2
DOUBLE	REAL8
FLOAT	REAL(DOUBLE) Se i valori FLOAT non sono compresi nell'intervallo seguente, usa una trasformazione per mappare FLOAT su STRING. Per ulteriori informazioni sulle trasformazioni, consulta Operazioni e regole di trasformazione. L'intervallo FLOAT supportato è da -1.79E+308 a -2.23E-308, 0 e da 2.23E-308 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	STRINGA () `length` Qui `length` è la lunghezza del valore più lungo nell'ENUM.
SET	STRINGA () `length` Qui `length` è la lunghezza totale di tutti i valori nel SET, comprese le virgole.
JSON	CLOB

Nota

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

Avvertimento JavaScript è disabilitato o non è disponibile nel tuo browser.

Per usare la documentazione AWS, JavaScript deve essere abilitato. Consulta le pagine della guida del browser per le istruzioni.

Convenzioni dei documenti

Utilizzo di PostgreSQL come origine

Utilizzo di SAP ASE come origine