Migrazione dei dati da MySQL a Database di Azure per MySQL - Snapshot coerente con MySQL
Lo snapshot coerente con MySQL è una nuova funzionalità che consente agli utenti di acquisire uno snapshot coerente di un server MySQL senza perdere l'integrità dei dati all'origine a causa delle operazioni CRUD (creazione, lettura, aggiornamento ed eliminazione) in corso. La coerenza transazionale viene ottenuta senza la necessità di impostare il server di origine sulla modalità di sola lettura tramite questa funzionalità. Sono inoltre disponibili più opzioni di coerenza dei dati presentate all'utente: Abilita snapshot coerenti con blocco in lettura (disponibilità generale), Abilita snapshot coerenti senza blocchi (anteprima), Rendi il server di origine di sola lettura e Nessuno. La selezione dell'opzione "Nessuno" comporta l'assenza di misure aggiuntive per garantire la coerenza dei dati. Entrambe le opzioni, l'abilitazione di snapshot coerenti con blocco in lettura (disponibilità generale) e di snapshot coerenti senza blocchi, supportano l'esecuzione di una migrazione online. È consigliabile selezionare l'opzione "Abilita snapshot coerente senza blocchi" per mantenere la coerenza transazionale.
Abilitare snapshot coerenti senza blocchi (anteprima)
Quando si abilita questa opzione, si verificherà una fase di riconciliazione dopo il caricamento iniziale. Ciò consente di garantire che i dati scritti nella destinazione siano coerenti in modo transazionale con il server di origine da una posizione specifica nel log binario.
Con questa funzionalità non viene eseguito un blocco di lettura sul server. Le tabelle vengono invece lette in un momento diverso, tenendo traccia delle diverse posizioni binlog di ogni tabella. Ciò contribuisce a risolvere le differenze tra le tabelle verso la fine del carico iniziale eseguendo la replica in modalità catchup per ottenere uno snapshot coerente.
Funzionalità chiave di snapshot coerente senza blocchi:
- Possibilità di supportare server con carichi di lavoro pesanti o con transazioni a esecuzione prolungata senza la necessità di blocchi di lettura.
- Resilienza nel completamento delle migrazioni anche in caso di errori causati da blip di rete/server temporanei che causano la perdita di tutte le connessioni create in modo preliminare.
Abilitare snapshot coerenti con blocco in lettura (disponibilità generale)
Quando si abilita questa opzione, il servizio scarica tutte le tabelle nel server di origine con un blocco letto per ottenere lo snapshot temporizzato. Questo scaricamento viene eseguito perché un blocco globale è più affidabile rispetto al tentativo di bloccare singoli database o tabelle. Di conseguenza, anche se non si esegue la migrazione di tutti i database in un server, questi vengono bloccati durante la configurazione del processo di migrazione. Il servizio di migrazione avvia una lettura ripetibile e combina lo stato della tabella corrente con il contenuto del log di annullamento per lo snapshot. Lo snapshot viene generato dopo aver ottenuto il blocco a livello di server per alcuni secondi e aver generato diverse connessioni per la migrazione. Dopo la creazione di tutte le connessioni usate per la migrazione, i blocchi nella tabella vengono rilasciati.
Le letture ripetibili sono abilitate per mantenere accessibili i log di annullamento durante la migrazione, aumentando così lo spazio di archiviazione necessario nell'origine a causa di connessioni a esecuzione prolungata. Una migrazione a esecuzione prolungata con più modifiche alla tabella comporta un'ampia cronologia dei log di annullamento che deve essere riprodotta e potrebbe anche aumentare i requisiti di calcolo e il carico nel server di origine.
Imposta il server di origine come di sola lettura
Se si seleziona questa opzione, l'integrità dei dati del database di destinazione viene mantenuta durante la migrazione dell'origine impedendo operazioni di scrittura/eliminazione nel server di origine durante la migrazione stessa. Quando si rende di sola lettura il server di origine come parte del processo di migrazione, la selezione si applica a tutti i database del server di origine, indipendentemente dal fatto che siano selezionati per la migrazione.
Rendere il server di origine in sola lettura impedisce agli utenti di modificare i dati, rendendo il database non disponibile per le operazioni di aggiornamento. Tuttavia, se questa opzione non è abilitata, c’è la possibilità che gli aggiornamenti dei dati vengano eseguiti durante la migrazione. Di conseguenza, i dati sottoposti a migrazione potrebbero non essere coerenti perché gli snapshot del database vengono letti in momenti diversi.
Prerequisiti per l'abilitazione di snapshot coerenti con il blocco in lettura
Per completare correttamente la migrazione con snapshot coerente con blocco di lettura abilitato:
Assicurarsi che l'utente che sta tentando di scaricare le tabelle con un blocco di lettura disponga dell'autorizzazione RELOAD o FLUSH.
Usare lo strumento client mysql per determinare se log_bin è abilitato nel server di origine. Il log Bin non è sempre attivato per impostazione predefinita e deve essere controllato per verificare se sia abilitato prima di avviare la migrazione. Lo strumento client mysql viene usato per determinare se log_bin è abilitato nell'origine eseguendo il comando: SHOW VARIABLES LIKE 'log_bin';
Nota
Con il server singolo del Database di Azure per MySQL, cche supporta fino a 4 TB, questo non è abilitato per impostazione predefinita. Tuttavia, se si alza di livello una replica di lettura per il server di origine e quindi si elimina la replica di lettura, il parametro è impostato su ON.
- 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. Dopo il cutover riuscito, il valore può essere reimpostato.
Problemi noti e limitazioni per l'abilitazione di snapshot coerenti senza blocchi
- Le tabelle con chiavi esterne che dispongono della clausola Cascata o Imposta su null all'eliminazione/aggiornamento non sono supportate.
- Non devono verificarsi modifiche DDL durante il caricamento iniziale.
Problemi noti e limitazioni per l'abilitazione di snapshot coerenti con blocchi di lettura
I problemi noti e le limitazioni associati al backup coerente rientrano in due categorie: blocchi e tentativi.
Nota
Il servizio di migrazione esegue la query START TRANSACTION WITH CONSISTENT SNAPSHOT per tutti i thread di lavoro per ottenere lo snapshot del server. Tuttavia, l'operazione è supportata solo da InnoDB. Altre informazioni sono reperibili qui.
Locks
In genere, ottenere un blocco è un processo semplice che richiede da pochi secondi a pochi minuti. In alcuni scenari, tuttavia, i tentativi di ottenere un blocco nel server di origine possono non riuscire.
La presenza di query a esecuzione prolungata potrebbe comportare tempi di inattività non necessari, perché il Servizio Migrazione del database potrebbe bloccare un subset delle tabelle e quindi raggiungere il timeout in attesa dell'ultima disponibilità. Prima di avviare la migrazione, verificare la presenza di operazioni a esecuzione prolungata eseguendo il comando SHOW PROCESSLIST.
Se il server di origine riscontra molti aggiornamenti di scrittura al momento della richiesta di un blocco, il blocco non può essere ottenuto immediatamente e potrebbe non riuscire dopo il timeout di attesa del blocco. Ciò si verifica nel caso di task di elaborazione batch nelle tabelle, che quando sono in corso possono comportare il rifiuto della richiesta di un blocco. Come accennato in precedenza, il blocco richiesto è un singolo blocco a livello globale per l'intero server, quindi anche se una singola tabella o database è in fase di elaborazione, la richiesta di blocco dovrà attendere la conclusione dell'attività in corso.
Un'altra limitazione riguarda la migrazione da un server di origine AWS RDS. Servizi Desktop remoto non supporta lo scaricamento delle tabelle con blocco in lettura e la query LOCK TABLE viene eseguita in background nelle tabelle selezionate. Poiché le tabelle sono bloccate singolarmente, il processo di blocco può essere meno affidabile e i blocchi possono richiedere più tempo per l'acquisizione.
Nuovi tentativi
La migrazione gestisce i problemi di connessione temporanei e le connessioni aggiuntive vengono in genere sottoposte a provisioning iniziale per questo scopo. Vengono esaminate le impostazioni di migrazione, in particolare il numero di operazioni di lettura parallele sull'origine,si applica un fattore (in genere ~1,5) e si creano tutte le connessioni in anticipo. In questo modo il servizio garantisce che sia possibile mantenere le operazioni in esecuzione in parallelo. In qualsiasi momento, se si verifica una perdita di connessione o se il servizio non è in grado di ottenere un blocco, il servizio utilizza le connessioni in eccesso per riprovare la migrazione. Se tutte le connessioni di cui è stato effettuato il provisioning vengono esaurite con conseguente perdita della sincronizzazione temporizzata, la migrazione deve essere riavviata dall'inizio. Sia in caso di esito positivo che negativo, tutte le azioni di pulizia vengono eseguite da questo servizio di migrazione offline e l'utente non deve eseguire alcuna azione di pulizia esplicita.