sql >> Database >  >> RDS >> MariaDB

Top Open Source-tools voor MySQL- en MariaDB-migraties

Grote organisaties die MySQL- of MariaDB-databaseplatforms gebruiken, worden vaak geconfronteerd met de noodzaak om een ​​databasemigratie van de ene plaats naar de andere uit te voeren. Ongeacht het platform, het type databasesoftware (zoals van RDBMS naar NoSQL of NoSQL die teruggaat naar RDBMS), of als het slechts een datamigratie is, het uitvoeren van een migratie is een enorme hoeveelheid werk en kosten.

Een databasemigratie omvat altijd het proces van het migreren van gegevens van een of meer brondatabases naar een of meer doeldatabases. Dit kan een databasemigratieservice zijn of een mashup-set van tools die de technici hebben gebouwd om een ​​service te creëren en op maat te maken voor dit soort problemen.

Het is te verwachten dat een databasemigratie niet betekent dat het brondatabaseplatform uiteindelijk precies hetzelfde is als de oorspronkelijke bron. Zodra een migratie is voltooid, kan de dataset uit de doeldatabases mogelijk worden geherstructureerd. Het belangrijkste is dat zodra de migratie volledig is voltooid, de clients die toegang hebben tot de database, worden omgeleid naar de nieuwe brondatabases. De nieuwe brondatabase moet de exacte kopie van de gegevens van de bron leveren en mag geen invloed hebben op de prestaties die de algehele gebruikerservaring kunnen beïnvloeden.

Het verplaatsen van uw gegevens van het ene platform naar het doelplatform is een enorme taak. Dit is wat een databasemigratie dekt wanneer een organisatie of bedrijf om verschillende redenen besluit het licht naar het huidige platform uit te schakelen. De meest voorkomende redenen voor het migreren van gegevens zijn vanwege de kosteneffectiviteit naar het doelbestemmingsplatform of vanwege de flexibiliteit bij implementatie en schaalbaarheid. Hoewel het huidige platform dat de huidige productiegegevens host, meer kosten met zich meebrengt voor de upgrades en schaalbaarheid, is het alleen lastig bij het implementeren van kleine wijzigingen die daadwerkelijk kunnen worden geïmplementeerd in een microserviceplatform.

In deze blog gaan we ons concentreren op de beste open source-tools die u kunt gebruiken voor MySQL- en MariaDB-migraties voor een meer homogene databasemigratie.

Back-uptools voor gegevensmigratie

Het gemakkelijkste pad om te gebruiken bij het uitvoeren van migratie is het gebruik van databaseback-uptools. We bekijken wat deze tools zijn en hoe u ze kunt gebruiken tijdens de migratie.

mysqldump/mysqlpump

Deze tool is een van de meest bekende hulpprogramma's voor MySQL of MariaDB die een databasebeheerder of systeembeheerder deze tool zal gebruiken om ofwel een volledige database of een gedeeltelijke kopie van de database te migreren. Voor databasebeheerders die niet bekend zijn met MySQL/MariaDB, kunt u met deze tool een back-upkopie maken die een logische kopie van gegevens genereert die u op de doeldatabase kunt dumpen.

Een gebruikelijke opzet bij het gebruik van deze tool is dat wanneer een doeldatabase zich ergens anders bevindt en op een ander platform dan de bron wordt gehost, het doel fungeert als een slaaf of replica. Door mysqldump te gebruiken, dat gewoonlijk wordt aangeroepen met --single-transaction op een druk systeem, en met --master-data, krijgt u de coördinaten om een ​​slaaf op de doeldatabase in te stellen die als host voor gegevensmigratie zal worden gebruikt. Een alternatief voor mysqldump is ook mysqlpump, maar met een mindere functie die toch parallelle verwerking van databases en objecten in databases kan doen om het dumpproces te versnellen. Het nadeel is dat er met mysqlpump geen optie is die u kunt gebruiken, zoals --master-data, wat erg handig is als u een replica wilt maken die zal worden gebruikt als doelbestemming voor databasemigratie.

