Seleziona le tue preferenze relative ai cookie

Utilizziamo cookie essenziali e strumenti simili necessari per fornire il nostro sito e i nostri servizi. Utilizziamo i cookie prestazionali per raccogliere statistiche anonime in modo da poter capire come i clienti utilizzano il nostro sito e apportare miglioramenti. I cookie essenziali non possono essere disattivati, ma puoi fare clic su \"Personalizza\" o \"Rifiuta\" per rifiutare i cookie prestazionali.

Se sei d'accordo, AWS e le terze parti approvate utilizzeranno i cookie anche per fornire utili funzionalità del sito, ricordare le tue preferenze e visualizzare contenuti pertinenti, inclusa la pubblicità pertinente. Per continuare senza accettare questi cookie, fai clic su \"Continua\" o \"Rifiuta\". Per effettuare scelte più dettagliate o saperne di più, fai clic su \"Personalizza\".

Preferenze
Contattaci
Feedback
AWS Documentation
Crea un Account AWS

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

PDF
RSS
Modalità Focus
Utilizzo di un database compatibile con MySQL come origine per AWS DMS - AWS Servizio di migrazione del Database
Migrazioni da MySQL a MySQLUtilizzo di MySQL come origineUtilizzo di MySQL gestito dal cliente come origineUtilizzo AWS di -managed MySQL come sorgenteLimitazioni su MySQL come origineSupporto per transazione XAImpostazioni degli endpointTipi di dati di origine per MySQL

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

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

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.

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.

In questa pagina

PrivacyCondizioni del sitoPreferenze cookie
© 2025, Amazon Web Services, Inc. o società affiliate. Tutti i diritti riservati.