Migrering af din database til et nyt datacenter kan være en højrisiko- og tidskrævende proces. En database indeholder tilstand og kan være meget sværere at migrere sammenlignet med webservere, køer eller cacheservere.
I dette blogindlæg vil vi give dig nogle tips til, hvordan du migrerer dine data fra en tjenesteudbyder til en anden. Processen minder lidt om vores tidligere indlæg om, hvordan man opgraderer MySQL, men der er et par vigtige forskelle.
MySQL-replikering eller Galera-klynge?
At skifte til en anden tjenesteudbyder (f.eks. at flytte fra AWS til Rackspace eller fra colocated servere til cloud) betyder meget ofte, at man ville bygge en helt ny infrastruktur parallelt, synkronisere den med den gamle infrastruktur og derefter skifte over til den. For at forbinde og synkronisere dem, vil du måske bruge MySQL-replikering.
Hvis du bruger Galera Cluster, kan det være lettere at flytte dine Galera-noder til et andet datacenter. Bemærk dog, at hele klyngen stadig skal behandles som en enkelt database. Dette betyder, at dit produktionssted kan lide under den ekstra latens, der indføres, når Galera Cluster strækkes over WAN. Det er muligt at minimere påvirkningen ved at tune netværksindstillinger i både Galera og operativsystemet, men påvirkningen kan ikke helt elimineres. Det er også muligt at opsætte asynkron MySQL-replikering mellem den gamle og den nye klynge i stedet, hvis latenspåvirkningen ikke er acceptabel.
Opsætning af sikker forbindelse
MySQL-replikering er ukrypteret og derfor ikke sikker at bruge over WAN. Der er adskillige måder at sikre, at dine data overføres sikkert. Du bør undersøge, om det er muligt at etablere en VPN-forbindelse mellem din nuværende infrastruktur og din nye tjenesteudbyder. De fleste af udbyderne (for eksempel både Rackspace og AWS) leverer en sådan service - du kan forbinde din "overskyede" del til dit eksisterende datacenter via virtuelt privat netværk.
Hvis denne løsning af en eller anden grund ikke virker for dig (måske kræver den hardware, som du ikke har adgang til), kan du bruge software til at bygge en VPN – en af dem vil være OpenVPN. Dette værktøj vil fungere fint til at opsætte krypterede forbindelser mellem dine datacentre.
Hvis OpenVPN ikke er en mulighed, er der flere måder at sikre, at replikering bliver krypteret. For eksempel kan du bruge SSH til at oprette en tunnel mellem gamle og nye datacentre og videresende 3306-porten fra den nuværende MySQL-slave (eller master) til den nye node. Det kan gøres på en meget enkel måde, så længe du har SSH-forbindelse mellem værterne:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &For eksempel:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Nu kan du oprette forbindelse til fjernserveren ved at bruge 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Det vil fungere på samme måde for replikeringen, bare husk at bruge 127.0.0.1 til master_host og 3307 for master_port
Sidst men ikke mindst kan du kryptere din replikering ved hjælp af SSL. Dette tidligere blogindlæg forklarer, hvordan det kan gøres, og hvilken indvirkning det kan have på replikeringsydelsen.
Hvis du besluttede at bruge Galera-replikering på tværs af begge datacentre, gælder ovenstående forslag også her. Når det kommer til SSL, har vi tidligere blogget om, hvordan man krypterer Galera-replikeringstrafik. For en mere komplet løsning kan det være en god idé at kryptere alle databaseforbindelser fra klientapplikationer og enhver administrations-/overvågningsinfrastruktur.
Opsætning af den nye infrastruktur
Når du har forbindelse, skal du i gang med at bygge den nye infrastruktur. Til det vil du sandsynligvis bruge xtrabackup eller mariabackup. Det kan være fristende at kombinere migreringen med MySQL-opgraderingen, når alt kommer til alt, sætter du et helt nyt miljø op på den nye placering. Det vil vi ikke anbefale at gøre. Migrering til en ny infrastruktur er betydelig nok i sig selv, så at kombinere den med en anden større ændring øger kompleksiteten og risikoen. Det gælder også for andre ting - du vil tage en trin-for-trin tilgang til ændringer. Kun ved at ændre tingene én ad gangen, kan du forstå resultaterne af ændringerne, og hvordan de påvirker din arbejdsbyrde – hvis du har lavet mere end én ændring på et givet tidspunkt, kan du ikke være sikker på, hvilken der er ansvarlig for en given (nyt) ) adfærd, som du har observeret.
Når du har en ny MySQL-instans oppe og køre i det nye datacenter, skal du slave den fra noden i det gamle datacenter – for at sikre at data i begge datacentre forbliver synkroniserede. Dette vil være praktisk, når du forbereder dig på den sidste cutover. Det er også en god måde at sikre, at det nye miljø kan håndtere din skrivebelastning.
Næste skridt vil være at bygge en komplet iscenesættelsesinfrastruktur på den nye lokation og udføre tests og benchmarks. Dette er et meget vigtigt skridt, som ikke bør springes over - problemet her er, at du som DBA skal forstå kapaciteten i din infrastruktur. Når du skifter udbyder, ændrer tingene sig også. Ny hardware/vm'er er hurtigere eller langsommere. Der er mere eller mindre hukommelse pr. instans. Du skal igen forstå, hvordan din arbejdsbyrde vil passe ind i den hardware, du skal bruge. Til det vil du sandsynligvis bruge Percona Playback eller pt-log-player til at afspille nogle af de virkelige forespørgsler på iscenesættelsessystemet. Du vil gerne teste ydeevnen og sikre, at den er på et niveau, der er acceptabelt for dig. Du ønsker også at udføre alle de standard accepttests, som du kører på dine nye udgivelser - bare for at bekræfte, at alt er oppe og køre. Generelt bør alle applikationer bygges på en måde, så de ikke er afhængige af hardwarekonfigurationen og en aktuel opsætning. Men noget er måske sluppet igennem, og din app kan afhænge af nogle af de konfigurationsjusteringer eller hardwareløsninger, du ikke har i det nye miljø.
Endelig, når du er tilfreds med dine tests, vil du gerne bygge en produktionsklar infrastruktur. Når dette er gjort, kan det være en god idé at køre nogle skrivebeskyttede tests for endelig verifikation. Dette ville være det sidste trin før cutover.
Cutover
Efter at alle disse test er blevet udført, og efter at infrastrukturen blev anset for produktionsklar, er det sidste trin at afbryde trafikken fra den gamle infrastruktur.
Globalt set er dette en kompleks proces, men når vi ser på databaseniveauet, er det mere eller mindre det samme som standard failover - noget du måske har gjort flere gange tidligere. Vi dækkede det i detaljer i et tidligere indlæg, kort fortalt er trinene:stop trafikken, sørg for at den er stoppet, vent mens applikationen flyttes til det nye datacenter (DNS-registreringer ændres eller hvad ikke), lav nogle røgtests for at sikre alt ser godt ud, gå live, overvåg nøje i et stykke tid.
Denne nedskæring vil kræve noget nedetid, som vi kan se. Problemet er at sikre, at vi har en ensartet tilstand på tværs af det gamle og det nye. Hvis vi vil gøre det uden nedetid, skal vi konfigurere master-master-replikering. Årsagen er, at efterhånden som vi opdaterer DNS og flytter sessioner fra den gamle side til den nye, vil begge systemer være i brug på samme tid - indtil alle sessioner er omdirigeret til den nye side. I mellemtiden skal eventuelle ændringer på det nye websted afspejles på det gamle websted.
Brug af Galera Cluster, som beskrevet i dette blogindlæg, kan også være en måde at holde data mellem de to websteder synkroniseret.
Vi er klar over, at dette er en meget kort beskrivelse af datamigreringsprocessen. Forhåbentlig vil det være nok til at pege dig i en god retning og hjælpe dig med at identificere, hvilke yderligere oplysninger du skal kigge efter.