mysqlpump is voordelig als uw gegevens meer inactief zijn of in de onderhoudsmodus worden gezet, zodat er geen bewerkingen of wijzigingen in de brondatabase plaatsvinden. Het is sneller en sneller in vergelijking met mysqldump.

mijndumper/mijnloader 

mydumper/myloader is een zeer handige en efficiënte tool die u kunt gebruiken voor logische back-up, vooral voor het importeren van bulkgegevens met een hogere verwerkingssnelheid, omdat het parallellisme biedt, de mogelijkheid om gegevens in stukjes te verzenden, drempelwaarde en controle ondersteunt beoordeel het aantal threads, rijen, instructiegrootte en comprimeer het resultaat. Het genereert of bevat binaire logbestanden en logposities, wat erg handig is als u het doelbestemmingsplatform instelt om te fungeren als een replica van de huidige bron- en productieomgeving.

In principe is mydumper het binaire en het commando dat je via de commandoregel moet aanroepen om de logische back-up te maken. Terwijl myloader het binaire bestand en de opdracht is die u moet gebruiken bij het laden van gegevens naar de gewenste doelbestemming. Dankzij de flexibiliteit kunt u uw gewenste snelheid beheren bij het verwerken van de acties, of het nu gaat om het maken van een back-up of het laden van de gegevens. Met mydumper kunt u ook een volledige back-up of slechts een gedeeltelijke back-up van uw brondatabase maken. Dit is erg handig als u grote gegevens of schema's nodig hebt die u van de huidige databasehost wilt verwijderen en deze iets naar een andere doelbestemming wilt verplaatsen terwijl u begint met het instellen van nieuwe databaseshards. Dit kan ook een manier zijn om grote gegevens te migreren door een enorm segment van de gegevensset op te halen en deze vervolgens te verplaatsen, maar dan als een nieuw shardknooppunt.

mydumper/myloader heeft ook zijn beperkingen. Het is gestopt met updates van de oorspronkelijke auteurs, maar is opgeslagen door Max Bube, maar de tool wordt nog steeds veel gebruikt, zelfs voor productieomgevingen.

Percona XtraBackup/MariaDB-back-up

Percona's XtraBackup is een geschenk voor databasebeheerders die geen geld willen uitgeven aan Oracle MySQL Enterprise Backup voor ondernemingen. Terwijl MariaDB Backup is gevorkt en afgeleid van Percona XtraBackup, hebben ze ook MariaDB Enterprise Backup.

Beide tools delen dezelfde concepten bij het uitvoeren of maken van een back-up. Het is een binaire back-up die een hot online back-up biedt, PITR, incrementele en volledige back-up, gedeeltelijke back-up, ook handig voor gegevensherstel, omdat het herstel begrijpt, zodat een binair logbestand en positie wordt geproduceerd, GTID's worden ondersteund en nog veel meer. Hoewel MariaDB Backup en Percona XtraBackup tegenwoordig twee verschillende soorten software zijn, omdat ze verder zijn ontworpen om de database te ondersteunen die is gericht op het bieden van een back-up. MariaDB Backup is zeker van toepassing als u van plan bent om back-ups te gebruiken of te maken van een MariaDB-databasebron. Terwijl Percona XtraBackup toepasbaar is op Oracle MySQL en ook op Percona Server of sommige afgeleide MySQL-servers zoals Percona XtraDB Server of Codership's versie van Galera Cluster voor MySQL.

Beide back-ups zijn zeer nuttig voor databasemigraties. Het uitvoeren van een hot online back-up gaat steeds sneller en levert een back-up op die u direct kunt gebruiken om deze in uw doeldatabase te laden. Vaker is streaming back-up ook handig, zoals u een online back-up kunt maken en de binaire gegevens naar de doeldatabase kunt streamen met behulp van socat of netcat. Hierdoor kunt u de migratietijd verkorten, aangezien het verplaatsen van gegevens naar de doelbestemming direct wordt gestreamd.

