Die Migration Ihrer Datenbank in ein neues Rechenzentrum kann ein risikoreicher und zeitaufwändiger Prozess sein. Eine Datenbank enthält Status und kann im Vergleich zu Webservern, Warteschlangen oder Cache-Servern viel schwieriger zu migrieren sein.
In diesem Blogbeitrag geben wir Ihnen einige Tipps, wie Sie Ihre Daten von einem Dienstleister zu einem anderen migrieren können. Der Prozess ähnelt unserem vorherigen Beitrag zum Aktualisieren von MySQL, aber es gibt ein paar wichtige Unterschiede.
MySQL-Replikation oder Galera-Cluster?
Der Wechsel zu einem anderen Dienstleister (z. B. der Wechsel von AWS zu Rackspace oder von Colocated-Servern in die Cloud) bedeutet sehr oft, dass man parallel eine brandneue Infrastruktur aufbaut, sie mit der alten Infrastruktur synchronisiert und dann darauf umsteigt. Um sie zu verbinden und zu synchronisieren, möchten Sie vielleicht die MySQL-Replikation nutzen.
Wenn Sie Galera Cluster verwenden, ist es möglicherweise einfacher, Ihre Galera-Knoten in ein anderes Rechenzentrum zu verschieben. Beachten Sie jedoch, dass der gesamte Cluster immer noch als einzelne Datenbank behandelt werden muss. Dies bedeutet, dass Ihr Produktionsstandort möglicherweise unter der zusätzlichen Latenz leidet, die beim Dehnen des Galera-Clusters über das WAN entsteht. Es ist möglich, die Auswirkungen zu minimieren, indem Sie die Netzwerkeinstellungen sowohl in Galera als auch im Betriebssystem optimieren, aber die Auswirkungen können nicht vollständig eliminiert werden. Es ist auch möglich, stattdessen eine asynchrone MySQL-Replikation zwischen dem alten und dem neuen Cluster einzurichten, wenn die Auswirkung auf die Latenz nicht akzeptabel ist.
Sichere Konnektivität einrichten
Die MySQL-Replikation ist unverschlüsselt und kann daher nicht sicher über das WAN verwendet werden. Es gibt zahlreiche Möglichkeiten, um sicherzustellen, dass Ihre Daten sicher übertragen werden. Sie sollten prüfen, ob es möglich ist, eine VPN-Verbindung zwischen Ihrer aktuellen Infrastruktur und Ihrem neuen Dienstanbieter herzustellen. Die meisten Anbieter (z. B. sowohl Rackspace als auch AWS) bieten einen solchen Service an – Sie können Ihren „Cloud“-Teil über ein virtuelles privates Netzwerk mit Ihrem vorhandenen Rechenzentrum verbinden.
Wenn diese Lösung aus irgendeinem Grund für Sie nicht funktioniert (vielleicht erfordert sie Hardware, auf die Sie keinen Zugriff haben), können Sie Software verwenden, um ein VPN aufzubauen – eines davon wird OpenVPN sein. Dieses Tool funktioniert gut, um verschlüsselte Verbindungen zwischen Ihren Rechenzentren einzurichten.
Wenn OpenVPN keine Option ist, gibt es weitere Möglichkeiten, um sicherzustellen, dass die Replikation verschlüsselt wird. Sie können beispielsweise SSH verwenden, um einen Tunnel zwischen alten und neuen Rechenzentren zu erstellen und den Port 3306 vom aktuellen MySQL-Slave (oder -Master) an den neuen Knoten weiterzuleiten. Dies kann auf sehr einfache Weise erfolgen, solange Sie eine SSH-Verbindung zwischen den Hosts haben:
$ ssh -L local_port:old_dc_host:mysql_port_in_old_dc [email protected]_dc_host -N &Zum Beispiel:
$ ssh -L 3307:10.0.0.201:3306 [email protected] -N &Jetzt können Sie sich mit 127.0.0.1:3307
mit dem Remote-Server verbinden$ mysql -P3307 -h 127.0.0.1Es funktioniert ähnlich für die Replikation, denken Sie nur daran, 127.0.0.1 für den master_host und 3307 für den master_port
zu verwendenZu guter Letzt können Sie Ihre Replikation mit SSL verschlüsseln. In diesem vorherigen Blogpost wird erläutert, wie dies durchgeführt werden kann und welche Auswirkungen dies auf die Replikationsleistung haben kann.
Wenn Sie sich entschieden haben, die Galera-Replikation über beide Rechenzentren hinweg zu verwenden, gelten die obigen Vorschläge auch hier. Wenn es um SSL geht, haben wir zuvor darüber gebloggt, wie man den Galera-Replikationsverkehr verschlüsselt. Für eine vollständigere Lösung möchten Sie möglicherweise alle Datenbankverbindungen von Client-Anwendungen und jeglicher Verwaltungs-/Überwachungsinfrastruktur verschlüsseln.
Einrichten der neuen Infrastruktur
Sobald Sie Konnektivität haben, müssen Sie mit dem Aufbau der neuen Infrastruktur beginnen. Dafür werden Sie wahrscheinlich xtrabackup oder mariabackup verwenden. Es könnte verlockend sein, die Migration mit dem MySQL-Upgrade zu kombinieren, schließlich richten Sie am neuen Standort eine ganz neue Umgebung ein. Wir würden das nicht empfehlen. Die Migration auf eine neue Infrastruktur ist für sich genommen schon bedeutend genug, sodass die Kombination mit einer anderen größeren Änderung die Komplexität und das Risiko erhöht. Das gilt auch für andere Dinge – Sie wollen Veränderungen Schritt für Schritt angehen. Nur wenn Sie die Dinge einzeln ändern, können Sie die Ergebnisse der Änderungen und ihre Auswirkungen auf Ihre Arbeitslast verstehen. Wenn Sie zu einem bestimmten Zeitpunkt mehr als eine Änderung vorgenommen haben, können Sie nicht sicher sein, welche für eine bestimmte (neue ) Verhalten, das Sie beobachtet haben.
Wenn Sie eine neue MySQL-Instanz im neuen Rechenzentrum eingerichtet und ausgeführt haben, müssen Sie sie vom Knoten im alten Rechenzentrum sklaven, um sicherzustellen, dass die Daten in beiden Rechenzentren synchron bleiben. Dies wird praktisch, wenn Sie sich auf die endgültige Umstellung vorbereiten. Es ist auch eine gute Möglichkeit sicherzustellen, dass die neue Umgebung Ihre Schreiblast bewältigen kann.
Der nächste Schritt wird sein, eine komplette Staging-Infrastruktur am neuen Standort aufzubauen und Tests und Benchmarks durchzuführen. Dies ist ein sehr wichtiger Schritt, der nicht übersprungen werden sollte – das Problem dabei ist, dass Sie als DBA die Kapazität Ihrer Infrastruktur verstehen müssen. Wenn Sie den Anbieter wechseln, ändern sich auch die Dinge. Neue Hardware/VMs sind schneller oder langsamer. Es gibt mehr oder weniger Arbeitsspeicher pro Instanz. Sie müssen noch einmal verstehen, wie Ihre Workload in die Hardware passt, die Sie verwenden werden. Dazu werden Sie wahrscheinlich Percona Playback oder pt-log-player verwenden, um einige der Abfragen aus dem wirklichen Leben auf dem Staging-System wiederzugeben. Sie sollten die Leistung testen und sicherstellen, dass sie auf einem für Sie akzeptablen Niveau liegt. Sie möchten auch alle Standardakzeptanztests durchführen, die Sie auf Ihren neuen Releases durchführen – nur um zu bestätigen, dass alles funktioniert und läuft. Generell sollten alle Anwendungen so gebaut werden, dass sie nicht auf die Hardwarekonfiguration und ein aktuelles Setup angewiesen sind. Aber möglicherweise ist etwas durchgerutscht und Ihre App hängt möglicherweise von einigen der Konfigurationsoptimierungen oder Hardwarelösungen ab, die Sie in der neuen Umgebung nicht haben.
Sobald Sie mit Ihren Tests zufrieden sind, möchten Sie schließlich eine produktionsreife Infrastruktur aufbauen. Nachdem dies erledigt ist, möchten Sie möglicherweise einige schreibgeschützte Tests zur endgültigen Überprüfung ausführen. Dies wäre der letzte Schritt vor der Umstellung.
Umstellung
Nachdem all diese Tests durchgeführt wurden und nachdem die Infrastruktur als produktionsbereit eingestuft wurde, besteht der letzte Schritt darin, den Datenverkehr von der alten Infrastruktur umzuschalten.
Insgesamt gesehen ist dies ein komplexer Prozess, aber wenn wir uns die Datenbankebene ansehen, ist es mehr oder weniger dasselbe wie ein Standard-Failover – etwas, das Sie in der Vergangenheit möglicherweise mehrmals durchgeführt haben. Wir haben es in einem früheren Beitrag ausführlich behandelt, kurz gesagt, die Schritte sind:Stoppen Sie den Datenverkehr, stellen Sie sicher, dass er gestoppt wird, warten Sie, während die Anwendung in das neue Rechenzentrum verschoben wird (DNS-Einträge ändern sich oder was auch immer), führen Sie einige Rauchtests durch, um dies sicherzustellen alles sieht gut aus, geh live, beobachte eine Weile genau.
Diese Umstellung erfordert, wie wir sehen, einige Ausfallzeiten. Das Problem besteht darin, sicherzustellen, dass wir einen konsistenten Status auf der alten und der neuen Website haben. Wenn wir dies ohne Ausfallzeiten tun möchten, müssten wir eine Master-Master-Replikation einrichten. Der Grund dafür ist, dass, wenn wir DNS aktualisieren und Sitzungen von der alten Site auf die neue verschieben, beide Systeme gleichzeitig verwendet werden – bis alle Sitzungen auf die neue Site umgeleitet werden. In der Zwischenzeit müssen alle Änderungen auf der neuen Website auf der alten Website widergespiegelt werden.
Die Verwendung von Galera Cluster, wie in diesem Blogbeitrag beschrieben, kann auch eine Möglichkeit sein, Daten zwischen den beiden Standorten synchron zu halten.
Wir sind uns bewusst, dass dies eine sehr kurze Beschreibung des Datenmigrationsprozesses ist. Hoffentlich reicht es aus, Sie in eine gute Richtung zu weisen und Ihnen dabei zu helfen, herauszufinden, nach welchen zusätzlichen Informationen Sie suchen müssen.
