Cloud-Notfallwiederherstellung für MariaDB und MySQL

MySQL hat eine lange Tradition in der geografischen Replikation. Die Verteilung von Clustern auf entfernte Rechenzentren reduziert die Auswirkungen der geografischen Latenz, indem Daten näher an den Benutzer gebracht werden. Es bietet auch eine Fähigkeit zur Notfallwiederherstellung. Aufgrund der erheblichen Kosten für das Duplizieren von Hardware an einem separaten Standort konnten sich dies in der Vergangenheit nicht viele Unternehmen leisten. Ein weiterer Kostenfaktor sind qualifizierte Mitarbeiter, die in der Lage sind, eine anspruchsvolle Umgebung mit mehreren Rechenzentren zu entwerfen, zu implementieren und zu warten.

Mit der Cloud- und DevOps-Automatisierungsrevolution war es nie einfacher, ein verteiltes Rechenzentrum für die Massen zu haben. Cloud-Anbieter erweitern ihr Leistungsspektrum zu einem besseren Preis. Man kann Cloud-übergreifende, hybride Umgebungen mit weltweit verteilten Daten aufbauen. Man kann flexible und skalierbare DR-Pläne erstellen, um eine breite Palette von Störungsszenarien anzugehen. In einigen Fällen kann dies nur ein extern gespeichertes Backup sein. In anderen Fällen kann es sich um eine 1-zu-1-Kopie einer Produktionsumgebung handeln, die woanders läuft.

In diesem Blog werden wir uns einige dieser Fälle ansehen und gängige Szenarien ansprechen.

Speichern von Backups in der Cloud

Ein DR-Plan ist ein allgemeiner Begriff, der einen Prozess zur Wiederherstellung von gestörten IT-Systemen und anderen kritischen Ressourcen beschreibt, die ein Unternehmen verwendet. Backup ist die primäre Methode, um dies zu erreichen. Wenn sich ein Backup im selben Rechenzentrum wie Ihre Produktionsserver befindet, riskieren Sie, dass alle Daten gelöscht werden, falls Sie dieses Rechenzentrum verlieren. Um dies zu vermeiden, sollten Sie über die Richtlinie verfügen, eine Kopie an einem anderen physischen Ort zu erstellen. Es ist immer noch eine gute Praxis, eine Sicherung auf der Festplatte zu speichern, um die für die Wiederherstellung benötigte Zeit zu verkürzen. In den meisten Fällen werden Sie Ihr primäres Backup im selben Rechenzentrum aufbewahren (um die Wiederherstellungszeit zu minimieren), aber Sie sollten auch ein Backup haben, das verwendet werden kann, um Geschäftsabläufe wiederherzustellen, wenn das primäre Rechenzentrum ausgefallen ist.

ClusterControl ermöglicht eine nahtlose Integration zwischen Ihrer Datenbankumgebung und der Cloud. Es bietet Optionen für die Migration von Daten in die Cloud. Wir bieten eine vollständige Kombination von Datenbanksicherungen für Amazon Web Services (AWS), Google Cloud Services oder Microsoft Azure. Backups können jetzt direkt von Ihrem Cloud-Anbieter Ihrer Wahl ausgeführt, geplant, heruntergeladen und wiederhergestellt werden. Diese Fähigkeit bietet erhöhte Redundanz, bessere Disaster-Recovery-Optionen und Vorteile in Bezug auf Leistung und Kosteneinsparungen.

Der erste Schritt zur Einrichtung von "Rechenzentrumsausfall - sicheres Backup" besteht darin, Anmeldeinformationen für Ihren Cloud-Betreiber bereitzustellen. Hier können Sie zwischen mehreren Anbietern wählen. Werfen wir einen Blick auf den Prozess, der für den beliebtesten Cloud-Betreiber – AWS – eingerichtet wurde.

Sie benötigen lediglich die AWS-Schlüssel-ID und das Geheimnis für die Region, in der Sie Ihr Backup speichern möchten. Sie können dies über die AWS-Konsole abrufen. Sie können ein paar Schritte befolgen, um es zu erhalten.

1. Verwenden Sie die E-Mail-Adresse und das Passwort Ihres AWS-Kontos, um sich als Root-Benutzer des AWS-Kontos bei der AWS-Managementkonsole anzumelden.
2. Wählen Sie auf der IAM-Dashboard-Seite Ihren Kontonamen in der Navigationsleiste und dann Meine Sicherheitsanmeldeinformationen aus .
3. Wenn Sie eine Warnung zum Zugriff auf die Sicherheitsanmeldeinformationen für Ihr AWS-Konto sehen, wählen Sie Weiter zu Sicherheitsanmeldeinformationen .
4. Erweitern Sie den Abschnitt Zugriffsschlüssel (Zugriffsschlüssel-ID und geheimer Zugriffsschlüssel).
5. Wählen Sie Neuen Zugriffsschlüssel erstellen . Wählen Sie dann Schlüsseldatei herunterladen um die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel in einer Datei auf Ihrem Computer zu speichern. Nachdem Sie das Dialogfeld geschlossen haben, können Sie diesen geheimen Zugriffsschlüssel nicht erneut abrufen.