De meest gebruikelijke benadering van gegevensmigratie bij het gebruik van deze tool is om de gegevens van de bron te kopiëren en de gegevens vervolgens naar de doelbestemming te streamen. Eenmaal in de doeldatabasebestemming, kunt u gewoon de binaire back-up voorbereiden met --prepare optie waar het de logs toepast die zijn vastgelegd tijdens het maken van de back-up, zodat het de volledige gegevens kopieert zoals het is en precies vanaf het tijdstip waar de back-up is gemaakt. Stel vervolgens de doeldatabasebestemming in als een replica om als replica of slaaf van het bestaande broncluster te fungeren en alle wijzigingen en transacties te repliceren die vanuit het hoofdcluster hebben plaatsgevonden.

Natuurlijk zijn er ook beperkingen aan het gebruik van deze tool, maar databasebeheerders moeten weten hoe ze deze tool moeten gebruiken en ook hoe ze het gebruik kunnen vertragen en aanpassen in overeenstemming met het gewenste gebruik. Misschien wilt u uw brondatabase niet vastlopen als uw bron vanaf dat moment te veel verkeer of veel verwerking in beslag neemt. De beperking zorgt er ook voor dat het een homogene setup is waarbij de doelbron een Linux-compatibel systeem is en niet in een Windows-omgeving, aangezien Percona XtraBackup en MariaDB Backup alleen in de Linux-omgeving werken.

Hulpprogramma's voor migratie van databaseschema's

Databasemigratie spreekt niet alleen over een specifieke tool en een specifieke taak, dan kan migratie plaatsvinden. Er zijn veel overwegingen en onderliggende taken die moeten worden uitgevoerd om een ​​volledige databasemigratie te voltooien. Een daarvan is de schemamigratie of databasemigratie. Een schema in MySQL/MariaDB is een verzameling gegevens die bestaat uit een groep tabellen met kolommen en rijen, gebeurtenissen, triggers, opgeslagen procedures of routines en functies. Het kan voorkomen dat u alleen een schema of alleen een tabel wilt migreren. Stel dat een specifieke tabel in een schema een wijziging in de tabelstructuur vereist en daarvoor een DDL-instructie vereist. Het probleem is dat het uitvoeren van een directe DDL-instructie zoals ALTER TABLE ...ENGINE=InnoDB alle inkomende transacties of verbindingen blokkeert die ook naar de doeltabel verwijzen of gebruiken. Voor sommige enorme tabellen die een lange gegevensdefinitie en structuur van de tabel bevatten, voegt het een grotere uitdaging toe en wordt het ook ingewikkelder, vooral als de tabel een hot table is. Terwijl het bij een databasemigratie moeilijk kan zijn om de exacte volledige kopie van de volledige tabel te kopiëren zonder downtime van de bron. Dus laten we eens kijken wat dit zijn.

pt-online-schema-change

Het maakt deel uit van de beroemde Percona Toolkit die oorspronkelijk is afgeleid van Maatkit en Aspersa. Deze tool is erg handig bij het uitvoeren van een wijziging van de tabeldefinitie, vooral voor een hot table die uit een enorme hoeveelheid gegevens bestaat. Voor een algemene maar naïeve benadering voor het uitvoeren van een wijziging van de tabeldefinitie, kan het uitvoeren van ALTER TABLE het werk doen. Hoewel het voldoende is, veroorzaakt ALTER TABLE zonder gebruik van ALGORITHM=INPLACE een volledige tabelkopie die een volledige metadatavergrendeling verkrijgt en dat betekent dat uw database zich mogelijk kan opstapelen en voor een lange periode kan vastlopen, vooral als de tabel is reusachtig. In dat geval is deze tool gebouwd om dat probleem op te lossen. Deze tool is zeer nuttig voor databasemigratie op een zodanige manier dat een inconsistente kopie van een hot table met zeer grote gegevens van uw reeds ingestelde doeldatabasebestemming wordt gedetecteerd. In plaats van een back-up uit te voeren met behulp van een logische of binaire/fysieke kopie, kan pt-online-schema-change worden gebruikt die de rijen van de brontabel naar de doeltabel stuk voor stuk kopieert. U kunt de opdracht zelfs aanpassen met de juiste aanroepen van de parameters, afhankelijk van uw vereisten.

