Follower-Cluster sind eine ScaleGrid-Funktion, mit der Sie zwei unabhängige Datenbanksysteme (des gleichen Typs) synchron halten können. Anders als beim Klonen oder Replizieren können Sie so eine aktive Kopie Ihrer Produktionsdaten zu einem bestimmten Zeitpunkt beibehalten. Dieser zusätzliche Cluster, bekannt als Follower-Cluster, kann für mehrere Anwendungsfälle genutzt werden, einschließlich zum Analysieren, Optimieren und Testen Ihrer Anwendungsleistung für MongoDB, MySQL und PostgreSQL. In diesem Blogbeitrag behandeln wir die drei wichtigsten Szenarien zur Nutzung von Follower-Clustern für Ihre Anwendung.
Wie unterscheiden sich Follower-Cluster von der Replikation?
Im Gegensatz zu einem statischen Klon werden diese Daten nach einem festgelegten Zeitplan importiert, sodass Ihr Follower-Cluster immer mit Ihrem Produktionscluster synchronisiert ist. Hier sind einige wesentliche Unterschiede zur Replikation:
- Sie können steuern, wie oft das Zielsystem von der Quelle synchronisiert – einmal pro Woche, einmal am Tag oder noch seltener. Dies trägt dazu bei, die Belastung des Quellsystems zu verringern.
- Da es sich um zwei unabhängige Systeme handelt, haben Sie viel mehr Flexibilität bei den synchronisierten Daten. Sie können unterschiedliche Benutzeranmeldeinformationen haben und sogar einige Daten basierend auf Sicherheitsanforderungen vom Ziel entfernen (Hinweis:Dies erfordert benutzerseitiges Skripting – es ist keine integrierte Funktion von Follower-Clustern).
- Das „Follower“-System ist beschreibbar, sodass Sie es als Staging-Umgebung verwenden können, um Ihre Anwendungsänderungen zu testen. Dies können Sie auf einem Replikatknoten nicht tun.
Hinweis:ScaleGrid implementiert Follower-Cluster mithilfe von Speicher-Snapshots. Es ist nicht für unsere In-Memory-Datenbankangebote wie Hosting für Redis™* verfügbar.
1. Datenbank-Entwicklungs-/Test-Setup
Das haben wir alle schon erlebt – ein vermeintlich gut getesteter Code wird in der Produktion eingesetzt, und dann bricht die Hölle los. Produktionsworkflows schlagen fehl oder sind so langsam, dass sie praktisch unbrauchbar sind. Ingenieure werden aus ihren Betten geweckt, um einen ausgewachsenen Brandbekämpfungseinsatz zu starten. Ein paar schlaflose Nächte später taucht diese gefürchtete Ursache auf.
Die Anwendung verhält sich bei Produktions- und Engineering-Setups unterschiedlich.
Mit anderen Worten, wir haben es mit „Testdaten“ getestet. Was, wie sich herausstellte, nichts mit den Produktionsdaten zu tun hatte. Überhaupt.
Der naheliegende Weg, diese Situation zu vermeiden, besteht darin, Tests an Ihren Produktionsdaten durchzuführen. Natürlich nicht die eigentliche Produktion – das wird mit der Katastrophe kokettieren. Auf einer geklonten Kopie der Produktionsdaten. Während Bedenken hinsichtlich Datenschutz und Datensicherheit dies in vielen Szenarien undurchführbar machen, ist dies die beste Lösung, sofern die Datenschutzanforderungen dies zulassen. Wir müssen uns nicht mehr darauf verlassen, dass Ingenieure entsprechende Datensätze erstellen – wenn sie Testdaten weitergeben, werden sie Produktionsdaten weitergeben.
Das heißt, bis die Testdaten so weit von der Produktion abweichen, dass sie keine gute Annäherung mehr sind. Und wir sind wieder bei Null.
Hier kommen Follower-Cluster ins Spiel.
Durch die Verwendung von Follower-Clustern können Sie regelmäßig Daten aus Ihrer Produktionsdatenbank in die Entwicklungs-/Testdatenbank importieren. Und da der gesamte Import über Speicher-Snapshots und nicht über einen logischen Dump erfolgt, erfolgt der Vorgang nahezu augenblicklich. Sie können Ihre Importe einmal alle 24 Stunden, einmal pro Woche oder in einer beliebigen Häufigkeit planen, die Ihrem speziellen Szenario entspricht.
Da Ihre Entwicklungs- und QA-Cluster so eingestellt sind, dass sie dem Produktionscluster folgen, können Sie sich beruhigt zurücklehnen. Wenn Ihre Anwendung den Testdatensatz weitergibt, ist sie definitiv für den Einsatz in der Produktion geeignet!
2. Datenanalyse
Wenn Sie als DBA gearbeitet haben, haben Sie wahrscheinlich mit Ihrem Team darüber gesprochen, dass sich die Systemleistung zu bestimmten Zeiten „auf mysteriöse Weise“ verlangsamt. In den meisten Fällen stellt sich heraus, dass der Schuldige ein Analysejob ist, der auf Unmengen von Daten zugreift und am Ende das gesamte System verlangsamt.
Als DBaaS-Anbieter haben wir dieses Gespräch mehrfach mit unseren Kunden geführt. Hier sind die zwei Optionen, die wir normalerweise vorschlagen:
- Wenn der Analysejob auf dem Primär-/Masterserver ausgeführt wird, verschieben Sie ihn auf einen Sekundär-/Replikatserver.
- Wenn der Analysejob bereits auf einem sekundären Knoten ausgeführt wird und der Leistungsabfall nicht akzeptabel ist, empfehlen wir, die Jobs in einen dedizierten Analysecluster zu verschieben.
Mit unserer Follower-Cluster-Funktion ist es sehr einfach, einen Analyse-Cluster mit aktuellen Produktionsdaten auf dem Laufenden zu halten. Sie können einen Follower-Zeitplan erstellen, um die neuesten Daten aus der Produktion zu synchronisieren, kurz bevor Ihr Analysejob beginnt.
Das Beste daran? Die Follower-Synchronisierung führt keine Operationen auf Datenbankebene durch – es stellt lediglich den neuesten Snapshot wieder her! Es gibt also keine Auswirkungen auf Ihren Produktionscluster.
3. Berichterstattung
Ein weiterer häufiger Anwendungsfall, in dem unsere Kunden die Follower-Cluster-Funktion verwenden, ist die Berichterstellung. Berichterstellungsprozesse werden normalerweise selten ausgeführt, greifen jedoch auf große Datenmengen zu und beanspruchen die meisten Ressourcen eines Datenbankclusters. Wenn der Leistungsabfall nicht akzeptabel ist, empfehlen wir unseren Kunden, die Berichterstellungsarbeitslast auf einen neuen Cluster zu verschieben.
Da Berichterstellungsvorgänge selten sind, ziehen es viele unserer Kunden vor, unsere Funktion zum Anhalten/Fortsetzen zu nutzen, um Berichts-Cluster anzuhalten, wenn sie nicht verwendet werden. Dies hilft, Infrastrukturkosten massiv einzusparen. Typischerweise sind Berichts-Cluster auch viel „kleiner“ (weniger CPU/RAM), um die Kosten zu senken.
Nachdem Sie einen Follower-Cluster über unsere Benutzeroberfläche erstellt haben, können Sie diesen Workflow verwenden, um Ihren Berichtsablauf zu automatisieren:
- Verwenden Sie unsere Resume-API, um den Cluster fortzusetzen.
- Warten Sie, bis der Cluster wieder ausgeführt wird (zu diesem Zweck können Sie Ihre Get-Status-API verwenden).
- Lösen Sie bei Bedarf eine Sicherung auf Ihrem Produktionscluster aus (normalerweise können Sie diesen Schritt überspringen, wenn regelmäßige Sicherungen in Ihrer Produktion geplant sind. Wenn Sie jedoch möchten, dass Ihre Berichterstellung auf den neuesten Daten ausgeführt wird, ist dies unerlässlich).
- Warten Sie, bis die Sicherung abgeschlossen ist.
- Lösen Sie einen Synchronisierungsjob auf dem Follower aus – dies findet den neuesten Snapshot auf dem Quellcluster und stellt ihn am Ziel wieder her.
- Warten Sie, bis der Synchronisierungsauftrag abgeschlossen ist.
- Führen Sie Ihre Berichtsaufgaben aus.
- Verwenden Sie unsere Pause-API, um den Cluster bis zu Ihrem nächsten Berichtsauftrag anzuhalten!
Glauben Sie, dass Follower-Cluster für Ihren speziellen Anwendungsfall gut geeignet sind? In unseren Hilfedokumenten erfahren Sie alles darüber, wie Sie Follower-Cluster für MongoDB, MySQL und PostgreSQL bereitstellen und verwalten!
Wenn Sie sich nicht sicher sind, ob Follower-Cluster die richtige Lösung für Ihren Anwendungsfall sind, hinterlassen Sie einen Kommentar oder erreichen Sie uns unter [email protected] – wir besprechen wir gerne, welche Funktion am besten zu Ihren Anforderungen passt.
