Het migreren van uw database naar een nieuw datacenter kan een risicovol en tijdrovend proces zijn. Een database bevat een status en kan veel moeilijker te migreren zijn in vergelijking met webservers, wachtrijen of cacheservers.
In deze blogpost geven we u enkele tips over hoe u uw gegevens van de ene serviceprovider naar de andere kunt migreren. Het proces lijkt enigszins op ons vorige bericht over het upgraden van MySQL, maar er zijn een paar belangrijke verschillen.
MySQL-replicatie of Galera-cluster?
Overstappen naar een andere serviceprovider (bijvoorbeeld overstappen van AWS naar Rackspace of van colocated servers naar de cloud) betekent vaak dat men parallel een geheel nieuwe infrastructuur bouwt, deze synchroniseert met de oude infrastructuur en er vervolgens naar overschakelt. Om ze te verbinden en te synchroniseren, wil je misschien MySQL-replicatie gebruiken.
Als u Galera Cluster gebruikt, is het wellicht gemakkelijker om uw Galera-nodes naar een ander datacenter te verplaatsen. Houd er echter rekening mee dat het hele cluster nog steeds als één database moet worden behandeld. Dit betekent dat uw productiesite te lijden kan hebben van de extra latentie die ontstaat wanneer Galera Cluster over het WAN wordt uitgerekt. Het is mogelijk om de impact te minimaliseren door de netwerkinstellingen in zowel Galera als het besturingssysteem af te stemmen, maar de impact kan niet volledig worden geëlimineerd. Het is ook mogelijk om in plaats daarvan asynchrone MySQL-replicatie in te stellen tussen het oude en het nieuwe cluster, als de latentie-impact niet acceptabel is.
Beveiligde connectiviteit instellen
MySQL-replicatie is niet-versleuteld en daarom niet veilig om via het WAN te gebruiken. Er zijn talloze manieren om ervoor te zorgen dat uw gegevens veilig worden overgedragen. U dient te onderzoeken of het mogelijk is om een VPN-verbinding tot stand te brengen tussen uw huidige infrastructuur en uw nieuwe serviceprovider. De meeste providers (bijvoorbeeld zowel Rackspace als AWS) bieden een dergelijke service - u kunt uw "bewolkte" deel via een virtueel particulier netwerk verbinden met uw bestaande datacenter.
Als deze oplossing om de een of andere reden niet voor u werkt (misschien vereist het hardware waartoe u geen toegang hebt), kunt u software gebruiken om een VPN te bouwen - een daarvan is OpenVPN. Deze tool werkt goed om versleutelde verbindingen tussen uw datacenters op te zetten.
Als OpenVPN geen optie is, zijn er meer manieren om ervoor te zorgen dat replicatie wordt versleuteld. U kunt SSH bijvoorbeeld gebruiken om een tunnel te maken tussen oude en nieuwe datacenters en de 3306-poort door te sturen van de huidige MySQL-slave (of master) naar de nieuwe node. Het kan op een heel eenvoudige manier worden gedaan, zolang je SSH-connectiviteit hebt tussen de hosts:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Bijvoorbeeld:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &U kunt nu verbinding maken met de externe server met behulp van 127.0.0.1:3307
$ mysql -P3307 -h 127.0.0.1Het zal op dezelfde manier werken voor de replicatie, vergeet niet om 127.0.0.1 te gebruiken voor de master_host en 3307 voor de master_port
Last but not least kunt u uw replicatie versleutelen met SSL. In deze vorige blogpost wordt uitgelegd hoe dit kan en wat voor impact het kan hebben op de replicatieprestaties.
Als je hebt besloten om Galera-replicatie in beide datacenters te gebruiken, zijn bovenstaande suggesties ook hier van toepassing. Als het op SSL aankomt, hebben we eerder geblogd over het versleutelen van Galera-replicatieverkeer. Voor een completere oplossing wilt u misschien alle databaseverbindingen van clienttoepassingen en elke beheer-/bewakingsinfrastructuur versleutelen.
De nieuwe infrastructuur opzetten
Zodra u verbinding heeft, moet u beginnen met het bouwen van de nieuwe infrastructuur. Daarvoor gebruik je waarschijnlijk xtrabackup of mariabackup. Het is misschien verleidelijk om de migratie te combineren met de MySQL-upgrade, u zet immers een geheel nieuwe omgeving in op de nieuwe locatie. Dat zouden we niet aanraden. Migreren naar een nieuwe infrastructuur is op zich al belangrijk genoeg, dus de combinatie met een andere grote verandering verhoogt de complexiteit en het risico. Dat geldt ook voor andere dingen:je wilt veranderingen stapsgewijs aanpakken. Alleen door dingen één voor één te wijzigen, kunt u de resultaten van de wijzigingen begrijpen en hoe deze van invloed zijn op uw werklast. Als u meer dan één wijziging tegelijk heeft aangebracht, weet u niet zeker welke verantwoordelijk is voor een bepaalde (nieuwe ) gedrag dat je hebt waargenomen.
Wanneer u een nieuwe MySQL-instantie in het nieuwe datacenter in gebruik heeft, moet u deze van het knooppunt in het oude datacenter afzetten - om ervoor te zorgen dat de gegevens in beide datacenters synchroon blijven. Dit zal handig worden als u zich voorbereidt op de definitieve overgang. Het is ook een goede manier om ervoor te zorgen dat de nieuwe omgeving uw schrijfbelasting aankan.
De volgende stap is het bouwen van een complete staging-infrastructuur op de nieuwe locatie en het uitvoeren van tests en benchmarks. Dit is een zeer belangrijke stap die niet mag worden overgeslagen - het probleem hier is dat u als DBA de capaciteit van uw infrastructuur moet begrijpen. Als je van aanbieder verandert, veranderen er ook dingen. Nieuwe hardware/vm's zijn sneller of langzamer. Er is meer of minder geheugen per instantie. U moet opnieuw begrijpen hoe uw werklast zal passen in de hardware die u gaat gebruiken. Daarvoor zul je waarschijnlijk Percona Playback of pt-log-player gebruiken om enkele van de real-life queries op het staging-systeem opnieuw af te spelen. U wilt de prestaties testen en ervoor zorgen dat deze op een niveau zijn dat voor u acceptabel is. U wilt ook alle standaard acceptatietests uitvoeren die u op uw nieuwe releases uitvoert - gewoon om te bevestigen dat alles werkt. Over het algemeen moeten alle applicaties zo worden gebouwd dat ze niet afhankelijk zijn van de hardwareconfiguratie en van een huidige setup. Maar er kan iets zijn geglipt en uw app kan afhankelijk zijn van enkele van de configuratie-tweaks of hardware-oplossingen die u niet heeft in de nieuwe omgeving.
Tot slot, als u eenmaal tevreden bent met uw tests, wilt u een productieklare infrastructuur bouwen. Nadat dit is gebeurd, wilt u misschien enkele alleen-lezen-tests uitvoeren voor definitieve verificatie. Dit zou de laatste stap zijn voor de overgang.
Knipsel
Nadat al die tests zijn uitgevoerd en nadat de infrastructuur productieklaar is bevonden, is de laatste stap om het verkeer van de oude infrastructuur af te sluiten.
Globaal gesproken is dit een complex proces, maar als we kijken naar de databaselaag, is het min of meer hetzelfde als standaard failover - iets dat u in het verleden misschien meerdere keren hebt gedaan. We hebben het in een eerdere post in detail besproken, in het kort zijn de stappen:stop het verkeer, zorg dat het wordt gestopt, wacht terwijl de applicatie wordt verplaatst naar het nieuwe datacenter (DNS-records veranderen of wat niet), doe wat rooktests om er zeker van te zijn alles ziet er goed uit, ga live, houd het een tijdje nauwlettend in de gaten.
Deze overgang vereist enige downtime, zoals we kunnen zien. Het probleem is om ervoor te zorgen dat we een consistente status hebben op de oude en de nieuwe site. Als we het zonder downtime willen doen, moeten we master-master-replicatie instellen. De reden is dat wanneer we DNS vernieuwen en sessies van de oude site naar de nieuwe verplaatsen, beide systemen tegelijkertijd in gebruik zullen zijn - totdat alle sessies zijn omgeleid naar de nieuwe site. In de tussentijd moeten eventuele wijzigingen op de nieuwe site worden weergegeven op de oude site.
Het gebruik van Galera Cluster, zoals beschreven in deze blogpost, kan ook een manier zijn om gegevens tussen de twee sites synchroon te houden.
We zijn ons ervan bewust dat dit een zeer korte beschrijving is van het gegevensmigratieproces. Hopelijk is het voldoende om u in een goede richting te wijzen en u te helpen bepalen naar welke aanvullende informatie u moet zoeken.