Naast het gebruik, gebruikt pt-online-schema-change ook triggers. Door triggers te gebruiken, wordt elk volgend of doorgaand verkeer dat wijzigingen in die referentietabel probeert toe te passen, ook gekopieerd naar de doeldatabase die fungeert als een replica van het huidige brondatabasecluster. Hiermee kopieert u alle gegevens precies welke gegevens de brondatabase heeft naar uw doeldatabase die bijvoorbeeld op een ander platform staat. Het gebruik van triggers is van toepassing op MySQL en MariaDB zolang de engine InnoDB is en een primaire sleutel aanwezig is op die tabel, wat een vereiste is. U weet misschien dat InnoDB een rij-vergrendelingsmechanisme gebruikt waarmee pt-online-schema-change voor een bepaald aantal chunks (een groep geselecteerde records) dat zal proberen te kopiëren en vervolgens de INSERT-instructie op de doeltabel toepast. . De doeltabel is een dummytabel die fungeert als een doelkopie van de spoedige vervanging van de bestaande brontabel. pt-online-schema-change stelt de gebruiker echter in staat om ofwel de dummy-tabel te verwijderen of de dummy-tabel op zijn plaats te laten totdat de beheerder klaar is om die tabel te verwijderen. Houd er rekening mee dat het laten vallen of verwijderen van een tabel een meta-datalock verkrijgt. Omdat het triggers verwerft, worden alle volgende wijzigingen exact gekopieerd naar de doeltabel, zodat er geen discrepantie is in de doel- of dummytabel.

gh-ost

Deelt hetzelfde concept als pt-online-schema-change. Deze tool benadert anders dan pt-online-schema-change. Ik zal zeggen dat deze schematoolmigratie die op productie gebaseerde belemmeringen benadert die ervoor kunnen zorgen dat uw database langzamer gaat werken en mogelijk vastloopt, waardoor uw databasecluster onder onderhoudsmodus of voor een onbekende periode uitvalt, totdat het probleem is opgelost opgelost. Dit probleem wordt meestal veroorzaakt door triggers. Als u een drukke of actieve tabel hebt die een schemawijziging of wijziging van de tabeldefinitie ondergaat, kunnen triggers ervoor zorgen dat uw database zich opstapelt vanwege vergrendelingsconflicten. Met MySQL/MariaDB-triggers kan uw database triggers definiëren voor INSERT, UPDATE en DELETE. Als de doeltafel zich op een hotspot bevindt, kan het vervelend worden. Je database begint langzamer te worden totdat hij vastloopt, tenzij je in staat bent om die inkomende zoekopdrachten te stoppen of de triggers het beste kunt verwijderen, maar dat is niet waar het bij de ideale aanpak om draait.

Vanwege deze problemen lost gh-ost dat probleem op. Het werkt alsof er een binaire logserver is waar de inkomende gebeurtenissen of transacties worden vastgelegd in een binair logformaat, met name met behulp van RBR (Row Based Replication). In feite is het erg veilig en heeft u minder zorgen over de impact die u het hoofd moet bieden. In feite heb je ook de mogelijkheid om een ​​test te doen of een test uit te voeren (hetzelfde als bij pt-online-schema-change) maar deze rechtstreeks in de replica of een slave-node te testen. Dit is perfect als u tijdens de migratie wilt spelen en de exacte kopie naar uw doeldatabase wilt controleren.

Deze tool is zeer flexibel in overeenstemming met uw behoeften en impliceert de zekerheid dat uw cluster niet vastloopt of waarschijnlijk een failover of gegevensherstel uitvoert als het slechter gaat. Voor meer informatie en om deze tool te leren, raad ik aan dit bericht van Github door Shlomi Noach te lezen.

Andere OSC-tools