Wenn alles eingestellt ist, können Sie Ihren Backup-Zeitplan anpassen und die Backup-to-Cloud-Option aktivieren. Stellen Sie sicher, dass Sie die Datenkomprimierung aktivieren, um den Netzwerkverkehr zu reduzieren. Dadurch werden Backups kleiner und die für das Hochladen benötigte Zeit minimiert. Eine weitere bewährte Methode besteht darin, das Backup zu verschlüsseln. ClusterControl erstellt automatisch einen Schlüssel und verwendet ihn, wenn Sie sich entscheiden, ihn wiederherzustellen. Erweiterte Backup-Richtlinien sollten unterschiedliche Aufbewahrungszeiten für Backups haben, die auf Servern im selben Rechenzentrum gespeichert sind, und für Backups, die an einem anderen physischen Ort gespeichert sind. Sie sollten einen längeren Aufbewahrungszeitraum für Cloud-basierte Backups und einen kürzeren Zeitraum für Backups festlegen, die in der Nähe der Produktionsumgebung gespeichert werden, da die Wahrscheinlichkeit einer Wiederherstellung mit der Lebensdauer des Backups sinkt.

Erweitern Sie Ihren Cluster mit asynchroner Replikation

Galera mit asynchroner Replikation kann eine hervorragende Lösung sein, um einen aktiven DR-Knoten in einem entfernten Rechenzentrum aufzubauen. Es gibt einige gute Gründe, einen asynchronen Slave an ein Galera-Cluster anzuschließen. Abfragen vom Typ OLAP mit langer Laufzeit auf einem Galera-Knoten können einen ganzen Cluster verlangsamen. Mit der Option zur verzögerten Anwendung kann die verzögerte Replikation Sie vor menschlichen Fehlern bewahren, sodass all diese goldenen Eingaben nicht sofort auf Ihren Backup-Knoten angewendet werden.

In ClusterControl erfolgt die Erweiterung einer Galera-Knotengruppe mit asynchroner Replikation in einem einzigen Seitenassistenten. Sie müssen die notwendigen Informationen über Ihren zukünftigen oder bestehenden Slave-Server bereitstellen. Der Slave wird aus einem vorhandenen Backup oder einem frisch gestreamten XtraBackup vom Master zum Slave eingerichtet.

Load Balancer in Multi-Datacenter

Load Balancer sind eine entscheidende Komponente für die Hochverfügbarkeit von MySQL- und MariaDB-Datenbanken. Es reicht nicht aus, einen Cluster zu haben, der sich über mehrere Rechenzentren erstreckt. Sie benötigen weiterhin Ihre Dienste, um darauf zugreifen zu können. Ein Ausfall eines Load Balancers, der in einem Rechenzentrum verfügbar ist, macht Ihre gesamte Umgebung unerreichbar.

Eine der gängigen Methoden, um die Komplexität der Datenbankschicht vor einer Anwendung zu verbergen, ist die Verwendung eines Proxys. Proxys fungieren als Einstiegspunkt zu den Datenbanken, sie verfolgen den Zustand der Datenbankknoten und sollten den Datenverkehr immer nur zu den verfügbaren Knoten leiten. ClusterControl erleichtert die Bereitstellung und Konfiguration mehrerer verschiedener Lastausgleichstechnologien für MySQL und MariaDB, einschließlich ProxySQL, HAProxy, mit einer grafischen Point-and-Click-Oberfläche.

Es ermöglicht auch, diese Komponente überflüssig zu machen, indem Keepalived darüber hinzugefügt wird. Um zu verhindern, dass Ihre Load Balancer ein Single Point of Failure sind, würde man zwei identische (eine aktive und eine in einem anderen DC als Standby) HAProxy-, ProxySQL- oder MariaDB Maxscale-Instanzen einrichten und Keepalived verwenden, um das Virtual Router Redundancy Protocol (VRRP) dazwischen auszuführen Sie. VRRP stellt dem aktiven Load Balancer eine virtuelle IP-Adresse bereit und überträgt die virtuelle IP im Fehlerfall an den Standby-HAProxy. Es ist nahtlos, da die beiden Proxy-Instanzen keinen gemeinsamen Zustand benötigen.

Natürlich gibt es viele Dinge zu beachten, um Ihre Datenbanken immun gegen Rechenzentrumsausfälle zu machen.
Mit der richtigen Planung und Automatisierung wird es funktionieren! Viel Spaß beim Clustern!