Store organisationer, der bruger MySQL- eller MariaDB-databaseplatforme, står ofte over for et behov for at udføre en databasemigrering fra et sted til et andet. Uanset platformen, typen af databasesoftware (såsom fra RDBMS til NoSQL eller NoSQL, der går tilbage til RDBMS), eller hvis det blot er en datamigrering, er det en enorm mængde arbejde og omkostninger at udføre en migrering.
En databasemigrering vil altid involvere processen med at migrere data fra en eller flere kildedatabaser til en eller flere måldatabaser. Dette kan involvere en databasemigreringstjeneste eller et mashup-sæt af værktøjer, som ingeniørerne har bygget til at skabe en service og skræddersy til denne type problemer.
Det forventes, at en databasemigrering ikke betyder, at kildedatabaseplatformen ender med, at dens målplatform bliver nøjagtig som oprindelseskilden. Når en migrering er afsluttet, kan datasættet fra måldatabaserne muligvis ende med at blive omstruktureret. Det, der betyder mest, når migreringen er fuldført, er, at de klienter, der får adgang til databasen, skal omdirigeres til de nye kildedatabaser. Den nye kildedatabase skal levere den nøjagtige kopi af data fra kilden, og uden indvirkning på ydeevnen, der kan påvirke den overordnede brugeroplevelse.
At flytte dine data fra én platform til destinationsplatformen er en stor opgave at udføre. Dette er hvad en databasemigrering dækker over, når en organisation eller virksomhed beslutter sig for at slukke lyset til den nuværende platform af flere årsager. De almindelige årsager til at migrere data er på grund af omkostningseffektivitet til måldestinationsplatformen eller dens fleksibilitet ved implementering og skalerbarhed. Mens den nuværende platform, der hoster de nuværende produktionsdata, forårsager flere omkostninger til dens opgraderinger og skalerbarhed, er den bare byrdefuld, når du implementerer små ændringer, som faktisk kan implementeres i en mikroserviceplatform.
I denne blog vil vi sætte fokus på de bedste open source-værktøjer, du kan bruge til MySQL- og MariaDB-migrering på en mere homogen databasemigrering.
Sikkerhedskopieringsværktøjer til datamigrering
Den nemmeste vej at bruge, når du udfører migrering, er at bruge værktøjer til databasesikkerhedskopiering. Vi vil se på, hvad disse værktøjer er, og hvordan du kan bruge dem under migreringen.
mysqldump/mysqlpump
Dette værktøj er et af de mest berømte værktøjer til MySQL eller MariaDB, som en databaseadministrator eller systemadministrator vil tilslutte dette værktøj til at migrere enten en hel database eller en delvis kopi af databasen. For databaseadministratorer, der ikke er fortrolige med MySQL/MariaDB, vil dette værktøj give dig mulighed for at oprette en kopi af backup, som vil generere en logisk kopi af data, som du kan dumpe på måldatabasen.
En almindelig opsætning ved brug af dette værktøj er, at når en måldatabase er placeret et andet sted og hostes på en anden platform end kilden, fungerer målet som en slave eller replika. Brug af mysqldump, der almindeligvis påberåbes med --single-transaction på et travlt system, og med --master-data vil give dig koordinaterne til at opsætte en slave på måldatabasen, som vil blive brugt som vært til datamigrering. Et alternativ til mysqldump er også mysqlpump, men med en mindre funktion kan den dog udføre parallel behandling af databaser og objekter i databaser for at fremskynde dumpprocessen. Ulempen er, at der med mysqlpump ikke er nogen mulighed, du kan bruge, såsom --master-data, hvilket er meget nyttigt, hvis du vil oprette en replika, der vil blive brugt som måldestination for databasemigrering.
mysqlpump er fordelagtig, hvis dine data er mere inaktive eller sættes i vedligeholdelsestilstand, således at ingen behandlede skrivninger eller ændringer igangværende til kildedatabasen. Det er hurtigere og hurtigere sammenlignet med mysqldump.
mydumper/myloader
mydumper/myloader er et meget smart og effektivt værktøj, som du kan bruge til logisk backup, især til import af bulkdata med hurtigere behandlingshastighed, da det tilbyder parallelitet, mulighed for at sende data i stykker, understøtter tærskelværdi og kontrol bedømme antallet af tråde, rækker, udsagnsstørrelse, og komprimere resultatet. Det genererer eller inkluderer binære logfiler og logpositioner, hvilket er meget nyttigt, hvis du opsætter måldestinationsplatformen til at fungere som en replika af det aktuelle kilde- og produktionsmiljø.
Dybest set er mydumper den binære og den kommando, du skal påkalde via kommandolinjen for at oprette den logiske sikkerhedskopi. Hvorimod myloader er den binære og den kommando, du skal bruge, når du indlæser data til den ønskede destination. Dens fleksibilitet giver dig mulighed for at styre din ønskede hastighed, når du behandler handlingerne, uanset om det opretter en sikkerhedskopi eller indlæser dataene. Ved at bruge mydumper kan du også oprette en fuld sikkerhedskopi eller blot en delvis sikkerhedskopi af din kildedatabase. Dette er meget nyttigt, hvis du har brug for et stort data eller et skema, som du ønsker at flytte væk fra den aktuelle databasevært, og lidt flytte det til en anden måldestination, mens du begynder at opsætte en ny databaseskår. Dette kan også være en måde at migrere store data på ved at trække et stort segment af datasættet og derefter flytte det, men som en ny shard node.
mydumper/myloader har også sine begrænsninger. Det er blevet stoppet fra opdateringer fra de originale forfattere, men gemt af Max Bube, men værktøjet bliver stadig meget brugt, selv til produktionsmiljøer.
Percona XtraBackup/MariaDB Backup
Perconas XtraBackup er en gave til databaseadministratorer, der ikke ønsker at bruge og bruge penge til virksomhedens Oracle MySQL Enterprise Backup. Mens MariaDB Backup er splittet og afledt af Percona XtraBackup, har de også MariaDB Enterprise Backup.
Begge disse værktøjer deler de samme koncepter, når de udfører eller tager en sikkerhedskopi. Det er en binær backup, som tilbyder en varm online backup, PITR, inkrementel og fuld backup, delvis backup, også nyttig til datagendannelse, da den forstår gendannelse, som producerer binær logfil og position, understøtter GTID'er og meget mere. Selvom MariaDB Backup og Percona XtraBackup er to forskellige typer software i dag, da de er udviklet til at understøtte databasen fokuseret på at give en backup. MariaDB Backup er bestemt anvendelig, hvis du har til hensigt at bruge eller tage sikkerhedskopier fra en MariaDB-databasekilde. Hvorimod Percona XtraBackup er anvendelig på Oracle MySQL og også på Percona Server eller nogle afledte MySQL-servere såsom Percona XtraDB Server eller Coderships version af Galera Cluster til MySQL.
Begge sikkerhedskopier er meget gavnlige til databasemigreringer. At udføre en hot online backup er hurtigere og hurtigere og producerer en backup, som du direkte kan bruge til at indlæse den til din måldatabase. Oftere er streaming backup praktisk, ligesom du kan udføre en online backup og streame de binære data til måldatabasen ved hjælp af socat eller netcat. Dette giver dig mulighed for at forkorte migreringstiden, da flytning af data til måldestinationen bliver streamet direkte.
Den mest almindelige tilgang til datamigrering, mens du bruger dette værktøj, er at kopiere dataene fra kilden og derefter streame dataene til måldestinationen. Når du først er i måldatabasedestinationen, kan du bare forberede den binære sikkerhedskopi med --prepare-indstillingen, hvor den anvender de logfiler, der blev registreret under oprettelsen af sikkerhedskopien, så den kopierer de fulde data, som de er og nøjagtigt fra tidspunktet hvor sikkerhedskopien er taget. Indstil derefter måldatabasedestinationen som en replika til at fungere som en replika eller slave af den eksisterende kildeklynge og replikere alle de ændringer og transaktioner, der er sket fra hovedklyngen.
Selvfølgelig er der også en begrænsning ved at bruge dette værktøj, men databaseadministratorer skal vide, hvordan man bruger dette værktøj, og også hvordan man begrænser og tilpasser brugen i overensstemmelse med dets ønskede brug. Du ønsker måske ikke at lægge din kildedatabase ned, hvis din kilde tager for meget trafik eller stor behandling fra det tidspunkt. Dens begrænsning sikrer også, at det er en homogen opsætning, hvor målkilden er et Linux-kompatibelt system og ikke på et Windows-miljø, da Percona XtraBackup og MariaDB Backup kun fungerer i Linux-miljøet.
Databaseskemamigreringsværktøjer
Databasemigrering taler ikke kun sig selv om et bestemt værktøj og en specifik opgave, så kan migrering ske. Der er en masse overvejelser og bagvedliggende efterfølgende opgaver, der skal udføres for at opfylde en komplet databasemigrering. En af disse er skemamigreringen eller databasemigreringen. Et skema i MySQL/MariaDB er en samling af data, som består af en gruppe tabeller med dens kolonner og rækker, hændelser, triggere, lagrede procedurer eller rutiner og funktioner. Der er lejligheder, hvor du måske kun ønsker at migrere et skema eller kun en tabel. Lad os sige, at en specifik tabel på et skema kræver en ændring i dens tabelstruktur, og det kræver en DDL-sætning. Problemet er, at kørsel af en direkte DDL-sætning såsom ALTER TABLE ...ENGINE=InnoDB blokerer alle indgående transaktioner eller forbindelser, som også vil referere eller bruge til måltabellen. For nogle enorme tabeller, der omfatter lange datadefinitioner og tabellens struktur, tilføjer det mere reel udfordring og komplicerer også mere, især hvis tabellen er et varmt bord. Mens det i en databasemigrering kan være svært at kopiere den nøjagtige fulde kopi af den fulde tabel uden nedetid fra kilden. Så lad os se, hvad disse er.
pt-online-schema-change
Det er en del af det berømte Percona Toolkit, som oprindeligt stammer fra Maatkit og Aspersa. Dette værktøj er meget nyttigt, når du udfører en tabeldefinitionsændring, især for et varmt bord, der består af en enorm mængde data. For en almindelig, men naiv tilgang til at udføre en tabeldefinitionsændring, kan kørsel af ALTER TABLE gøre jobbet. Selvom det er tilstrækkeligt tilfældet, forårsager ALTER TABLE uden brug af ALGORITHM=INPLACE en fuld tabelkopi, som får en fuld metadatalås, og det betyder, at din database muligvis kan stables op og låse op i lang tid, især hvis tabellen er kæmpe stor. I så fald er dette værktøj bygget til at løse det problem. Dette værktøj er meget fordelagtigt til databasemigrering på en sådan måde, at en detekteret inkonsekvent kopi af en hot table med meget store data fra din allerede opsatte måldatabasedestination. I stedet for at udføre en backup enten ved at bruge en logisk eller binær/fysisk kopi, kan pt-online-schema-change bruges, som kopierer rækkerne fra kildetabel til dens måltabel stykke-for-chunk. Du kan endda tilpasse kommandoen med korrekte opkald til dens parametre afhængigt af dine krav.
Udover at bruge bruger pt-online-schema-change også triggere. Ved at bruge triggere skal enhver efterfølgende eller igangværende trafik, der forsøger at anvende ændringer i denne referencetabel, også kopieres til måldatabasen, der fungerer som en replika af den aktuelle kildedatabaseklynge. Dette kopierer alle data præcis, hvilke data kildedatabasen har ned til din måldatabase, som f.eks. ligger på en anden platform. Brug af triggere kan bruges til MySQL og MariaDB, så længe dens motor er InnoDB og har en primær nøgle tilstedeværelse på bordet, hvilket er et krav. Du ved måske, at InnoDB bruger en rækkelåsemekanisme, der tillader, at pt-online-schema-change for et vist antal bidder (en gruppe udvalgte poster) forsøger at kopiere det og derefter anvender INSERT-sætningen på måltabellen . Måltabellen er en dummy-tabel, der fungerer som en målkopi af den snart udskiftning af den eksisterende kildetabel. pt-online-schema-change giver dog brugeren mulighed for enten at fjerne dummy-tabellen eller bare lade dummy-tabellen være på plads, indtil administratoren er klar til at fjerne denne tabel. Bemærk, at slip eller fjernelse af en tabel erhverver en meta-datalås. Da den får udløsere, skal alle efterfølgende ændringer kopieres nøjagtigt til måltabellen uden at efterlade nogen uoverensstemmelse på mål- eller dummytabellen.
gh-ost
Deler det samme koncept som pt-online-schema-change. Dette værktøj nærmer sig anderledes sammenlignet med pt-online-schema-change. Jeg vil sige, denne migrering af skemaværktøj nærmer sig de produktionsbaserede hindringer, der kan få din database til at sænke farten og muligvis hænge fast, hvilket får din databaseklynge til at falde ned under vedligeholdelsestilstand eller nede i en ukendt periode, indtil problemet er løst. Dette problem er normalt forårsaget af triggere. Hvis du har et travlt eller varmt bord, der gennemgår en skemaændring eller tabeldefinitionsændring, kan triggere få din database til at hobe sig op på grund af låsestrid. MySQL/MariaDB-triggere giver din database mulighed for at definere triggere for INSERT, UPDATE og DELETE. Hvis måltabellen er på et hotspot, kan det ende med at være grimt. Din database begynder at blive langsommere, indtil den sætter sig fast, medmindre du er i stand til at dræbe de indkommende forespørgsler eller bedst kan fjerne triggerne, men det er ikke det, den ideelle tilgang handler om.
På grund af disse problemer løser gh-ost dette problem. Det fungerer, som om der er en binær log-server, hvor de indgående hændelser eller transaktioner logges i et binært log-format, specifikt ved hjælp af RBR (Row Based Replication). Faktisk er det meget sikkert og mindre bekymringer med hensyn til påvirkning, du skal møde. Faktisk har du også mulighed for at lave en test eller dry-run (samme som med pt-online-schema-change), men teste det direkte ind i replikaen eller en slaveknude. Dette er perfekt, hvis du vil lege og tjekke den nøjagtige kopi til din måldatabase under migreringen.
Dette værktøj er meget fleksibelt i overensstemmelse med dine behov og indebærer sikkerhed for, at din klynge ikke hænger fast eller sandsynligvis vil ende med at udføre en failover eller datagendannelse, hvis det går værre. For mere information og ønsker at lære dette værktøj, foreslår jeg, at du læser dette indlæg fra Github af Shlomi Noach.
Andre OSC-værktøjer
Jeg kan sige, at disse to værktøjer er mere anbefalelsesværdige, men andre alternativer kan du også prøve. For det meste anvender disse værktøjer MySQL/MariaDB-udløsere, så det på en eller anden måde deler det samme koncept som pt-online-schema-change. Her er følgende liste:
- LHM - Rails-stil databasemigreringer er en nyttig måde at udvikle dit dataskema på en agil måde. De fleste Rails-projekter starter sådan, og i begyndelsen er det hurtigt og nemt at foretage ændringer.
- OnlineSchemaChange - Oprettet og initieret af Facebook. Dette værktøj bruges til at lave skemaændringer for MySQL-tabeller på en ikke-blokerende måde
- TableMigrator - initieret af Serious Business og tidligere ansatte på Twitter. Dette værktøj deler det samme princip med nul-nedetidsmigrering af store tabeller i MySQL. Det er implementeret ved hjælp af Rails, så det kan være nyttigt, hvis du har et Ruby-on-Rails-applikationsmiljø.
- oak-online-alter-table - dette er et gammelt værktøj skabt af Shlomi Noach, selvom det på en eller anden måde nærmer sig den samme tilgang, som pt-online-schema-change og udfører en ikke-blokerende ALTER TABLE-operation
Værktøjer til Database Migration Wizard
Der er få migreringsværktøjer, der tilbyder gratis brug, hvilket til en vis grad er meget fordelagtigt. Hvad der er mere fordelagtigt ved at bruge migreringsguideværktøjer er, at de har GUI, som du kan have bekvemmeligheden for at se den aktuelle struktur eller bare følge de trin, brugergrænsefladen giver under migreringen. Der kan være adskillige tjenester eller guideværktøjer, men det er ikke open source, og det er ikke tilgængeligt gratis. Selvfølgelig er en databasemigrering en meget kompleks, men alligevel en systematisk proces, men i nogle tilfælde kræver det stort arbejde og indsats. Lad os tage et kig på disse gratis værktøjer.
MySQL Workbench
Som navnet antyder, er det til MySQL, og afledte databaser som Percona Server kan f.eks. være nyttige, når det kommer til databasemigrering. Da MariaDB totalt er skiftet til en anden rute, især siden 10.2-versionen, er der nogle inkompatibilitetsproblemer, du kan støde på, hvis du forsøger at bruge dette fra en MariaDB-kilde eller et mål. Workbench kan bruges til heterogene typer databaser, såsom dem, der kommer fra forskellige kildedatabaser og ønsker at dumpe dataene til MySQL.
MySQL Workbench er sammensat af fællesskabs- og virksomhedsversioner. Alligevel er fællesskabsversionen frit tilgængelig som GPL, som du kan finde her https://github.com/mysql/mysql-workbench. Som det fremgår af dokumentationen, giver MySQL Workbench dig mulighed for at migrere fra Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL og andre RDBMS-tabeller, -objekter og -data til MySQL. Migrering understøtter også migrering fra tidligere versioner af MySQL til de seneste udgivelser.
phpMyAdmin
For dem, der arbejder som webudviklere, der bruger LAMP-stakken, kommer dette værktøj ikke til nogen overraskelse, fordi det er en af deres schweiziske hærknive, når de beskæftiger sig med databaseopgaver. phpMyAdmin er et gratis softwareværktøj skrevet i PHP, beregnet til at håndtere administrationen af MySQL over nettet. phpMyAdmin understøtter en bred vifte af operationer på MySQL og MariaDB. Hyppigt brugte operationer (håndtering af databaser, tabeller, kolonner, relationer, indekser, brugere, tilladelser osv.) kan udføres via brugergrænsefladen, mens du stadig har mulighed for direkte at udføre enhver SQL-sætning.
Selvom det er ret enkelt, når det kommer til import og eksport, er det vigtigt, at det gør arbejdet gjort. Selvom for større og mere kompleks migration, er dette muligvis ikke tilstrækkeligt til at håndtere dine ønskede behov.
HeidiSQL
HeidiSQL er gratis software og har til formål at være let at lære. "Heidi" lader dig se og redigere data og strukturer fra computere, der kører et af databasesystemerne MariaDB, MySQL, Microsoft SQL, PostgreSQL og SQLite. Opfundet i 2002 af Ansgar, HeidiSQL hører til de mest populære værktøjer til MariaDB og MySQL på verdensplan.
Til migreringsformål giver det dig mulighed for at eksportere fra én server/database direkte til en anden server/database. Det har også importfunktioner til at tillade tekstfelter såsom CSV, og også eksportere tabelrækker også til en bred vifte af understøttede filtyper såsom CSV, HTML, XML, SQL, LaTeX, Wiki Markup og PHP Array. Selvom det er bygget til at administrere databaser til administration af db-servere, kan du alligevel bruge det til simple migreringsting.
Percona Toolkit som din schweiziske hærkniv
Percona Toolkit er bemærkelsesværdig software, der distribueres som open source-software under GPL's garanti. Percona Toolkit er en samling af avancerede kommandolinjeværktøjer, der almindeligvis bruges internt af Percona, men det er også anvendeligt til ethvert databasearbejde, der er relateret specielt til MySQL/MariaDB-servere.
Så hvordan og hvorfor er det også nyttigt til datamigrering, især i MySQL/MariaDB-migreringer? De har en række værktøjer her, som er fordelagtige at bruge ved migrering og efter migrering.
Som tidligere nævnt er en almindelig tilgang til datamigrering at have måldestinationsserveren som en replika af hovedkildedatabaseklyngen, men i en homogen opsætning. Dette betyder, at hvis situationen bevæger sig fra on-prem til en offentlig cloud-udbyder, kan du konfigurere en valgt node fra den platform, og denne node vil replikere alle transaktioner fra hovedklyngen. Ved at bruge sikkerhedskopieringsværktøjer kan du muligvis opnå denne type migreringsopsætning. Men det slutter ikke der. Percona Toolkit har pt-table-checksum/pt-table-sync-værktøjer, for eksempel for at hjælpe dig med at identificere datainkonsistens mellem on-prem kontra måldestinationsdatabaseserveren. Med pt-table-checksum kan du udføre checksum-beregninger baseret på en række bidder for alle databaser eller blot selektivt checksum på bestemte databaser eller bestemte tabeller eller endda en række poster i tabellen. pt-table-sync vil blive brugt til at udføre datasynkronisering, så dine måldatabaser vil blive opdateret igen med en ny kopi af de nøjagtige data fra hovedkildeklyngen.
På den anden side er pt-upgrade meget nyttig, efter at migreringen fra sikkerhedskopieringsværktøjer er udført. Med pt-upgrade kan du bruge dette værktøj til at udføre analyse ved at køre et sæt forespørgsler, for eksempel fra en langsom forespørgselslogfil. Disse resultater kan bruges til at sammenligne fra kildedatabasen og med måldatabaseserveren.
Oversigt
Databasemigration, især fra en heterogen opsætning, kan være meget kompliceret. Men på en homogen opsætning kan det være ret ligetil; uanset om dataene er store eller små, så længe du er udstyret med de rigtige værktøjer og selvfølgelig den korrekte systematiske tilgang til at bestemme, at migreringen er komplet med konsistente data. Der kan være tidspunkter, hvor en migrering kræver konsultation med eksperterne, men det er altid en god start at komme op og prøve med disse open source-værktøjer for at opnå din ønskede databasemigreringsopgave.