Quali sono le best practice da seguire quando si esegue la migrazione di un database RDS MySQL di origine a un database MySQL RDS di destinazione utilizzando AWS DMS?

Breve descrizione

Utilizzando AWS DMS, puoi migrare i dati da un datastore di origine a un datastore di destinazione. Questi due datastore sono denominati endpoint. È possibile eseguire la migrazione tra endpoint di origine e destinazione che utilizzano lo stesso motore di database, ad esempio da un database MySQL a un altro database MySQL.

Sebbene AWS DMS crei gli oggetti dello schema di destinazione, crea solo gli oggetti minimi necessari per la corretta migrazione dei dati dall'origine. Pertanto, AWS DMS crea tabelle, chiavi primarie e, in alcuni casi, indici univoci, ma non crea oggetti come indici secondari, vincoli di chiave non primaria e valori predefiniti dei dati. Per ulteriori informazioni sulla migrazione di AWS DMS, consulta la sezione Presentazione generale di AWS DMS.

Creazione preliminare delle tabelle nel database di destinazione prima della migrazione

Per conservare le definizioni dei dati predefinite, crea preliminarmente le tabelle nel database di destinazione prima della migrazione. A seconda del tipo di migrazione che stai eseguendo, utilizza uno dei seguenti approcci:

• Per migrazioni omogenee come da MySQL a MySQL, utilizza i servizi nativi del motore di database come mysqldump per eseguire un'esportazione delle definizioni delle tabelle. Quindi, importa queste definizioni di tabella nella destinazione senza i dati. Dopo aver creato le definizioni delle tabelle, utilizza l'attività AWS DMS con la modalità di preparazione della tabella di destinazione impostata su TRUNCATE_BEFORE_LOAD per caricare i dati.
• Per le migrazioni tra diversi motori di database, utilizza lo Strumento di conversione dello schema AWS (AWS SCT). Puoi utilizzare questo metodo anche per database omogenei. AWS SCT si connette ai database di origine e di destinazione, quindi converte lo schema di database esistente da un motore di database a un altro. Puoi utilizzare AWS SCT per creare preliminarmente le tabelle sul database di destinazione con le definizioni dei dati predefinite intatte. Quindi, utilizza l'attività AWS DMS con la modalità di preparazione della tabella di destinazione impostata su TRUNCATE_BEFORE_LOAD per caricare i dati. Per ulteriori informazioni, consulta la sezione Conversione degli schemi di database utilizzando AWS SCT.

Risoluzione

Segui le best practice per la migrazione da MySQL a MySQL AWS DMS

Quando esegui la migrazione dei dati da un database di origine MySQL a un database di destinazione MySQL usa le seguenti best practice.

• Durante la migrazione disattiva i backup e i registri specifici del database (ad esempio bin, general e audit) sul database di destinazione. Se necessario, puoi riattivarli per risolvere eventuali problemi.
• Durante la migrazione disattiva i trigger, gli altri cron job e gli scheduler di eventi sul database di destinazione.
• Quando esegui la migrazione con AWS DMS evita di usare Multi-AZ nel database Amazon RDS di destinazione.
• Durante l'esecuzione della migrazione evita di applicare qualsiasi altro traffico client esterno al database di destinazione.
• Effettua il provisioning dell'istanza di replica e dei database di origine e di destinazione di AWS DMS con la CPU, la memoria, l'archiviazione e gli IOPS necessari per evitare conflitti di risorse durante la migrazione.
• Configura il database di origine con i prerequisiti per l'utilizzo di AWS DMS Change Data Capture (CDC) prima di iniziare la migrazione.
• Per la migrazione, utilizza impostazioni LOB ottimizzate come LOB limitato e LOB in linea.
• Se il database di origine contiene molte tabelle con un carico di lavoro elevato, suddividi le tabelle tra più attività. Suddividi le tabelle in base alla loro dimensione nel database di origine, al modello di traffico delle applicazioni e alla presenza di colonne LOB. Se la tabella ha molte colonne LOB (TEXT o JSON) con traffico di scrittura elevato sull'origine, crea un'attività separata per la tabella. La coerenza transazionale viene mantenuta all'interno di un'attività, quindi è importante che le tabelle in attività separate non partecipino a transazioni comuni.
• Per ridurre i tempi di migrazione utilizza il meccanismo parallelo a caricamento completo per tabelle di origine pesanti. Per ulteriori informazioni, consulta la sezione Utilizzo del carico parallelo per tabelle, visuali e raccolte selezionate.
• Durante la migrazione a caricamento completo disattiva i vincoli di chiave esterna sulla tabella di destinazione.
• Aggiungi l'indice secondario sul database di destinazione prima di avviare la fase di replica CDC.
• L'utente principale di Amazon RDS non dispone dei privilegi di rilascio e nuova creazione sulle tabelle degli schemi predefinite. Pertanto, evita di migrare il database o le tabelle degli schemi predefiniti dall'origine utilizzando AWS DMS.
• Per informazioni sui tipi di dati che AWS DMS può migrare correttamente, consulta la documentazione relativa all'utilizzo di AWS DMS per la migrazione dei dati da MySQL a MySQL.
• Testa il carico di lavoro utilizzando l'applicazione CDC transazionale predefinita prima di utilizzare il metodo CDC di applicazione batch. Per maggiori informazioni, consulta la sezione In che modo è possibile utilizzare la funzione di applicazione batch DMS per migliorare le prestazioni di replica CDC?
• Prima di avviare la migrazione in fase di produzione, testala utilizzando gli stessi dati della fase di produzione su qualsiasi altro ambiente di database QA/DEV. Assicurati di utilizzare la stessa configurazione di AWS DMS quando esegui la migrazione in fase di produzione.

