Le grandi organizzazioni che utilizzano piattaforme di database MySQL o MariaDB devono spesso affrontare la necessità di eseguire una migrazione del database da un luogo all'altro. Indipendentemente dalla piattaforma, dal tipo di software di database (come da RDBMS a NoSQL o NoSQL che torna a RDBMS), o se si tratta solo di una migrazione di dati, eseguire una migrazione comporta un'enorme quantità di lavoro e costi.
Una migrazione di database comporterà sempre il processo di migrazione dei dati da uno o più database di origine a uno o più database di destinazione. Ciò può comportare un servizio di migrazione del database o un insieme di strumenti mashup che gli ingegneri hanno creato per creare un servizio e adattarlo a questo tipo di problema.
Si prevede che una migrazione del database non significhi che la piattaforma del database di origine finirà per essere la piattaforma di destinazione esattamente come l'origine di origine. Una volta terminata una migrazione, il set di dati dai database di destinazione potrebbe finire per essere eventualmente ristrutturato. La cosa più importante, una volta completata la migrazione, è che i client che accedono al database vengano reindirizzati ai nuovi database di origine. Il nuovo database di origine deve fornire la copia esatta dei dati dall'origine e senza alcun impatto sulle prestazioni che potrebbe influire sull'esperienza utente complessiva.
Spostare i dati da una piattaforma alla piattaforma di destinazione di destinazione è un compito enorme da svolgere. Questo è ciò che copre una migrazione del database quando un'organizzazione o un'azienda decide di spegnere la luce sulla piattaforma attuale per numerosi motivi. I motivi comuni per la migrazione dei dati sono l'economicità alla piattaforma di destinazione di destinazione o la sua flessibilità al momento dell'implementazione e della scalabilità. Sebbene l'attuale piattaforma che ospita gli attuali dati di produzione comporti costi maggiori per gli aggiornamenti e la scalabilità, è solo onerosa quando si implementano piccole modifiche che possono essere effettivamente implementate in una piattaforma di microservizi.
In questo blog ci concentreremo sui migliori strumenti open source che puoi utilizzare per migrazioni MySQL e MariaDB su una migrazione di database più omogenea.
Strumenti di backup per la migrazione dei dati
Il percorso più semplice da utilizzare durante l'esecuzione della migrazione consiste nell'utilizzare gli strumenti di backup del database. Vedremo cosa sono questi strumenti e come puoi usarli durante la migrazione.
mysqldump/mysqlpump
Questo strumento è una delle utilità più famose per MySQL o MariaDB che un amministratore di database o un amministratore di sistema collegherà questo strumento per migrare un database completo o una copia parziale del database. Per gli amministratori di database che non hanno familiarità con MySQL/MariaDB, questo strumento ti consentirà di creare una copia del backup che genererà una copia logica dei dati che puoi scaricare sul database di destinazione.
Una configurazione comune con l'utilizzo di questo strumento è che, ogni volta che un database di destinazione si trova da qualche altra parte ed è ospitato su una piattaforma diversa da quella di origine, la destinazione agisce come uno slave o una replica. L'uso di mysqldump comunemente invocato con --single-transaction su un sistema occupato e con --master-data ti fornirà le coordinate per impostare uno slave sul database di destinazione che verrà utilizzato come host per la migrazione dei dati. Un'alternativa a mysqldump è anche mysqlpump, ma con una funzionalità minore può eseguire l'elaborazione parallela di database e oggetti all'interno di database per accelerare il processo di dump. Lo svantaggio è che, con mysqlpump, non è possibile utilizzare opzioni come --master-data che è molto utile se si desidera creare una replica che verrà utilizzata come destinazione di destinazione per la migrazione del database.
mysqlpump è vantaggioso se i tuoi dati sono più inattivi o vengono messi in modalità di manutenzione in modo tale che nessuna scrittura elaborata o modifiche in corso nel database di origine. È sempre più veloce rispetto a mysqldump.
il mio dumper/il mio caricatore
mydumper/myloader è uno strumento molto ingegnoso ed efficiente che puoi utilizzare per il backup logico soprattutto per l'importazione di dati in blocco con una velocità di elaborazione più rapida in quanto offre parallelismo, capacità di inviare dati per blocchi, supporta soglia e controllo valutare il numero di thread, le righe, la dimensione dell'istruzione e comprimere il risultato. Genera o include file di registro binari e posizioni di registro, il che è molto utile se si imposta la piattaforma di destinazione di destinazione in modo che agisca come una replica dell'ambiente di origine e di produzione corrente.
Fondamentalmente, mydumper è il binario e il comando che devi invocare tramite riga di comando per creare il backup logico. Mentre, myloader è il binario e il comando che devi usare quando carichi i dati nella destinazione di destinazione desiderata. La sua flessibilità consente di gestire la velocità desiderata durante l'elaborazione delle azioni, sia che si tratti di creare un backup o di caricare i dati. Utilizzando mydumper, puoi anche creare un backup completo o solo una copia di backup parziale del tuo database di origine. Ciò è molto utile nel caso in cui sia necessario un dato o uno schema di grandi dimensioni che si desidera allontanare dall'host del database corrente e spostarlo leggermente in un'altra destinazione di destinazione mentre si inizia a configurare un nuovo shard di database. Questo può anche essere un modo per migrare dati di grandi dimensioni estraendo un enorme segmento del set di dati e spostandolo poi come un nuovo nodo shard.
mydumper/myloader ha anche i suoi limiti. È stato interrotto dagli aggiornamenti degli autori originali ma salvato da Max Bube, tuttavia lo strumento è ancora ampiamente utilizzato anche per gli ambienti di produzione.
Backup Percona XtraBackup/MariaDB
XtraBackup di Percona è un regalo per gli amministratori di database che non vogliono utilizzare e spendere denaro per Oracle MySQL Enterprise Backup aziendale. Mentre MariaDB Backup è biforcato e derivato da Percona XtraBackup, hanno anche MariaDB Enterprise Backup.
Entrambi questi strumenti condividono gli stessi concetti durante l'esecuzione o l'esecuzione di un backup. È un backup binario che offre un backup online a caldo, PITR, backup incrementale e completo, backup parziale, utile anche per il ripristino dei dati poiché comprende il ripristino in modo tale da produrre file di registro e posizione binari, supporta GTID e molto altro. Sebbene MariaDB Backup e Percona XtraBackup siano due diversi tipi di software al giorno d'oggi, poiché sono progettati per supportare il database mirato a fornire un backup. MariaDB Backup è sicuramente applicabile se si intende utilizzare o eseguire backup da un'origine database MariaDB. Considerando che, Percona XtraBackup è applicabile su Oracle MySQL e anche su Percona Server o alcuni server MySQL derivati come Percona XtraDB Server o la versione Codership di Galera Cluster per MySQL.
Entrambi i backup sono molto utili per le migrazioni di database. L'esecuzione di un backup online a caldo è sempre più veloce e produce un backup che è possibile utilizzare direttamente per caricarlo nel database di destinazione. Più spesso, il backup in streaming è utile così come è possibile eseguire un backup online e trasmettere i dati binari al database di destinazione utilizzando socat o netcat. Ciò consente di ridurre il tempo di migrazione poiché lo spostamento dei dati nella destinazione di destinazione viene trasmesso direttamente.
L'approccio più comune alla migrazione dei dati durante l'utilizzo di questo strumento consiste nel copiare i dati dall'origine, quindi trasmettere i dati alla destinazione di destinazione. Una volta nella destinazione del database di destinazione, puoi semplicemente preparare il backup binario con l'opzione --prepare in cui applica i registri che sono stati registrati durante il momento della creazione del backup in modo che copierà i dati completi così come sono ed esattamente dal momento dove è stato eseguito il backup. Quindi imposta la destinazione del database di destinazione come replica in modo che funga da replica o slave del cluster di origine esistente e replichi tutte le modifiche e le transazioni che si sono verificate dal cluster principale.
Naturalmente c'è anche una limitazione nell'utilizzo di questo strumento, ma gli amministratori di database devono sapere come utilizzare questo strumento e anche come limitare e personalizzare l'utilizzo in base all'uso desiderato. Potresti non voler impantanare il tuo database di origine se la tua fonte sta assorbendo troppo traffico o un'elaborazione di grandi dimensioni da quel momento. La sua limitazione garantisce inoltre che sia una configurazione omogenea in cui l'origine di destinazione è di un sistema compatibile con Linux e non su un ambiente di tipo Windows poiché Percona XtraBackup e MariaDB Backup funzionano solo in ambiente Linux.
Strumenti di migrazione dello schema del database
La migrazione del database non parla da sola di uno strumento specifico e di un'attività specifica, quindi la migrazione può avvenire. Ci sono molte considerazioni e attività successive alla base che devono essere eseguite per eseguire una migrazione completa del database. Uno di questi è la migrazione dello schema o la migrazione del database. Uno schema in MySQL/MariaDB è una raccolta di dati costituita da un gruppo di tabelle con colonne e righe, eventi, trigger, stored procedure o routine e funzioni. Ci sono occasioni in cui potresti voler migrare solo uno schema o solo una tabella. Supponiamo che una tabella specifica su uno schema richieda una modifica nella sua struttura della tabella e ciò richieda un'istruzione DDL. Il problema è che, l'esecuzione di un'istruzione DDL diretta come ALTER TABLE ...ENGINE=InnoDB blocca qualsiasi transazione o connessione in entrata che farà riferimento o utilizzerà anche alla tabella di destinazione. Per alcune tabelle enormi che comprendono la definizione di dati lunghi e la struttura della tabella, aggiunge una sfida più reale e complica anche di più, soprattutto se la tabella è una tabella calda. Mentre in una migrazione del database, può essere difficile copiare la copia completa esatta dell'intera tabella senza tempi di inattività dall'origine. Vediamo quindi quali sono.
pt-online-cambio-schema
Fa parte del famoso Percona Toolkit che originariamente derivava da Maatkit e Aspersa. Questo strumento è molto utile quando si esegue una modifica della definizione di una tabella, in particolare per una tabella attiva costituita da un'enorme quantità di dati. Per un approccio comune ma ingenuo per eseguire una modifica della definizione di tabella, l'esecuzione di ALTER TABLE può fare il lavoro. Sebbene sia sufficiente, ALTER TABLE senza utilizzare ALGORITHM=INPLACE provoca una copia completa della tabella che acquisisce un blocco completo dei metadati e ciò significa che il database può accumularsi e bloccarsi per un lungo periodo di tempo, specialmente se la tabella è enorme. In tal caso, questo strumento è stato creato per risolvere il problema. Questo strumento è molto vantaggioso per la migrazione del database in modo tale che venga rilevata una copia incoerente di una tabella calda con dati molto grandi dalla destinazione del database di destinazione già impostata. Invece di eseguire un backup utilizzando una copia logica o binaria/fisica, è possibile utilizzare pt-online-schema-change che copia le righe dalla tabella di origine alla relativa tabella di destinazione pezzo per pezzo. Puoi persino personalizzare il comando con chiamate appropriate ai suoi parametri a seconda delle tue esigenze.
Oltre all'utilizzo, pt-online-schema-change utilizza anche i trigger. Utilizzando i trigger, qualsiasi traffico successivo o in corso che tenti di applicare modifiche a quella tabella di riferimento deve essere copiato anche nel database di destinazione che funge da replica del cluster di database di origine corrente. Questo copia tutti i dati esattamente quali dati ha il database di origine fino al database di destinazione che si trova su una piattaforma diversa, ad esempio. L'uso dei trigger è applicabile per MySQL e MariaDB purché il suo motore sia InnoDB e abbia una presenza di chiave primaria su quella tabella, che è un requisito. Potresti sapere che InnoDB utilizza un meccanismo di blocco delle righe che consente che, per un certo numero di blocchi (un gruppo di record selezionati), pt-online-schema-change proverà a copiarlo e quindi applicherà l'istruzione INSERT alla tabella di destinazione . La tabella di destinazione è una tabella fittizia che funge da copia di destinazione della prossima sostituzione della tabella di origine esistente. pt-online-schema-change consente tuttavia all'utente di rimuovere la tabella fittizia o semplicemente di lasciare la tabella fittizia sul posto fino a quando l'amministratore non è pronto a rimuovere quella tabella. Tieni presente che l'eliminazione o la rimozione di una tabella acquisisce un meta-datalock. Poiché acquisisce trigger, eventuali modifiche successive devono essere copiate esattamente nella tabella di destinazione senza lasciare discrepanze sulla tabella di destinazione o fittizia.
gh-ost
Condivide lo stesso concetto di pt-online-schema-change. Questo strumento si avvicina in modo diverso rispetto a pt-online-schema-change. Devo dire che questa migrazione dello strumento dello schema si avvicina a quegli impedimenti basati sulla produzione che possono causare il rallentamento del database e il possibile blocco del cluster di database in modalità di manutenzione o inattivo per un periodo di tempo sconosciuto, fino a quando il problema non viene risolto risolto. Questo problema è causato di solito con i trigger. Se si dispone di una tabella occupata o attiva che sta subendo una modifica dello schema o una modifica della definizione della tabella, i trigger possono causare l'accumulo del database a causa di conflitti di blocco. I trigger MySQL/MariaDB consentono al database di definire i trigger per INSERT, UPDATE e DELETE. Se la tabella di destinazione si trova in un hotspot, può finire male. Il tuo database inizia a rallentare finché non si blocca a meno che tu non sia in grado di eliminare le query in arrivo o di rimuovere i trigger, ma non è questo l'approccio ideale.
A causa di questi problemi, gh-ost risolve il problema. Si comporta come se fosse presente un server di registro binario in cui gli eventi o le transazioni in entrata vengono registrati in un formato di registro binario, in particolare utilizzando RBR (Row Based Replication). In effetti, è molto sicuro e meno preoccupante in termini di impatto che devi affrontare. In effetti, hai anche la possibilità di eseguire un test o un test (come con pt-online-schema-change) ma testarlo direttamente nella replica o in un nodo slave. Questo è perfetto se vuoi giocare e controllare la copia esatta nel database di destinazione durante la migrazione.
Questo strumento è molto flessibile in base alle tue esigenze e implica la garanzia che il tuo cluster non si bloccherà o probabilmente finirà per eseguire un failover o un ripristino dei dati se peggiora. Per ulteriori informazioni e per conoscere questo strumento, suggerisco di leggere questo post di Github di Shlomi Noach.
Altri strumenti OSC
Posso dire che questi due strumenti sono più un approccio raccomandabile, ma puoi provare anche altre alternative. Per lo più, questi strumenti applicano trigger MySQL/MariaDB in modo che in qualche modo condividano lo stesso concetto di pt-online-schema-change. Ecco il seguente elenco:
- LHM - Le migrazioni di database in stile Rails sono un modo utile per far evolvere lo schema dei dati in modo agile. La maggior parte dei progetti Rails inizia in questo modo e all'inizio apportare modifiche è facile e veloce.
- OnlineSchemaChange - Creato e avviato da Facebook. Questo strumento viene utilizzato per apportare modifiche allo schema per le tabelle MySQL in modo non bloccante
- TableMigrator - Avviato da Serious Business ed ex dipendenti di Twitter. Questo strumento condivide lo stesso principio con migrazioni senza tempi di inattività di tabelle di grandi dimensioni in MySQL. È implementato utilizzando Rails, quindi può essere utile se hai un ambiente applicativo Ruby-on-Rails.
- oak-online-alter-table - questo è un vecchio strumento creato da Shlomi Noach anche se in qualche modo si avvicina allo stesso approccio di pt-online-schema-change ed esegue un'operazione ALTER TABLE non bloccante
Strumenti della procedura guidata di migrazione del database
Ci sono pochi strumenti di migrazione che offrono un utilizzo gratuito che è molto vantaggioso in una certa misura. La cosa più vantaggiosa dell'utilizzo degli strumenti della procedura guidata di migrazione è che dispongono di una GUI per la quale puoi avere la comodità di vedere la struttura corrente o semplicemente seguire i passaggi forniti dall'interfaccia utente durante la migrazione. Possono esserci numerosi servizi o strumenti di procedura guidata, ma non è open source e non è disponibile gratuitamente. Naturalmente, la migrazione di un database è un processo molto complesso ma sistematico, ma in alcuni casi richiede grandi sforzi e lavoro. Diamo un'occhiata a questi strumenti gratuiti.
Workbench MySQL
Come suggerisce il nome, è per MySQL e database derivati come Percona Server, ad esempio, può essere utile quando si tratta di migrazione di database. Dal momento che MariaDB è completamente passata a un percorso diverso, specialmente dalla versione 10.2, ci sono alcuni problemi di incompatibilità che potresti incontrare se tenti di usarlo da un'origine o una destinazione MariaDB. Workbench può essere utilizzato per tipi eterogenei di database come quelli provenienti da database di origine diversi e desidera eseguire il dump dei dati su MySQL.
MySQL Workbench è composto da versioni community e enterprise. Tuttavia, la versione community è disponibile gratuitamente come GPL che puoi trovare qui https://github.com/mysql/mysql-workbench. Come afferma la documentazione, MySQL Workbench consente di migrare da Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL e altre tabelle, oggetti e dati RDBMS a MySQL. La migrazione supporta anche la migrazione dalle versioni precedenti di MySQL alle versioni più recenti.
phpMyAdmin
Per coloro che lavorano come sviluppatori web utilizzando lo stack LAMP, questo strumento non sorprende che sia uno dei loro coltellini svizzeri quando si occupano di attività di database. phpMyAdmin è uno strumento software gratuito scritto in PHP, destinato a gestire l'amministrazione di MySQL sul Web. phpMyAdmin supporta un'ampia gamma di operazioni su MySQL e MariaDB. Le operazioni utilizzate di frequente (gestione di database, tabelle, colonne, relazioni, indici, utenti, autorizzazioni, ecc.) possono essere eseguite tramite l'interfaccia utente, mentre hai ancora la possibilità di eseguire direttamente qualsiasi istruzione SQL.
Sebbene sia abbastanza semplice quando si tratta di importare ed esportare, l'importante è che faccia il lavoro. Sebbene per una migrazione più ampia e complessa, ciò potrebbe non essere sufficiente per gestire le esigenze desiderate.
HeidiSQL
HeidiSQL è un software gratuito e ha l'obiettivo di essere facile da imparare. "Heidi" consente di visualizzare e modificare dati e strutture da computer che eseguono uno dei sistemi di database MariaDB, MySQL, Microsoft SQL, PostgreSQL e SQLite. Inventato nel 2002 da Ansgar, HeidiSQL è uno degli strumenti più popolari per MariaDB e MySQL in tutto il mondo.
A scopo di migrazione, consente di esportare da un server/database direttamente a un altro server/database. Ha anche funzionalità di importazione per consentire campi di testo come CSV e anche esportare righe di tabella anche in un'ampia gamma di tipi di file supportati come CSV, HTML, XML, SQL, LaTeX, Wiki Markup e PHP Array. Sebbene sia stato creato per gestire i database per scopi di amministrazione del server db, puoi utilizzarlo per semplici operazioni di migrazione.
Percona Toolkit come coltellino svizzero
Percona Toolkit è un software notevole distribuito come software open-source sotto la garanzia di GPL. Percona Toolkit è una raccolta di strumenti avanzati da riga di comando comunemente utilizzati internamente da Percona, ma è anche applicabile a qualsiasi lavoro relativo ai database, in particolare per i server MySQL/MariaDB.
Allora, come e perché è utile anche per la migrazione dei dati, specialmente nelle migrazioni MySQL/MariaDB? Hanno una serie di strumenti qui che è utile utilizzare durante la migrazione e dopo la migrazione.
Come accennato in precedenza, un approccio comune alla migrazione dei dati consiste nell'avere il server di destinazione di destinazione come una replica del cluster di database di origine principale ma in una configurazione omogenea. Ciò significa che, se la situazione si sta spostando da locale a un provider di cloud pubblico, puoi configurare un nodo scelto da quella piattaforma e questo nodo replicherà tutte le transazioni dal cluster principale. Utilizzando gli strumenti di backup, potresti essere in grado di ottenere questo tipo di configurazione della migrazione. Ma non finisce qui. Percona Toolkit dispone di strumenti pt-table-checksum/pt-table-sync, ad esempio, per aiutarti a identificare le incongruenze dei dati tra il server del database di destinazione locale e quello di destinazione. Con pt-table-checksum, puoi eseguire calcoli di checksum basati su una serie di blocchi per tutti i database o semplicemente checksum selettivamente su database particolari, tabelle particolari o anche un intervallo di record della tabella. pt-table-sync verrà utilizzato per eseguire la sincronizzazione dei dati in modo che i database di destinazione vengano nuovamente aggiornati con una nuova copia dei dati esatti dal cluster di origine principale.
D'altra parte, pt-upgrade è molto utile dopo aver eseguito la migrazione dagli strumenti di backup. Con pt-upgrade, puoi utilizzare questo strumento per eseguire analisi eseguendo una serie di query, ad esempio da un file di registro di query lento. Questi risultati possono essere utilizzati per confrontare dal database di origine e con il server del database di destinazione.
Riepilogo
La migrazione del database, specialmente da una configurazione eterogenea, può essere molto complicata. Eppure su una configurazione omogenea può essere abbastanza semplice; indipendentemente dal fatto che i dati siano grandi o piccoli, purché si disponga degli strumenti adeguati e, naturalmente, dell'approccio sistematico corretto per determinare che la migrazione sia completa e che i dati siano coerenti. Ci possono essere momenti in cui una migrazione richiede la consultazione con gli esperti, ma è sempre un ottimo inizio per provare con questi strumenti open source per ottenere l'attività di migrazione del database desiderata.
