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 Sorgenti Aurora MySQL 8.4 Limitazioni su MySQL come origine Supporto per transazione XA Impostazioni degli endpoint Tipi di dati di origine per MySQL

Utilizzo di un MySQL-compatible database come fonte per AWS DMS

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

Per informazioni sulle versioni di MySQL supportate come AWS DMS sorgente, vedere. Fonti per AWS DMS

È possibile utilizzare SSL per crittografare le connessioni tra l' MySQL-compatible endpoint e l'istanza di replica. Per ulteriori informazioni sull'utilizzo di SSL con un endpoint, consulta. MySQL-compatible Utilizzo di SSL con AWS Database Migration Service

Nelle sezioni seguenti, il termine "autogestito" si applica a qualsiasi database installato on-premise 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 MySQL-compatible dei database e AWS DMS, consulta le seguenti sezioni.

Argomenti

Migrazione da MySQL a MySQL utilizzando AWS DMS
MySQL-compatible Utilizzare qualsiasi database come fonte per AWS DMS
Utilizzo di un MySQL-compatible database autogestito come fonte per AWS DMS
Utilizzo di un AWS MySQL-compatible -database gestito come fonte per AWS DMS
Considerazioni sui sorgenti Aurora MySQL 8.4
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

Nota

Quando si configurano le regole di mappatura AWS Database Migration Service (AWS DMS), è importante evitare l'uso di caratteri jolly (%) per i nomi di database o schemi. È invece necessario specificare in modo esplicito solo i database creati dall'utente che devono essere migrati. L'utilizzo di un carattere jolly include tutti i database nel processo di migrazione, inclusi i database di sistema che non sono necessari nell'istanza di destinazione. Poiché l'utente master MySQL di Amazon RDS non dispone delle autorizzazioni necessarie per importare i dati nei database del sistema di destinazione, il tentativo di migrare questi database di sistema non riesce.

Migrazione da MySQL a MySQL utilizzando 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.

MySQL-compatible Utilizzare qualsiasi database 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 alle fonti autogestite o 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, solo le attività di caricamento completo non richiedono questo privilegio.

Nota
Per la versione 10.5.2+ di MariadB, puoi usare BINLOG MONITOR, che sostituisce REPLICATION CLIENT.
REPLICATION SLAVE: questo privilegio è richiesto per le attività di sola CDC. In altre parole, solo le attività di caricamento completo 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 MySQL-specific le valutazioni di premigrazione:


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
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Se utilizzi una fonte RDS e intendi eseguire valutazioni di MySQL-specific premigrazione, aggiungi la seguente autorizzazione:


grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Se il parametro BatchEnable ètrue, è necessario concedere:


grant create temporary tables on `<schema>`.* to <dms_user>;

Utilizzo di un MySQL-compatible database autogestito come fonte per AWS DMS