Per ulteriori informazioni, consulta la sezione Migliorare le prestazioni di una migrazione AWS DMS.

Utilizza la configurazione e i metodi consigliati sui database di origine e di destinazione

1. Crea preliminarmente la tabella DDL in modo manuale sui database MySQL/PostgreSQL di destinazione. Quindi, crea un'attività AWS DMS con la modalità di preparazione del target impostata su "DO_DOTHING/TRUNCATE" per migrare solo i dati.

Esegui questo comando per creare un dump senza dati dal database MySQL di origine:

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

Questo comando esegue il dump della struttura DDL dall'origine senza dati.

Quindi, esegui questo comando per ripristinare la struttura DDL sulla destinazione:

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

In alternativa, puoi consentire ad AWS DMS di creare le tabelle sulla destinazione utilizzando la modalità di preparazione della destinazione DROP AND CREATE. Quindi, vai al passaggio 3 per modificare la tabella e aggiungere oggetti mancanti come indici secondari prima di riprendere l'attività per la fase CDC.

Nota: per impostazione predefinita, AWS DMS crea la tabella sulla destinazione unicamente con la chiave primaria o la chiave univoca. Non esegue la migrazione di altri oggetti nel database MySQL di destinazione.

2. Durante il caricamento completo, AWS DMS non identifica le tabelle relazionali a chiave esterna. Carica i dati in modo casuale, pertanto se il database di destinazione ha un controllo della chiave esterna attivato il caricamento della tabella può non riuscire. Usa questo attributo di connessione extra (ECA) sull'endpoint MySQL di destinazione per disattivare i controlli delle chiavi esterne per questa sessione AWS DMS.

initstmt=SET FOREIGN_KEY_CHECKS=0;

Per maggiori informazioni, consulta la sezione Attributi di connessione aggiuntivi quando si utilizza un database compatibile con MySQL come destinazione per AWS DMS.

3. Nelle impostazioni JSON, imposta l'interruzione dell'attività prima dell'applicazione delle modifiche memorizzate nella cache su true (vero) e l'interruzione dell'attività dopo l'applicazione delle modifiche memorizzate nella cache su true (vero).

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

Al termine del caricamento completo e prima di applicare le modifiche memorizzate nella cache, l'attività si interrompe. Mentre l'attività viene interrotta, crea indici di chiave primaria e indici secondari sulla destinazione.

Quindi, riprendi l'attività perché questa si interrompe nuovamente dopo aver applicato le modifiche memorizzate nella cache. A questo punto, verifica i dati migrati utilizzando l'output di convalida di AWS DMS o la verifica manuale prima di riprendere nuovamente l'attività per la fase di replica CDC. Completando questo passaggio, è possibile identificare eventuali problemi e risolverli prima di riprendere la replica CDC.

4.    Nelle impostazioni di caricamento completo dell'attività, regola l'impostazione commitRate per accelerare la velocità di estrazione dei dati dall'origine. Il valore predefinito è 10.000, quindi regola questa impostazione quando esegui la migrazione di una grande quantità di dati dalla tabella di origine.

CommitRate=50000

