Migrazione dei dati da MySQL a Database di Azure per MySQL - Replicare le modifiche MySQL
L'esecuzione di una migrazione usando la replica delle modifiche, con lo scenario offline con "Abilita coerenza transazionale" consente alle aziende di eseguire la migrazione dei database in Azure mentre i database rimangono operativi. In parole povere, è possibile completare le migrazioni con tempi di inattività minimi per le applicazioni critiche, limitando l'impatto sulla disponibilità a livello di servizio e gli inconvenienti per i clienti finali.
Nota
Questo articolo contiene riferimenti al termine slave, che Microsoft non usa più. Quando il termine verrà rimosso dal software, verrà rimosso anche dall'articolo.
Implementazione corrente
È necessario eseguire uno scenario di migrazione offline con "Abilita coerenza transazionale" per ottenere il file di log bin e la posizione per replicare le modifiche in ingresso. L'interfaccia utente del portale del Servizio Migrazione del database mostra il nome del file di log binario e la posizione allineati al momento in cui sono stati ottenuti i blocchi nell'origine per lo snapshot coerente. È possibile usare questo valore nella migrazione delle modifiche di replica per eseguire lo streaming delle modifiche in ingresso.
Durante l'esecuzione della migrazione con replica delle modifiche, quando la destinazione è quasi uguale al server di origine, arrestare tutte le transazioni in ingresso nel database di origine e attendere che tutte le transazioni in sospeso siano state applicate al database di destinazione. Per confermare che il database di destinazione sia aggiornato nel server di origine, eseguire la query "SHOW MASTER STATUS";, quindi confrontare tale posizione con l'ultimo evento binlog di cui è stato eseguito il commit (visualizzato in Stato migrazione). Quando le due posizioni sono le stesse, la destinazione ha completato tutte le modifiche ed è possibile avviare il cutover.
Funzionamento della replica delle modifiche
L'implementazione attuale si basa sullo streaming delle modifiche del binlog dal server di origine e sulla loro applicazione al server di destinazione. Analogamente alla replica dei dati in ingresso, questa operazione è più semplice da configurare e non richiede una connessione fisica tra l'origine e i server di destinazione.
Il server può inviare Binlog come flusso che contiene dati binari come documentato qui. Il client può specificare la posizione del log iniziale con cui avviare il flusso. Il nome del file di log descrive la posizione del log, la posizione all'interno del file e, facoltativamente, il GTID (ID transazione globale) se la modalità gtid è abilitata nell'origine.
Le modifiche ai dati vengono inviate come eventi di "riga", che contengono dati per singole righe (prima e/o dopo la modifica a seconda del tipo di operazione, ovvero inserimento, eliminazione o aggiornamento). Gli eventi di riga vengono quindi applicati nel formato non elaborato usando un'istruzione BINLOG: Manuale di riferimento di MySQL 8.0 :: 13.7.8.1 Istruzione BINLOG. Tuttavia, per una migrazione del Servizio Migrazione del database a un server 5.7, Il Servizio Migrazione del database non applica le modifiche come da istruzioni BINLOG (poiché il Servizio Migrazione del database non dispone dei privilegi necessari per farlo) e converte invece gli eventi di riga in istruzioni INSERT, UPDATE o DELETE.
Prerequisiti
Per completare correttamente la migrazione con replica delle modifiche, assicurarsi che siano soddisfatti i prerequisiti seguenti:
- Usare lo strumento a riga di comando MySQL preferito per determinare se log_bin sia abilitato sul server di origine. Il Binlog non è sempre attivato per impostazione predefinita, quindi verificare che sia abilitato, prima di avviare la migrazione. Per determinare se log_bin sia abilitato sul server di origine, eseguire il comando: SHOW VARIABLES LIKE 'log_bin'
- Assicurarsi che l'utente disponga dell'autorizzazione "REPLICATION_APPLIER" o "BINLOG_ADMIN" per il server di destinazione per l'applicazione del log bin.
- Verificare che l'utente disponga dell'autorizzazione "REPLICATION SLAVE" nel server di destinazione.
- Assicurarsi che l'utente disponga delle autorizzazioni "REPLICATION CLIENT" e "REPLICATION SLAVE" nel server di origine per la lettura e l'applicazione del log bin.
- Eseguire uno scenario di migrazione offline con "Abilita coerenza transazionale" per ottenere il file di log e la posizione del bin.
- Se si usa una migrazione online, configurare il parametro binlog_expire_logs_seconds nel server di origine per assicurarsi che i file binlog non vengano eliminati prima che la replica esegua il commit delle modifiche. Per iniziare, è consigliabile prevedere almeno due giorni. Dopo un cutover riuscito, è possibile ripristinare il valore.
Limiti
- Quando si esegue una migrazione con replica delle modifiche, il nome del database nel server di destinazione deve corrispondere al nome nel server di origine.
- Il supporto è limitato al formato ROW binlog.
- La replica delle modifiche DDL è supportata solo quando è stata selezionata l'opzione Replicare le istruzioni di definizione e amministrazione dei dati per gli oggetti selezionati nell'interfaccia utente del Servizio Migrazione del database. La funzionalità di replica supporta la replica delle istruzioni di definizione e amministrazione dei dati che si verificano dopo il caricamento iniziale e vengono registrate nel log binario nella destinazione.
- La ridenominazione di database o tabelle non è supportata durante la replica delle modifiche.