Ik kan zeggen dat deze twee tools een meer aan te bevelen benadering zijn, maar je kunt ook andere alternatieven proberen. Meestal passen deze tools MySQL/MariaDB-triggers toe, zodat het op de een of andere manier hetzelfde concept deelt als pt-online-schema-change. Hier is de volgende lijst:

  • LHM - Databasemigraties in Rails-stijl zijn een handige manier om uw gegevensschema op een flexibele manier te ontwikkelen. De meeste Rails-projecten beginnen zo, en in het begin is het aanbrengen van wijzigingen snel en gemakkelijk.
  • OnlineSchemaChange - Gemaakt en geïnitieerd door Facebook. Deze tool wordt gebruikt om schemawijzigingen voor MySQL-tabellen op een niet-blokkerende manier aan te brengen
  • TableMigrator - Geïnitieerd door Serious Business en ex-medewerkers van Twitter. Deze tool deelt hetzelfde principe met zero-downtime migraties van grote tabellen in MySQL. Het is geïmplementeerd met Rails, dus het kan handig zijn als je een Ruby-on-Rails-toepassingsomgeving hebt.
  • oak-online-alter-table - dit is een oude tool gemaakt door Shlomi Noach, hoewel het op de een of andere manier dezelfde benadering benadert als pt-online-schema-change en een niet-blokkerende ALTER TABLE-bewerking uitvoert

Wizardhulpprogramma's voor databasemigratie

Er zijn maar weinig migratietools die gratis gebruik bieden, wat tot op zekere hoogte erg voordelig is. Wat voordeliger is bij het gebruik van migratiewizard-tools, is dat ze een GUI hebben waarvoor u het gemak kunt hebben om de huidige structuur te zien of gewoon de stappen te volgen die de gebruikersinterface biedt tijdens de migratie. Er kunnen talloze services of wizardtools zijn, maar het is geen open source en het is niet gratis beschikbaar. Een databasemigratie is natuurlijk een zeer complex maar toch systematisch proces, maar in sommige gevallen vereist het veel werk en inspanningen. Laten we eens kijken naar deze gratis tools.

MySQL-werkbank

Zoals de naam al doet vermoeden, is het voor MySQL en afgeleide databases zoals Percona Server kunnen bijvoorbeeld handig zijn als het gaat om databasemigratie. Aangezien MariaDB volledig is overgestapt op een andere route, vooral sinds de 10.2-versie, zijn er enkele incompatibiliteitsproblemen die u kunt tegenkomen als u dit probeert te gebruiken vanuit een MariaDB-bron of -doel. Workbench kan worden gebruikt voor heterogene typen databases, zoals die afkomstig zijn uit verschillende brondatabases en wil de gegevens naar MySQL dumpen.

De MySQL Workbench bestaat uit community- en enterprise-versies. Toch is de communityversie vrij beschikbaar als GPL, die je hier kunt vinden https://github.com/mysql/mysql-workbench. Zoals in de documentatie staat, kunt u met MySQL Workbench migreren van Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL en andere RDBMS-tabellen, objecten en gegevens naar MySQL. Migratie ondersteunt ook het migreren van eerdere versies van MySQL naar de nieuwste releases.

phpMyAdmin

Voor degenen die werken als webontwikkelaars die de LAMP-stack gebruiken, is het geen verrassing dat deze tool een van hun Zwitserse zakmessen is bij het omgaan met databasetaken. phpMyAdmin is een gratis softwaretool geschreven in PHP, bedoeld om het beheer van MySQL via het web af te handelen. phpMyAdmin ondersteunt een breed scala aan bewerkingen op MySQL en MariaDB. Veelgebruikte bewerkingen (beheer van databases, tabellen, kolommen, relaties, indexen, gebruikers, machtigingen, enz.) kunnen worden uitgevoerd via de gebruikersinterface, terwijl u nog steeds de mogelijkheid heeft om elk SQL-statement direct uit te voeren.

Hoewel het vrij eenvoudig is als het gaat om importeren en exporteren, is het belangrijk dat het werk wordt gedaan. Hoewel dit voor grotere en complexere migraties misschien niet voldoende is om aan uw gewenste behoeften te voldoen.

HeidiSQL