Nota: la modifica di commitRate su un valore più elevato potrebbe influire sulle prestazioni, pertanto assicurati di disporre di memoria sufficiente e di monitorarla nell'istanza di replica.

5.    Aggiungi questo ECA sull'endpoint di destinazione per specificare la dimensione massima (in KB) di qualsiasi file .csv utilizzato per trasferire i dati al MySQL di destinazione. Il valore predefinito è 32.768 KB (32 MB) e i valori validi vanno da 1 a 1.048.576 KB (fino a 1,1 GB).

maxFileSize=250000;

Nota: quando utilizzi un'istanza di destinazione come MySQL, Aurora o MariaDB per il caricamento completo, utilizza questa opzione per consentire ad AWS DMS di creare un file .csv in background per caricare i dati nell'istanza di destinazione. Utilizza un valore compreso tra 32 MB e 1 GB. Tuttavia, tieni anche in considerazione quanto è in grado di gestire l'istanza di destinazione. Se sono presenti più attività che caricano 1 GB di file.csv, ciò può causare un sovraccarico sull'istanza di destinazione. Assicurati di avere un'istanza con un'elevata potenza di calcolo sulla destinazione.

6.    Utilizza le impostazioni LOB limitate o LOB in linea per prestazioni migliori.

Modalità LOB limitata: quando si utilizza la modalità LOB limitata, si specifica la dimensione massima dei dati della colonna LOB. Ciò consente ad AWS DMS di allocare preventivamente le risorse e quindi applicare LOB in blocco. Se la dimensione delle colonne LOB supera la dimensione specificata nell'attività, AWS DMS tronca i dati. AWS DMS invia quindi avvisi al file di registro di AWS DMS. L'utilizzo della modalità LOB limitata migliora le prestazioni, tuttavia, prima di eseguire l'attività, è necessario identificare la dimensione massima LOB dei dati nell'origine. Quindi, specificare il parametro Dimensione massima LOB. Una best practice consiste nell'assicurarsi di disporre di memoria sufficiente allocata all'istanza di replica per gestire l'attività.

Modalità LOB in linea: quando si utilizza la modalità LOB in linea, è possibile migrare i LOB senza troncare i dati o rallentare le prestazioni delle attività, replicando LOB di piccole e grandi dimensioni. Innanzitutto, specificate un valore per il parametro InlineLobMaxSize, disponibile solo quando la modalità Full LOB è impostata su true (vero). L'attività AWS DMS trasferisce i piccoli LOB in linea, una procedura più efficiente. Quindi, AWS DMS esegue la migrazione di LOB più grandi della dimensione specificata in modalità LOB completa eseguendo una ricerca dalla tabella di origine. Tuttavia, è bene notare che la modalità LOB in linea funziona solo durante la fase di caricamento completo.

Nota: è necessario impostare InlineLobMaxSize quando si specificano le impostazioni dell'attività per l'attività.

Eseguire queste query per verificare la dimensione LOB, quindi compilare la dimensione massima della LOB.

Elencare le tabelle con colonne LOB:

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

Controllare le dimensioni della colonna LOB:

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

Controllare la dimensione delle colonne LOB per tutte le tabelle, quindi inserire la dimensione massima in Dimensione massima LOB (K).

L'utilizzo dell'opzione Dimensione massima LOB (K) con un valore superiore a 63 KB influisce sulle prestazioni di un caricamento completo configurato per l'esecuzione in modalità LOB limitata. Durante un caricamento completo, AWS DMS alloca la memoria moltiplicando il valore Dimensione massima LOB (K) per la velocità di commit. Quindi, il prodotto viene moltiplicato per il numero di colonne LOB.

Quando AWS DMS non è in grado di allocare preventivamente quella memoria, AWS DMS inizia a consumare memoria SWAP. Ciò influisce sulle prestazioni di un caricamento completo. Pertanto, se si verificano problemi di prestazioni quando si utilizza la modalità LOB limitata, ridurre la frequenza di commit fino a raggiungere un livello di prestazioni accettabile. Oppure, prendere in considerazione l'utilizzo della modalità LOB in linea per gli endpoint supportati dopo aver prima controllato la distribuzione LOB per la tabella.

Per ulteriori informazioni, consulta la sezione Impostazione del supporto LOB per i database di origine in un'attività AWS DMS.

---

Informazioni correlate

Migrazione da MySQL ad Amazon RDS con AWS DMS

Procedure dettagliate sulla migrazione del database