È possibile utilizzare i seguenti MySQL-compatible database autogestiti come fonti 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` or `binlog_expire_logs_seconds`	Il parametro expire_logs_days è obsoleto a partire da MySQL 8.0 e rimosso in MySQL 8.4. Per ulteriori informazioni, consulta Variabili e opzioni del server e di stato aggiunte, obsolete o rimosse in MySQL 8.4 dalla versione 8.0. Usa il `expire_logs_days` parametro per MySQL 5.x. Si consiglia di impostare questo parametro su `1` o superiore, vedere Opzioni e variabili di registrazione binaria. Usa il `binlog_expire_logs_seconds` parametro per MySQL 8.0 e versioni successive. Si consiglia di impostare questo parametro su un valore di `86400` secondi (1 giorno) o superiore. Vedi Opzioni e variabili di registrazione binaria.
`binlog_checksum`	Imposta questo parametro su `NONE` DMS versione 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 MySQL-compatible -database gestito come fonte per AWS DMS

È possibile utilizzare i seguenti MySQL-compatible database AWS gestiti come fonti per: AWS DMS

MySQL Community Edition
MariaDB Community Edition
Edizione Amazon Aurora MySQL-Compatible

Quando utilizzi un MySQL-compatible database AWS gestito come origine 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é MySQL-compatible i database AWS gestiti 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 AWS DMS impedire la corretta acquisizione di tutte le modifiche nel 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.

Per ulteriori informazioni sulle modifiche alla sicurezza di Aurora MySQL 8.4, consulta Sicurezza con Amazon Aurora MySQL e gestione delle password con Amazon Aurora e Secrets Manager nella Guida per l'utente di Amazon Aurora.

Considerazioni sui sorgenti Aurora MySQL 8.4

Aurora MySQL 8.4 introduce modifiche di sicurezza che possono influire sulla connettività degli endpoint di origine. AWS DMS Leggi quanto segue prima di aggiornare il codice sorgente Aurora MySQL alla versione 8.4.

Applicazione del protocollo TLS

Aurora MySQL 8.4 è impostato su come impostazione ON predefinita, il che significa che tutte require_secure_transport le connessioni devono utilizzare TLS. Se l'endpoint di AWS DMS origine si connette ad Aurora MySQL 8.4 e la modalità SSL è impostata su nessuna, le connessioni verranno rifiutate. Se la modalità SSL dell'endpoint è impostata su Nessuno, riceverai il seguente errore:. MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON Imposta la modalità SSL dell'endpoint su verify-ca o verify-full. Entrambe le modalità richiedono un certificato CA. In alternativa, imposta su require_secure_transport OFF nel gruppo di parametri del cluster Aurora per consentire connessioni non crittografate.

Nota

Aurora MySQL 8.4 supporta solo le suite di crittografia GCM per TLS 1.2. CBC-mode Tutti i codici sono stati rimossi. AWS DMS utilizza TLS 1.2 per gli endpoint MySQL e Aurora MySQL e negozierà automaticamente un codice GCM supportato. Se disponi di configurazioni di crittografia personalizzate, verifica che includano una delle seguenti cifre supportate:,, o. ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384

Nota

AWS DMS non supporta TLS 1.3 per endpoint MySQL. Ciò non influisce sulla connettività ad Aurora MySQL 8.4, poiché Aurora MySQL 8.4 continua a supportare TLS 1.2.

Autenticazione (Aurora MySQL e RDS per MySQL 8.4)

Aurora MySQL 8.4 sostituisce il parametro con, che per impostazione predefinita è. default_authentication_plugin authentication_policy *:caching_sha2_password Gli utenti del database esistenti mantengono il plug-in di autenticazione corrente dopo l'aggiornamento. Se crei nuovi utenti dell' AWS DMS endpoint dopo l'aggiornamento, questi verranno utilizzati per impostazione caching_sha2_password predefinita, a meno che non lo impostiate *:mysql_native_password nel gruppo authentication_policy di parametri del cluster.

Reimpostazione della password dell'utente principale

Dopo l'aggiornamento ad Aurora MySQL 8.4, la reimpostazione della password dell'utente principale tramite la Console di gestione AWS CLI o tramite la rotazione di Secrets Manager imposta il plug-in di autenticazione dell'utente principale sul valore predefinito definito dal parametro. authentication_policy Se authentication_policy è impostato sul valore predefinito (*:caching_sha2_password), il plug-in di autenticazione dell'utente principale cambia da a alla successiva reimpostazione della password. mysql_native_password caching_sha2_password

Se l'endpoint di AWS DMS origine utilizza l'account utente principale, verifica la connettività dopo ogni reimpostazione della password. Per evitare modifiche al plug-in di autenticazione, procedi nel seguente modo:

Imposta authentication_policy su *:mysql_native_password nel gruppo di parametri del cluster prima di reimpostare la password, oppure
Crea un utente AWS DMS endpoint dedicato con un plug-in di autenticazione specificato in modo esplicito (consigliato). Ad esempio: CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

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'ALTER TABLE table_name ADD COLUMN column_nameistruzione per aggiungere colonne all'inizio (FIRST) o al centro di una tabella (AFTER) non è supportato per gli obiettivi relazionali. Le colonne vengono sempre aggiunte alla fine della tabella. Quando la destinazione è Amazon S3 o Amazon Kinesis Data Streams, è supportata l'aggiunta di colonne utilizzando FIRST o AFTER.
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 MySQL-Compatible 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.

Aurora MySQL-Compatible Edition Serverless v2 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' MySQL-compatible origine viene interrotta durante il caricamento completo, l' AWS DMS attività 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 nella destinazione.
In alcuni casi, l'attività è configurata per non replicare i LOB (» 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 MySQL di RDS Aurora deve essere un'istanza, non un'istanza di replica. read/write
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, vedere quanto segue. Supporto per transazione XA
AWS DMS non utilizza i GTID 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:
- Pre-create la tabella di destinazione nel database di destinazione e crea l' AWS DMS attività con l'impostazione dell'attività DO_NOTHING 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.
A causa della limitazione interna di MySQL AWS DMS , può elaborare BinLogs di dimensioni non superiori a 4 GB. I BinLogs di dimensioni superiori a 4 GB possono causare errori nelle attività DMS o altri comportamenti imprevedibili. È necessario ridurre le dimensioni delle transazioni per evitare BinLogs di dimensioni superiori a 4 GB.
AWS DMS non supporta back-tick (`) o virgolette singole (') nei nomi di schemi, tabelle e colonne.
AWS DMS non migra i dati dalle colonne invisibili del database di origine. Per includere queste colonne nell'ambito di migrazione, utilizzate l'istruzione ALTER TABLE per rendere visibili queste colonne.

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	Description
`ConnectionTimeout`	Usa questo attributo di connessione aggiuntivo (ECA) per impostare il timeout di connessione all'endpoint per l'istanza MySQL, in secondi. Il valore predefinito è 10 secondi. Esempio ECA:. `ConnectionTimeout=30`
`EventsPollInterval`	Speciifica la frequenza con cui verificare la presenza di nuovi dati nel registro binario changes/events quando il database è inattivo. Valore predefinito: 5 Valori validi: 1-60 Ad 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 Ad esempio: `--my-sql-settings '{"ExecuteTimeout": 1500}'`
`ServerTimezone`	Specifica il fuso orario del database di origine MySQL. Ad 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. Ad esempio: `--my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'`
`CleanSourceMetadataOnMismatch`	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` Ad esempio: `--my-sql-settings '{"CleanSourceMetadataOnMismatch": 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 le DDL relative alla tabella partizionata e continua a elaborare ulteriori modifiche al registro binario. Valore predefinito: `false` Ad 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` Ad 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 è compreso tra -1,79E+308 e -2,23E-308, 0 e tra 2,23 e 1,79E+308 E-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	`length`STRINGA () 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.

Convenzioni dei documenti

Utilizzo di PostgreSQL come origine

Utilizzo di SAP ASE come origine