HeidiSQL is gratis software en heeft als doel gemakkelijk te leren te zijn. Met "Heidi" kunt u gegevens en structuren bekijken en bewerken van computers met een van de databasesystemen MariaDB, MySQL, Microsoft SQL, PostgreSQL en SQLite. HeidiSQL, uitgevonden in 2002 door Ansgar, behoort tot de meest populaire tools voor MariaDB en MySQL wereldwijd.

Voor migratiedoeleinden kunt u rechtstreeks van de ene server/database naar een andere server/database exporteren. Het heeft ook importfuncties om tekstvelden zoals CSV toe te staan, en ook om tabelrijen te exporteren naar een breed scala aan ondersteunde bestandstypen zoals CSV, HTML, XML, SQL, LaTeX, Wiki Markup en PHP Array. Hoewel het is gebouwd om databases te beheren voor beheerders van db-servers, kunt u dit toch gebruiken voor eenvoudige migraties.

Percona Toolkit als uw Zwitsers zakmes

Percona Toolkit is opmerkelijke software die wordt gedistribueerd als open-sourcesoftware onder de garantie van GPL. Percona Toolkit is een verzameling geavanceerde opdrachtregelprogramma's die vaak intern door Percona worden gebruikt, maar is ook toepasbaar voor alle databasewerkzaamheden, met name voor MySQL/MariaDB-servers.

Dus hoe en waarom is het ook nuttig voor gegevensmigratie, vooral bij MySQL/MariaDB-migraties? Ze hebben hier een aantal tools die nuttig zijn om te gebruiken bij migratie en na migratie.

Zoals eerder vermeld, is een algemene benadering van gegevensmigratie om de doelbestemmingsserver te hebben als een replica van het hoofdbrondatabasecluster, maar in een homogene opstelling. Dit betekent dat, als de situatie verschuift van on-prem naar een openbare cloudprovider, u een gekozen knooppunt vanaf dat platform kunt instellen en dit knooppunt alle transacties van het hoofdcluster zal repliceren. Door back-uptools te gebruiken, kunt u dit type migratieconfiguratie mogelijk bereiken. Maar daar houdt het niet op. Percona Toolkit heeft bijvoorbeeld pt-table-checksum/pt-table-sync-tools om u te helpen bij het identificeren van inconsistenties in de gegevens tussen on-prem versus de doeldatabaseserver. Met pt-table-checksum kun je checksum-berekeningen uitvoeren op basis van een reeks chunks voor alle databases of gewoon selectief checksum voor bepaalde databases, of bepaalde tabellen, of zelfs een reeks records van de tabel. pt-table-sync wordt gebruikt om gegevenssynchronisatie uit te voeren, zodat uw doeldatabases opnieuw worden vernieuwd met een nieuwe kopie van de exacte gegevens van het hoofdbroncluster.

Aan de andere kant is pt-upgrade erg handig nadat de migratie van back-uptools is uitgevoerd. Met pt-upgrade kunt u deze tool gebruiken om analyses uit te voeren door een reeks query's uit te voeren, bijvoorbeeld vanuit een traag query-logbestand. Deze resultaten kunnen worden gebruikt om de brondatabase en de doeldatabaseserver te vergelijken.

Samenvatting

Databasemigratie, vooral vanuit een heterogene opzet, kan erg ingewikkeld zijn. Maar op een homogene opstelling kan het vrij eenvoudig zijn; ongeacht of de gegevens groot of klein zijn, zolang u maar bent uitgerust met de juiste tools en natuurlijk de juiste systematische aanpak om te bepalen of de migratie compleet is en dat de gegevens consistent zijn. Er kunnen momenten zijn dat een migratie overleg met de experts vereist, maar het is altijd een goed begin om deze open source-tools te bedenken en uit te proberen om de gewenste databasemigratietaak te realiseren.


  1. Aantal rijen Lezen / Werkelijke rijen Lees waarschuwingen in Plan Explorer

  2. Hoe NVL() werkt in MariaDB

  3. Wat zijn de bekende manieren om een ​​boomstructuur op te slaan in een relationele DB?

  4. Waarom is het resultaat van de rijen met explain niet gelijk aan count()?