Stora organisationer som använder MySQL- eller MariaDB-databasplattformar står ofta inför ett behov av att utföra en databasmigrering från en plats till en annan. Oavsett plattform, typ av databasprogramvara (som från RDBMS till NoSQL eller NoSQL som går tillbaka till RDBMS), eller om det bara är en datamigrering, är att utföra en migrering en enorm mängd arbete och kostnader.
En databasmigrering kommer alltid att involvera processen att migrera data från en eller flera källdatabaser till en eller flera måldatabaser. Detta kan involvera en databasmigreringstjänst eller en mashup-uppsättning verktyg som ingenjörerna har byggt för att skapa en tjänst och skräddarsy för denna typ av problem.
Det förväntas att en databasmigrering inte betyder att källdatabasplattformen kommer att hamna i målplattformen exakt som ursprungskällan. När en migrering är klar kan datauppsättningen från måldatabaserna eventuellt omstruktureras. Det som är viktigast när migreringen väl är klar är att klienterna som kommer åt databasen ska omdirigeras till de nya källdatabaserna. Den nya källdatabasen måste tillhandahålla den exakta kopian av data från källan och utan inverkan på prestanda som kan påverka den övergripande användarupplevelsen.
Att flytta dina data från en plattform till målplattformen är en enorm uppgift att göra. Detta är vad en databasmigrering omfattar när en organisation eller ett företag bestämmer sig för att släcka sitt ljus till den nuvarande plattformen av flera skäl. De vanliga orsakerna till att migrera data är på grund av kostnadseffektivitet till måldestinationsplattformen eller dess flexibilitet vid distribution och skalbarhet. Medan den nuvarande plattformen som är värd för nuvarande produktionsdata orsakar mer kostnader för sina uppgraderingar och skalbarhet, är det bara betungande när man implementerar små ändringar som faktiskt kan distribueras i en mikrotjänstplattform.
I den här bloggen kommer vi att fokusera på de bästa verktygen med öppen källkod som du kan använda för MySQL- och MariaDB-migrering på en mer homogen databasmigrering.
Verktyg för säkerhetskopiering för datamigrering
Den enklaste vägen att använda när du utför migrering är att använda verktyg för databassäkerhetskopiering. Vi ska titta på vad dessa verktyg är och hur du kan använda dem under migreringen.
mysqldump/mysqlpump
Detta verktyg är ett av de mest kända verktygen för MySQL eller MariaDB som en databasadministratör eller systemadministratör kopplar detta verktyg för att migrera antingen en hel databas eller en delkopia av databasen. För databasadministratörer som inte är bekanta med MySQL/MariaDB låter det här verktyget dig skapa en kopia av säkerhetskopia som genererar en logisk kopia av data som du kan dumpa på måldatabasen.
En vanlig installation med att använda det här verktyget är att när en måldatabas finns någon annanstans och är värd på en annan plattform än källan, fungerar målet som en slav eller replik. Att använda mysqldump som vanligtvis anropas med --single-transaction på ett upptaget system, och med --master-data kommer att ge dig koordinaterna för att ställa in en slav på måldatabasen som kommer att användas som en värd för datamigrering. Ett alternativ till mysqldump är också mysqlpump men med en mindre funktion som ändå kan göra parallell bearbetning av databaser, och av objekt i databaser, för att påskynda dumpningsprocessen. Nackdelen är att med mysqlpump finns det inget alternativ som du kan använda såsom --master-data vilket är mycket användbart om du vill skapa en replik som kommer att användas som måldestination för databasmigrering.
mysqlpump är fördelaktigt om dina data är mer inaktiva eller sätts i underhållsläge så att inga bearbetade skrivningar eller ändringar pågår till källdatabasen. Det är snabbare och snabbare jämfört med mysqldump.
mydumper/myloader
mydumper/myloader är ett mycket snyggt och effektivt verktyg som du kan använda för logisk säkerhetskopiering, speciellt för att importera bulkdata med snabbare bearbetningshastighet eftersom det erbjuder parallellitet, möjlighet att skicka data i bitar, stöder tröskelvärden och kontroll betygsätt antalet trådar, rader, satsstorlek och komprimera resultatet. Den genererar eller inkluderar binära loggfiler och loggpositioner, vilket är mycket användbart om du ställer in måldestinationsplattformen för att fungera som en replik av den aktuella käll- och produktionsmiljön.
I grund och botten är mydumper det binära och kommandot du måste anropa via kommandoraden för att skapa den logiska säkerhetskopian. Medan myloader är det binära och kommandot du måste använda när du laddar data till den önskade måldestinationen. Dess flexibilitet gör att du kan hantera önskad hastighet när du bearbetar åtgärderna oavsett om det skapar en säkerhetskopia eller laddar data. Med mydumper kan du också skapa en fullständig säkerhetskopia eller bara en partiell säkerhetskopia av din källdatabas. Detta är mycket användbart om du behöver en stor data eller ett schema som du vill flytta bort från den aktuella databasvärden och flytta den något till en annan måldestination medan du börjar ställa in en ny databasskärvor. Detta kan också vara ett sätt att migrera stora data genom att dra ett stort segment av datamängden och sedan flytta den men som en ny skärvnod.
mydumper/myloader har också sina begränsningar. Det har stoppats från uppdateringar från de ursprungliga författarna men sparats av Max Bube men verktyget används fortfarande i stor utsträckning även för produktionsmiljöer.
Percona XtraBackup/MariaDB Backup
Perconas XtraBackup är en gåva till databasadministratörer som inte vill använda och spendera pengar för företaget Oracle MySQL Enterprise Backup. Medan MariaDB Backup är kluven och härledd från Percona XtraBackup, har de också MariaDB Enterprise Backup.
Båda dessa verktyg delar samma koncept när de utför eller tar en säkerhetskopia. Det är en binär backup som erbjuder en het online backup, PITR, inkrementell och full backup, partiell backup, även användbar för dataåterställning eftersom den förstår återställning som producerar binär loggfil och position, stöder GTID och mycket mer. Även om MariaDB Backup och Percona XtraBackup är två olika typer av programvara nuförtiden eftersom de är utformade för att stödja databasen fokuserad för att tillhandahålla en säkerhetskopia. MariaDB Backup är definitivt tillämplig om du tänker använda eller ta säkerhetskopior från en MariaDB-databaskälla. Medan Percona XtraBackup är tillämpligt på Oracle MySQL och även på Percona Server eller några härledda MySQL-servrar som Percona XtraDB Server eller Coderships version av Galera Cluster för MySQL.
Båda säkerhetskopiorna är mycket fördelaktiga för databasmigrering. Att utföra en het online backup är snabbare och snabbare och ger en backup som du direkt kan använda för att ladda den till din måldatabas. Oftare är streaming backup praktiskt liksom att du kan utföra en online backup och strömma binära data till måldatabasen med socat eller netcat. Detta gör att du kan förkorta migreringstiden eftersom att flytta data till måldestinationen strömmas direkt.
Den vanligaste metoden för datamigrering när du använder det här verktyget är att kopiera data från källan och sedan strömma data till måldestinationen. Väl i måldatabasdestinationen kan du bara förbereda den binära säkerhetskopian med alternativet --prepare där den tillämpar loggarna som registrerades under tiden för säkerhetskopieringen så att den kopierar hela data som den är och exakt från tidpunkten där säkerhetskopian togs. Ställ sedan in måldatabasens destination som en replik för att fungera som en replik eller slav av det befintliga källklustret och replikera alla de ändringar och transaktioner som har inträffat från huvudklustret.
Självklart finns det en begränsning också för att använda det här verktyget, men databasadministratörer måste veta hur man använder det här verktyget och även hur man stryper och anpassar användningen i enlighet med dess önskade användning. Du kanske inte vill köra ner din källdatabas om din källa tar för mycket trafik eller stor bearbetning från den tiden. Dess begränsning säkerställer också att det är en homogen uppställning där målkällan är ett Linux-kompatibelt system och inte på en miljö av Windows-typ eftersom Percona XtraBackup och MariaDB Backup endast fungerar i Linux-miljön.
Databasschemamigreringsverktyg
Databasmigrering talar inte bara om ett specifikt verktyg och en specifik uppgift, då kan migrering ske. Det finns många överväganden och underliggande efterföljande uppgifter som måste göras för att fullfölja en komplett databasmigrering. En av dessa är schemamigreringen eller databasmigreringen. Ett schema i MySQL/MariaDB är en samling data som består av en grupp tabeller med dess kolumner och rader, händelser, triggers, lagrade procedurer eller rutiner och funktioner. Det finns tillfällen då du kanske bara vill migrera ett schema eller bara en tabell. Låt säga att en specifik tabell i ett schema kräver en förändring i dess tabellstruktur och det kräver en DDL-sats. Problemet är att körning av en direkt DDL-sats som ALTER TABLE ...ENGINE=InnoDB blockerar alla inkommande transaktioner eller anslutningar som också kommer att referera eller använda till måltabellen. För vissa enorma tabeller som innehåller långa datadefinitioner och tabellens struktur, tillför det mer verklig utmaning och komplicerar också mer, särskilt om tabellen är en het tabell. Medan i en databasmigrering kan det vara svårt att kopiera den exakta fullständiga kopian av hela tabellen utan driftstopp från källan. Så låt oss se vad dessa är.
pt-online-schema-change
Det är en del av den berömda Percona Toolkit som ursprungligen härrörde från Maatkit och Aspersa. Det här verktyget är mycket användbart när du utför en ändring av tabelldefinitionen, särskilt för en het tabell som består av en enorm mängd data. För ett vanligt men naivt tillvägagångssätt för att utföra en ändring av tabelldefinitionen kan körning av ALTER TABLE göra jobbet. Även om det räcker, orsakar ALTER TABLE utan att använda ALGORITHM=INPLACE en fullständig tabellkopia som får ett fullständigt metadatalås och det betyder att din databas möjligen kan staplas upp och låsas under en lång tidsperiod, särskilt om tabellen är enorm. I så fall är det här verktyget byggt för att lösa det problemet. Det här verktyget är mycket fördelaktigt för databasmigrering på ett sådant sätt att en upptäckt inkonsekvent kopia av en aktiv tabell med mycket stora data från din redan inställda måldatabasdestination. Istället för att göra en säkerhetskopia med antingen en logisk eller binär/fysisk kopia, kan pt-online-schema-change användas som kopierar raderna från källtabellen till måltabellen bit för bit. Du kan till och med anpassa kommandot med korrekta anrop till dess parametrar beroende på dina krav.
Bortsett från att använda, använder pt-online-schema-change också utlösare. Genom att använda triggers ska all efterföljande eller pågående trafik som försöker tillämpa ändringar i den referenstabellen också kopieras till måldatabasen som fungerar som en replik av det aktuella källdatabasklustret. Detta kopierar all data exakt vilken data som källdatabasen har ner till din måldatabas som till exempel ligger på en annan plattform. Att använda triggers är tillämpligt för att användas för MySQL och MariaDB så länge dess motor är InnoDB och har en primär nyckelnärvaro på det bordet, vilket är ett krav. Du kanske vet att InnoDB använder en radlåsningsmekanism som gör att pt-online-schema-change för ett visst antal bitar (en grupp utvalda poster) försöker kopiera det och sedan tillämpar INSERT-satsen på måltabellen . Måltabellen är en dummytabell som fungerar som en målkopia av den snart ersättare av den befintliga källtabellen. pt-online-schema-change tillåter dock användaren att antingen ta bort dummy-tabellen eller bara låta dummy-tabellen vara på plats tills administratören är redo att ta bort den tabellen. Observera att om du släpper eller tar bort en tabell får du ett metadatalås. Eftersom den får utlösare, ska alla efterföljande ändringar kopieras exakt till måltabellen utan att lämna någon avvikelse på mål- eller dummytabellen.
gh-ost
Delar samma koncept som pt-online-schema-change. Det här verktyget är annorlunda jämfört med pt-online-schema-change. Jag ska säga, migreringen av schemaverktyget närmar sig de produktionsbaserade hinder som kan få din databas att sakta ner och eventuellt fastna, vilket gör att ditt databaskluster faller ner under underhållsläge eller ner under en okänd tidsperiod, tills problemet är löst. Detta problem orsakas vanligtvis av triggers. Om du har en upptagen eller het tabell som genomgår en schemaändring eller ändring av tabelldefinitionen, kan utlösare göra att din databas staplas upp på grund av låskonflikter. MySQL/MariaDB-utlösare låter din databas definiera utlösare för INSERT, UPPDATERA och DELETE. Om målbordet är på en hotspot kan det sluta otäckt. Din databas börjar bli långsammare tills den fastnar såvida du inte kan döda de inkommande frågorna eller bäst att ta bort triggers, men det är inte vad det ideala tillvägagångssättet handlar om.
På grund av dessa problem löser gh-ost det problemet. Det fungerar som om det finns en binär loggserver där inkommande händelser eller transaktioner loggas i ett binärt loggformat, speciellt med RBR (Row Based Replication). Faktum är att det är väldigt säkert och mindre bekymmer när det gäller påverkan du behöver möta. Faktum är att du också har möjlighet att göra ett test eller torrkörning (samma som med pt-online-schema-change) men testa det direkt i repliken eller en slavnod. Detta är perfekt om du vill leka och kontrollera den exakta kopian till din måldatabas under migreringen.
Detta verktyg är mycket flexibelt i enlighet med dina behov och innebär försäkran om att ditt kluster inte fastnar eller troligen kommer att utföra en failover eller dataåterställning om det blir värre. För mer information och vill lära dig det här verktyget föreslår jag att du läser det här inlägget från Github av Shlomi Noach.
Andra OSC-verktyg
Jag kan säga att dessa två verktyg är mer att rekommendera, men andra alternativ kan du också prova. Oftast använder dessa verktyg MySQL/MariaDB-utlösare så att det på något sätt delar samma koncept som pt-online-schema-change. Här är följande lista:
- LHM - Databasmigreringar i Rails-stil är ett användbart sätt att utveckla ditt dataschema på ett smidigt sätt. De flesta Rails-projekt börjar så här, och till en början är det snabbt och enkelt att göra ändringar.
- OnlineSchemaChange - Skapad och initierad av Facebook. Detta verktyg används för att göra schemaändringar för MySQL-tabeller på ett icke-blockerande sätt
- TableMigrator - Initierad av Serious Business och tidigare anställda på Twitter. Det här verktyget delar samma princip med migrering av stora tabeller utan driftstopp i MySQL. Det är implementerat med Rails så det kan vara användbart om du har en Ruby-on-Rails-applikationsmiljö.
- oak-online-alter-table - detta är ett gammalt verktyg skapat av Shlomi Noach även om det på något sätt närmar sig samma tillvägagångssätt som pt-online-schema-change och utför en icke-blockerande ALTER TABLE-operation
Verktyg i guiden för databasmigrering
Det finns få migreringsverktyg som erbjuder gratis användning, vilket är mycket fördelaktigt i viss mån. Vad som är mer fördelaktigt med att använda migreringsguidens verktyg är att de har GUI som du kan ha bekvämligheten att se den aktuella strukturen för eller bara följa stegen som UI tillhandahåller under migreringen. Det kan finnas många tjänster eller guideverktyg men det är inte öppen källkod och det är inte tillgängligt gratis. Naturligtvis är en databasmigrering en mycket komplex men ändå en systematisk process, men i vissa fall kräver den stort arbete och ansträngningar. Låt oss ta en titt på dessa kostnadsfria verktyg.
MySQL Workbench
Som namnet antyder är det för MySQL och derivatdatabaser som Percona Server till exempel kan vara användbar när det kommer till databasmigrering. Eftersom MariaDB helt har gått över till en annan rutt, särskilt sedan 10.2-versionen, finns det några inkompatibilitetsproblem du kan stöta på om du försöker använda detta från en MariaDB-källa eller -mål. Workbench kan användas för heterogena typer av databaser som de som kommer från olika källdatabaser och vill dumpa data till MySQL.
MySQL Workbench består av community- och företagsversioner. Ändå är communityversionen fritt tillgänglig som GPL som du kan hitta här https://github.com/mysql/mysql-workbench. Som dokumentationen säger tillåter MySQL Workbench dig att migrera från Microsoft SQL Server, Microsoft Access, Sybase ASE, SQLite, SQL Anywhere, PostreSQL och andra RDBMS-tabeller, objekt och data till MySQL. Migrering stöder även migrering från tidigare versioner av MySQL till de senaste utgåvorna.
phpMyAdmin
För dem som arbetar som webbutvecklare som använder LAMP-stacken kommer det här verktyget inte som någon överraskning eftersom det är en av deras schweiziska arméknivar när de hanterar databasuppgifter. phpMyAdmin är ett gratis mjukvaruverktyg skrivet i PHP, avsett att hantera administrationen av MySQL över webben. phpMyAdmin stöder ett brett utbud av operationer på MySQL och MariaDB. Ofta använda operationer (hantera databaser, tabeller, kolumner, relationer, index, användare, behörigheter, etc) kan utföras via användargränssnittet, medan du fortfarande har möjlighet att direkt exekvera vilken SQL-sats som helst.
Även om det är ganska enkelt när det gäller import och export, är det viktiga att det gör jobbet gjort. Även om det för större och mer komplex migrering kanske inte räcker för att hantera dina önskade behov.
HeidiSQL
HeidiSQL är fri programvara och har som mål att vara lätt att lära sig. "Heidi" låter dig se och redigera data och strukturer från datorer som kör ett av databassystemen MariaDB, MySQL, Microsoft SQL, PostgreSQL och SQLite. HeidiSQL uppfanns 2002 av Ansgar och tillhör de mest populära verktygen för MariaDB och MySQL över hela världen.
För migreringsändamål låter den dig exportera från en server/databas direkt till en annan server/databas. Den har också importfunktioner för att tillåta textfält som CSV, och även exportera tabellrader till ett brett utbud av filtyper som stöds som CSV, HTML, XML, SQL, LaTeX, Wiki Markup och PHP Array. Även om den är byggd för att hantera databaser för administration av db-server, kan du ändå använda den för enkla migreringsgrejer.
Percona Toolkit som din schweiziska armékniv
Percona Toolkit är en anmärkningsvärd programvara som distribueras som en öppen källkodsprogramvara under GPL:s garanti. Percona Toolkit är en samling av avancerade kommandoradsverktyg som ofta används internt av Percona, men det är också tillämpligt för alla databasarbeten som är relaterade speciellt för MySQL/MariaDB-servrar.
Så hur och varför är det också användbart för datamigrering, särskilt i MySQL/MariaDB-migreringar? De har ett antal verktyg här som är fördelaktiga att använda vid migrering och efter migrering.
Som nämnts tidigare är ett vanligt tillvägagångssätt för datamigrering att ha måldestinationsservern som en replik av huvudkälldatabasklustret men i en homogen uppsättning. Detta innebär att, om situationen går från lokal till en offentlig molnleverantör, kan du ställa in en vald nod från den plattformen och denna nod kommer att replikera alla transaktioner från huvudklustret. Genom att använda verktyg för säkerhetskopiering kan du kanske uppnå den här typen av migreringsinställningar. Men det slutar inte där. Percona Toolkit har pt-table-checksum/pt-table-sync-verktyg till exempel för att hjälpa dig att identifiera datainkonsekvenser mellan lokal och måldatabasservern. Med pt-table-checksum kan du utföra checksummaberäkningar baserat på en serie bitar för alla databaser eller bara selektivt checksumma på särskilda databaser, eller särskilda tabeller, eller till och med en rad poster i tabellen. pt-table-sync kommer att användas för att utföra datasynkronisering så att dina måldatabaser kommer att uppdateras igen med en ny kopia av exakt data från huvudkällklustret.
Å andra sidan är pt-upgrade mycket användbart efter att migreringen från säkerhetskopieringsverktygen har utförts. Med pt-upgrade kan du använda det här verktyget för att utföra analys genom att köra en uppsättning frågor, till exempel från en långsam frågeloggfil. Dessa resultat kan användas för att jämföra från källdatabasen och mot måldatabasservern.
Sammanfattning
Databasmigrering, särskilt från en heterogen installation, kan vara mycket komplicerad. Men på en homogen uppställning kan det vara ganska okomplicerat; oavsett om data är stor eller liten så länge du är utrustad med rätt verktyg och, naturligtvis, det korrekta systematiska tillvägagångssättet för att fastställa att migreringen är komplett med data som är konsekventa. Det kan finnas tillfällen då en migrering kräver konsultation med experterna, men det är alltid en bra början att komma upp och prova med dessa verktyg med öppen källkod för att uppnå din önskade databasmigreringsuppgift.