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 compatibile con MySQL come fonte 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 come AWS DMS sorgente, vedere. [Fonti per AWS DMS](CHAP_Introduction.Sources.md)
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](CHAP_Security.SSL.md).
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 di database compatibili con MySQL AWS DMS, vedere le seguenti sezioni.
**Topics**
+ [Migrazione da MySQL a MySQL utilizzando AWS DMS](#CHAP_Source.MySQL.Homogeneous)
+ [Utilizzo di qualsiasi database compatibile con MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.Prerequisites)
+ [Utilizzo di un database autogestito compatibile con MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.CustomerManaged)
+ [Utilizzo di un AWS database compatibile con MySQL gestito come fonte per AWS DMS](#CHAP_Source.MySQL.AmazonManaged)
+ [Limitazioni all'utilizzo di un database MySQL come fonte per AWS DMS](#CHAP_Source.MySQL.Limitations)
+ [Supporto per transazione XA](#CHAP_Source.MySQL.XA)
+ [Impostazioni degli endpoint quando si utilizza MySQL come sorgente per AWS DMS](#CHAP_Source.MySQL.ConnectionAttrib)
+ [Tipi di dati di origine per MySQL](#CHAP_Source.MySQL.DataTypes)
**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.
## 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.
**Nota**
Per la versione 10.5.2\$1 di MariadB, puoi usare BINLOG MONITOR, che sostituisce REPLICATION CLIENT.
+ **REPLICATION SLAVE**: questo privilegio è richiesto per le attività di sola CDC. In altre parole, le attività non richiedono questo privilegio full-load-only.
+ **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 ;
grant select on mysql.db to ;
grant select on mysql.tables_priv to ;
grant select on mysql.role_edges to #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to ; #Required for primary instance validation - MySQL version 5.7 and higher only
```
Se utilizzi una fonte RDS e intendi eseguire valutazioni di premigrazione specifiche per MySQL, aggiungi la seguente autorizzazione:
```
grant select on mysql.rds_configuration to ; #Required for binary log retention check
```
Se il parametro `BatchEnable` è, è necessario concedere: `true`
```
grant create temporary tables on ``.* to ;
```
## 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) 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?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/)
+ 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) 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'`ALTER TABLE table_name ADD COLUMN column_name`istruzione 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 \$1.
+ 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups).
L'edizione Serverless v2 compatibile con Aurora MySQL supporta CDC.
+ L'attributo AUTO\$1INCREMENT 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](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html).
+ **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 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\$1ten\$1chars 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 delle 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](#CHAP_Source.MySQL.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](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes).
+ AWS DMS non acquisisce le modifiche alle colonne calcolate (`VIRTUAL`e`GENERATED 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](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md).
+ 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
+ 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](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), 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.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/dms/latest/userguide/CHAP_Source.MySQL.html)
## 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](CHAP_Reference.DataTypes.md)
| 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](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). L'intervallo FLOAT supportato è da -1.79E\$1308 a -2.23E-308, 0 e da 2.23E-308 a 1.79E\$1308 |
| 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.