Att migrera din databas till ett nytt datacenter kan vara en högrisk och tidskrävande process. En databas innehåller tillstånd och kan vara mycket svårare att migrera jämfört med webbservrar, köer eller cacheservrar.
I det här blogginlägget kommer vi att ge dig några tips om hur du migrerar din data från en tjänsteleverantör till en annan. Processen liknar något i vårt tidigare inlägg om hur man uppgraderar MySQL, men det finns ett par viktiga skillnader.
MySQL-replikering eller Galera-kluster?
Att byta till en annan tjänsteleverantör (t.ex. att flytta från AWS till Rackspace eller från samlokaliserade servrar till moln) innebär mycket ofta att man skulle bygga en helt ny infrastruktur parallellt, synkronisera den med den gamla infrastrukturen och sedan byta till den. För att ansluta och synkronisera dem kanske du vill utnyttja MySQL-replikering.
Om du använder Galera Cluster kan det vara lättare att flytta dina Galera-noder till ett annat datacenter. Observera dock att hela klustret fortfarande måste behandlas som en enda databas. Detta betyder att din produktionsplats kan drabbas av den extra latens som introduceras när Galera Cluster sträcks över WAN. Det är möjligt att minimera påverkan genom att justera nätverksinställningar i både Galera och operativsystemet, men påverkan kan inte elimineras helt. Det är också möjligt att ställa in asynkron MySQL-replikering mellan det gamla och det nya klustret istället, om latenseffekten inte är acceptabel.
Konfigurera säker anslutning
MySQL-replikering är okrypterad och därför inte säker att använda över WAN. Det finns många sätt att säkerställa att dina uppgifter överförs säkert. Du bör undersöka om det är möjligt att upprätta en VPN-anslutning mellan din nuvarande infrastruktur och din nya tjänsteleverantör. De flesta av leverantörerna (till exempel både Rackspace och AWS) tillhandahåller en sådan tjänst - du kan ansluta din "molniga" del till ditt befintliga datacenter via virtuellt privat nätverk.
Om den här lösningen av någon anledning inte fungerar för dig (kanske kräver hårdvara som du inte har tillgång till) kan du använda mjukvara för att bygga ett VPN – en av dem kommer att vara OpenVPN. Det här verktyget kommer att fungera bra för att ställa in krypterade anslutningar mellan dina datacenter.
Om OpenVPN inte är ett alternativ finns det fler sätt att säkerställa att replikering kommer att krypteras. Till exempel kan du använda SSH för att skapa en tunnel mellan gamla och nya datacenter, och vidarebefordra 3306-porten från den nuvarande MySQL-slaven (eller mastern) till den nya noden. Det kan göras på ett väldigt enkelt sätt så länge du har SSH-anslutning mellan värdarna:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Till exempel:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Nu kan du ansluta till fjärrservern genom att använda 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Det kommer att fungera på samma sätt för replikeringen, kom bara ihåg att använda 127.0.0.1 för master_host och 3307 för master_port
Sist men inte minst kan du kryptera din replikering med SSL. Det här tidigare blogginlägget förklarar hur det kan göras och vilken typ av inverkan det kan ha på replikeringsprestandan.
Om du bestämt dig för att använda Galera-replikering över båda datacenterna, gäller ovanstående förslag även här. När det kommer till SSL har vi tidigare bloggat om hur man krypterar Galera-replikeringstrafik. För en mer komplett lösning kanske du vill kryptera alla databasanslutningar från klientapplikationer och eventuell hanterings-/övervakningsinfrastruktur.
Konfigurera den nya infrastrukturen
När du har anslutningsmöjligheter måste du börja bygga den nya infrastrukturen. För det kommer du förmodligen att använda xtrabackup eller mariabackup. Det kan vara frestande att kombinera migreringen med MySQL-uppgraderingen, trots allt sätter du upp en helt ny miljö på den nya platsen. Vi skulle inte rekommendera att göra det. Att migrera till en ny infrastruktur är tillräckligt betydande i sig så att kombinera den med en annan stor förändring ökar komplexiteten och risken. Det är sant för andra saker också - du vill ta steg-för-steg-strategin för förändringar. Bara genom att ändra saker en i taget kan du förstå resultatet av ändringarna och hur de påverkar din arbetsbelastning - om du gjorde mer än en ändring vid en viss tidpunkt kan du inte vara säker på vilken som är ansvarig för en given tid (ny ) beteende som du har observerat.
När du har en ny MySQL-instans igång i det nya datacentret måste du slava den från noden i det gamla datacentret - för att säkerställa att data i båda datacentren förblir synkroniserade. Detta kommer att vara praktiskt när du förbereder dig för den sista cutover. Det är också ett bra sätt att se till att den nya miljön kan hantera din skrivbelastning.
Nästa steg blir att bygga en komplett iscensättningsinfrastruktur på den nya platsen och utföra tester och benchmarks. Detta är ett mycket viktigt steg som inte bör hoppas över - problemet här är att du som DBA måste förstå kapaciteten i din infrastruktur. När du byter leverantör förändras saker också. Ny hårdvara/vm är snabbare eller långsammare. Det finns mer eller mindre minne per instans. Du måste förstå igen hur din arbetsbelastning kommer att passa i hårdvaran du ska använda. För det kommer du förmodligen att använda Percona Playback eller pt-log-player för att spela om några av de verkliga frågorna på iscensättningssystemet. Du vill testa prestandan och se till att den är på en nivå som är acceptabel för dig. Du vill också utföra alla standardacceptanstest som du kör på dina nya utgåvor - bara för att bekräfta att allt är igång. I allmänhet bör alla applikationer byggas på ett sätt så att de inte förlitar sig på hårdvarukonfigurationen och på en aktuell installation. Men något kan ha glidit igenom och din app kan bero på några av de konfigurationsjusteringar eller hårdvarulösningar som du inte har i den nya miljön.
Slutligen, när du är nöjd med dina tester, vill du bygga en produktionsklar infrastruktur. När detta är gjort kanske du vill köra några skrivskyddade tester för slutlig verifiering. Detta skulle vara det sista steget innan cutover.
Cutover
Efter att alla dessa tester har utförts och efter att infrastrukturen bedömdes vara produktionsklar, är det sista steget att stänga av trafiken från den gamla infrastrukturen.
Globalt sett är detta en komplex process men när vi tittar på databasnivån är det mer eller mindre samma sak som standard failover - något som du kan ha gjort flera gånger tidigare. Vi behandlade det i detaljer i ett tidigare inlägg, i korthet är stegen:stoppa trafiken, se till att den är stoppad, vänta medan applikationen flyttas till det nya datacentret (DNS-poster ändras eller vad inte), gör några röktester för att säkerställa allt ser bra ut, sänd live, övervaka noga ett tag.
Denna nedbrytning kommer att kräva lite stillestånd, som vi kan se. Problemet är att se till att vi har ett konsekvent tillstånd på den gamla och den nya. Om vi vill göra det utan driftstopp måste vi ställa in master-master-replikering. Anledningen är att när vi uppdaterar DNS och flyttar över sessioner från den gamla platsen till den nya, kommer båda systemen att användas samtidigt - tills alla sessioner omdirigeras till den nya platsen. Under tiden måste alla ändringar på den nya webbplatsen återspeglas på den gamla.
Att använda Galera Cluster, som beskrivs i det här blogginlägget, kan också vara ett sätt att hålla data mellan de två webbplatserna synkroniserade.
Vi är medvetna om att detta är en mycket kort beskrivning av datamigreringsprocessen. Förhoppningsvis kommer det att räcka för att peka dig i en bra riktning och hjälpa dig att identifiera vilken ytterligare information du behöver leta efter.