Architekturen für Hochverfügbarkeit von MySQL-Clustern in Compute Engine

Last reviewed 2024-02-21 UTC

In diesem Dokument werden mehrere Architekturen für Hochverfügbarkeit (High Availability, HA) für MySQL-Bereitstellungen in Google Cloud beschrieben. HA ist das Maß für die Ausfallsicherheit eines Systems im Fall eines Infrastrukturausfalls. In diesem Dokument bezieht sich HA auf die Verfügbarkeit von MySQL-Clustern innerhalb einer einzelnen Cloud-Region.

Dieses Dokument richtet sich an Datenbankadministratoren, Cloud-Architekten und DevOps-Entwickler, die erfahren möchten, wie sie die Zuverlässigkeit der MySQL-Datenstufe durch Erhöhung der Betriebszeit des Gesamtsystems steigern können. Dieses Dokument richtet sich an Sie, wenn Sie MySQL in Compute Engine ausführen. Wenn Sie Cloud SQL for MySQL verwenden, ist dieses Dokument nicht für Sie bestimmt.

Für Systeme oder Anwendungen, die zur Verarbeitung von Anfragen oder Transaktionen einen persistenten Status erfordern, muss die Datenpersistenzschicht verfügbar sein, um Anfragen für Datenabfragen oder Mutationen erfolgreich verarbeiten zu können. Wenn die Anwendung mit der Datenstufe interagieren muss, um Anfragen zu bearbeiten, hindert jede Ausfallzeit der Datenstufe die Anwendung daran, die erforderlichen Aufgaben auszuführen.

Abhängig von den Service Level Objectives (SLOs) Ihres Systems benötigen Sie möglicherweise eine Architekturtopologie, die eine höhere Verfügbarkeit erlaubt. Es gibt mehrere Möglichkeiten, HA zu erreichen, aber im Allgemeinen stellen Sie dafür eine redundante Infrastruktur bereit, die Sie Ihrer Anwendung schnell zur Verfügung stellen können.

In diesem Dokument werden folgende Themen behandelt:

  • Definition von Begriffen, die das Verständnis von Datenbankkonzepten der Hochverfügbarkeit unterstützen
  • Erläuterung verschiedener Optionen für HA-MySQL-Topologien
  • Bereitstellung von Kontextinformationen, die für die Bewertung der einzelnen Optionen relevant sind

Terminologie

Es gibt verschiedene gängige Begriffe und Konzepte, die dem Branchenstandard entsprechen und deren Verständnis von Nutzen ist, die aber über den Rahmen dieses Dokuments hinausgehen.

Replikation: Der Prozess, bei dem Schreibtransaktionen (INSERT, UPDATE oder DELETE) zuverlässig erfasst, protokolliert und anschließend seriell auf alle Datenbankknoten in der Topologie angewendet werden.

Quellknoten. Alle Datenbankschreibvorgänge müssen an einen Quellknoten gerichtet werden. Der Quellknoten ermöglicht einen Lesevorgang mit dem aktuellsten Zustand der beibehaltenen Daten.

Replikatknoten: Eine Onlinekopie des Quelldatenbankknotens. Änderungen werden nahezu synchron vom Quellknoten auf Replikatknoten repliziert. Sie können aus Replikatknoten lesen, wobei die Daten aufgrund der Replikationsverzögerung aber etwas verzögert sein können.

Replikationsverzögerung: Ein Zeitmaß, das die Differenz zwischen dem Zeitpunkt ausdrückt, zu dem eine Transaktion auf das Replikat angewendet wird, und dem Zeitpunkt, zu dem sie auf den Quellknoten angewendet wird.

Betriebszeit: Der prozentuale Anteil der Zeit, während der eine Ressource einsatzbereit ist und Anfragen beantworten kann.

Ausfallerkennung: Der Prozess der Identifizierung eines Infrastrukturausfalls.

Failover: Der Prozess des Hochstufens der Sicherungs- oder Standby-Infrastruktur (in diesem Fall des Replikatknotens) zur primären Infrastruktur. Anders gesagt: Während des Failovers wird der Replikatknoten zum Quellknoten.

Recovery Time Objective (RTO): Die aus geschäftlicher Sicht akzeptable Echtzeit, die der Failover-Prozess der Datenstufe erfordern darf.

Fallback: Der Prozess der Reaktivierung des vorherigen Quellknotens nach einem Failover.

Selbstreparatur: Die Fähigkeit eines Systems, Probleme ohne externen, menschlichen Eingriff zu beheben.

Netzwerkpartitionierung: Eine Situation, in der zwei Knoten in einer Topologie, z. B. der Quell- und der Replikatknoten, nicht über das Netzwerk miteinander kommunizieren können.

Split-Brain: Eine Situation, in der zwei Knoten gleichzeitig „glauben“, der Quellknoten zu sein.

Knotengruppe: Eine Reihe von Computing-Ressourcenaufgaben, die einen Dienst bereitstellen. In diesem Dokument ist dieser Dienst die Datenpersistenzstufe.

Witness- oder Quorumknoten: Eine separate Computing-Ressource, die einer Knotengruppe hilft zu bestimmen, was in einer Split-Brain-Situation zu tun ist.

Quell- oder Leader-Auswahl. Der Prozess, über den eine Gruppe peer-sensitiver Knoten (einschließlich Witness-Knoten) bestimmt, welcher Knoten der Quellknoten sein soll.

Knotengruppe: Eine Reihe von Computing-Ressourcenaufgaben, die einen Dienst bereitstellen. In diesem Dokument ist dieser Dienst die Datenpersistenzstufe.

Hot-Standby. Ein Knoten, der eine Kopie eines anderen Quellknotens darstellt und mit minimaler Ausfallzeit zum neuen Quellknoten werden kann.

Mögliche Gründe für die Verwendung einer HA-Architektur

HA-Architekturen bieten einen besseren Schutz vor Ausfällen der Datenstufe. Die bei Ihnen bestehende Toleranz für Ausfallzeiten sowie die Vor- und Nachteile der verschiedenen Architekturen zu kennen, ist äußerst wichtig, wenn es darum geht, die richtige Option für Ihren geschäftlichen Anwendungsfall auszuwählen.

Verwenden Sie eine HA-Topologie, wenn Sie eine erhöhte Betriebszeit auf Datenstufe erreichen möchten, um die Zuverlässigkeitsanforderungen für Ihre Arbeitslasten und Dienste zu erfüllen. Bei Umgebungen, in denen ein gewisses Maß an Ausfallzeiten tolerierbar ist, führt eine HA-Topologie zu unnötigen Kosten und unnötiger Komplexität. Beispielsweise erfordern Entwicklungs- und Testumgebungen nur selten eine hohe Verfügbarkeit der Datenbankstufe.

HA-Anforderungen berücksichtigen

Die Kosten sind ein wichtiger Aspekt, da Sie damit rechnen müssen, dass sich die Kosten für Computing-Infrastruktur und Speicherung mindestens verdoppeln, wenn Sie für Hochverfügbarkeit sorgen. Denken Sie über die folgenden Fragen nach, wenn Sie die möglichen MySQL-HA-Optionen prüfen:

  • Welche Dienste oder Kunden benötigen Ihre Datenstufe?
  • Wie hoch ist Ihr operatives Budget?
  • Wie hoch sind die Kosten für Ihr Unternehmen bei einem Ausfall der Datenpersistenzstufe?
  • Wie automatisiert muss der Prozess sein?
  • Welches Verfügbarkeitsniveau möchten Sie erreichen: 99,5 %, 99,9 % oder 99,99 %?
  • Wie schnell muss ein Failover erfolgen? Welches RTO haben Sie?

Die folgenden Dinge haben einen Einfluss auf die Wiederherstellungszeit und sollten bei der Festlegung Ihres RTO berücksichtigt werden:

  • Ausfallerkennung
  • Bereitschaft der sekundären VM-Instanz (virtuelle Maschine)
  • Speicher-Failover
  • Wiederherstellungszeit für die Datenbank
  • Wiederherstellungszeit für die Anwendung

MySQL-HA-Architekturen

Auf der grundlegendsten Ebene umfasst Hochverfügbarkeit auf der Datenstufe Folgendes:

  • Einen Mechanismus zum Identifizieren eines Ausfalls des Quellknotens.
  • Einen Prozess, um einen Failover durchzuführen, bei dem der Replikatknoten zu einem Quellknoten hochgestuft wird.
  • Einen Prozess zum Ändern des Abfrageroutings, sodass Anwendungsanfragen den neuen Quellknoten erreichen.
  • Optional eine Methode, um zur ursprünglichen Topologie unter Verwendung von Quell- und Replikatknoten zurückzukehren.

In diesem Dokument werden die folgenden drei HA-Architekturen erläutert:

Zusätzlich zur Verringerung der Folgen eines Infrastrukturausfalls kann jede dieser Architekturen dazu beitragen, Ausfallzeiten im unwahrscheinlichen Fall eines Zonenausfalls zu minimieren. Sie verwenden diese Architekturen mit DNS-Änderungen (Domain Name System), um für multiregionale Hochverfügbarkeit zu sorgen und sich damit vor regionalen Dienstunterbrechungen zu schützen. Darauf wird in diesem Dokument jedoch nicht weiter eingegangen.

HA mit regionalen Persistent Disks

Hochverfügbarkeit auf der Datenstufe basiert immer auf einer Art von Datenreplikation. Die einfachste Replikation ist eine, die Sie nicht verwalten müssen.

Mit der Compute Engine-Speicheroption in Form regionaler Persistent Disks können Sie ein Blockspeichergerät bereitstellen, das für eine synchrone Datenreplikation zwischen zwei Zonen in einer Region sorgt. Regionale Persistent Disks stellen eine starke Basis für die Implementierung von HA-Diensten in Compute Engine dar.

Das folgende Diagramm veranschaulicht die Architektur von HA mit regionalen Persistent Disks.

Diagramm: Architektur zur Verwendung von regionalen Persistent Disks zum Erreichen von HA

Wenn die VM-Instanz des Quellknotens aufgrund eines Infrastruktur- oder Zonenausfalls nicht mehr verfügbar ist, können Sie erzwingen, dass die regionale Persistent Disk an eine VM-Instanz in der Sicherungszone in derselben Region angehängt wird.

Dafür müssen Sie einen der folgenden Schritte ausführen:

  • Starten Sie eine weitere VM-Instanz in der Sicherungszone, in der Zugriff auf den freigegebenen regionalen nichtflüchtigen Speicher verfügbar ist.
  • Eine Hot-Standby-VM-Instanz in der Sicherungszone verwalten. Eine Hot-Standby-VM-Instanz ist eine laufende VM-Instanz, die mit der von Ihnen verwendeten Instanz äquivalent ist. Nachdem Sie den regionalen nichtflüchtigen Speicher angehängt haben, können Sie das Datenbankmodul starten.

Wenn der Datendienstausfall sofort erkannt wird, erfolgt das erzwungene Anhängen normalerweise innerhalb von weniger als einer Minute. Das bedeutet, dass ein RTO im Minutenmaßstab erreichbar ist.

Wenn Ihr Unternehmen die zusätzliche Ausfallzeit tolerieren kann, die nötig ist, damit ein Ausfall erkannt und angezeigt werden kann und Sie manuell den Failover durchführen können, braucht der Prozess nicht automatisiert zu werden.

Wenn Ihre RTO-Toleranz niedriger ist, können Sie den Erkennungs- und Failover-Prozess automatisieren. Wenn Sie diese Architektur automatisieren, ist das System komplizierter, da es beim Failover- und Fallback-Prozess mehrere Grenzfälle gibt, die Sie berücksichtigen müssen. Weitere Informationen zu einer vollständig automatisierten Implementierung dieser Architektur finden Sie unter Cloud SQL-Hochverfügbarkeitskonfiguration.

Vorteile

Die Verwendung von regionalen Persistent Disks zum Erreichen von HA bietet aufgrund der folgenden Features einige Vorteile:

  • Diese Architektur bietet gleichzeitig Schutz vor verschiedenen Ausfallarten: Ausfall der Serverinfrastruktur der primären Zone, Verschlechterung des Blockspeichers einer einzelnen Zone, Ausfall einer ganzen Zone.
  • Eine Replikation in der Anwendungs- oder Datenbankschicht ist nicht erforderlich, da regionale Persistent Disks eine kontinuierliche und synchrone Datenreplikation auf Blockebene bieten, die vollständig von Google Cloud verwaltet wird. Eine regionale Persistent Disk erkennt automatisch Fehler und Verzögerungen, wechselt den Replikationsmodus und aktualisiert Daten, die in nur einer Zone repliziert wurden.
  • Bei Speicherproblemen in einer primären Zone führt eine regionale Persistent Disk automatisch Lesevorgänge aus der sekundären Zone durch. Dieser Vorgang kann zu einer höheren Leselatenz führen, aber Ihre Anwendung funktioniert ohne manuelle Eingriffe weiter.

Hinweise

Die Grenzen dieser Architektur beruhen darauf, dass diese Topologie auf einer einzelnen Region basiert, sowie auf einigen der folgenden inhärenten Beschränkungen regionaler Persistent Disks:

  • Die regionale Persistent Disk kann nur für eine einzige Datenbank bereitgestellt werden. Selbst wenn die VM-Instanz in der Standby-Datenbank ausgeführt wird, kann diese Instanz nicht für Datenbank-Lesevorgänge verwendet werden.
  • Die dieser Architektur zugrunde liegende Technologie ermöglicht nur die Replikation zwischen Zonen in derselben Region. Daher ist ein regionaler Failover nicht möglich, wenn nur diese Architektur verwendet wird.
  • Der Schreibdurchsatz der regionalen Persistent Disk wird im Vergleich zu zonalen Persistent Disks halbiert. Achten Sie darauf, dass die Durchsatzlimits innerhalb Ihrer erforderlichen Toleranz liegen.
  • Die Schreiblatenz der regionalen Persistent Disk ist etwas höher als jene der zonalen Persistent Disk. Wir empfehlen Ihnen, Ihre Arbeitslast daraufhin zu testen, ob die Schreibleistung Ihre Anforderungen erfüllt.
  • Bei einem Ausfall und der daraus resultierenden Umstellung müssen Sie erzwingen, dass die regionale Persistent Disk an die Standby-Zonen-VM angehängt wird. Das erzwungene Anhängen wird normalerweise innerhalb von weniger als einer Minute durchgeführt. Daher müssen Sie diese Zeit bei der Bewertung Ihres RTO berücksichtigen.
  • Bei der RTO-Kalkulation muss die Zeit berücksichtigt werden, die für das erzwungene Anhängen der regionalen Persistent Disk und für das Erkennen des im "Hot"-Verfahren angehängten Laufwerks durch das VM-Dateisystem erforderlich ist.

HA mit Hot-Standby- und Witness-Knoten

Wenn Sie einen automatischen Failover wünschen, ist eine andere Architektur erforderlich. Eine Möglichkeit besteht darin, eine Gruppe mit mindestens zwei Datenbankknoten bereitzustellen, die asynchrone Replikation der Datenbank zu konfigurieren und Witness-Knoten zu starten, um dafür zu sorgen, dass während der Wahl des Quellknotens ein Quorum erreicht werden kann.

Der Quelldatenbankknoten verarbeitet Schreibtransaktionen und bedient Leseabfragen. Bei der Datenbankreplikation werden Änderungen zum Online-Hot-Standby-Replikatknoten übertragen.

Da der Witness-Knoten eine kleine virtuelle Maschine sein kann, ist dies eine kostengünstige Methode, um dafür zu sorgen, dass die Mehrheit einer Gruppe für die Wahl des Quellknotens verfügbar ist.

Gruppenknoten bewerten fortlaufend den Status der anderen Gruppenknoten. Die Signale, die diese Statusprüfungen alle paar Sekunden verarbeiten, werden als "Heartbeats" bezeichnet, da sie dafür verwendet werden, den Zustand der anderen Gruppenknoten zu bewerten. Es ist wichtig, den Zustand von Datenbankknoten zügig zu bewerten, da ein fehlerhafter Quelldatenbankknoten schnell erkannt werden muss, damit ein Failover zum Hot-Standby-Knoten initiiert werden kann.

Das Quorum der Knotengruppe wird anhand der Anzahl der abstimmenden Elemente bestimmt, die Teil der aktiven Clustermitgliedschaft sein müssen, damit dieser Cluster ordnungsgemäß gestartet oder weiter ausgeführt werden kann. Damit eine Knotengruppe bei der Wahl eines Quelldatenbankknotens ein Quorum erreichen kann, muss die Mehrheit der Knoten in der Gruppe aktiv sein. Als Schutz vor einer Split-Brain-Situation sorgt die Mehrheitsanforderung dafür, dass im Fall einer Netzwerkpartitionierung zwei Abstimmungsgruppen nicht gleichzeitig genügend Knoten zum Abstimmen haben können.

Eine Gruppenmehrheit besteht aus (n+1)/2 Knoten, wobei n die Gesamtzahl der Knoten in der Gruppe ist. Wenn eine Gruppe z. B. drei Knoten enthält, müssen für die Wahl des Quellknotens mindestens zwei Knoten einsatzbereit sein. Wenn eine Gruppe fünf Knoten enthält, sind mindestens drei Knoten erforderlich.

Gruppen enthalten eine ungerade Anzahl von Knoten für den Fall, dass eine Netzwerkpartitionierung besteht und die Kommunikation zwischen Untergruppen der Knotengruppe verhindert. Wenn die Gruppengröße gerade ist, ist die Wahrscheinlichkeit höher, dass keine der Untergruppen die Mehrheit bilden kann. Wenn die Gruppengröße ungerade ist, ist es wahrscheinlicher, dass eine der Untergruppen oder keine Gruppe eine Mehrheit bildet.

Im folgenden Diagramm wird eine fehlerfreie Knotengruppe mit einer beeinträchtigten Knotengruppe verglichen.

Diagramm: Architektur zum Vergleich einer fehlerfreien Knotengruppe mit einer beeinträchtigten Knotengruppe

Im Diagramm sind zwei Knotengruppen zu sehen: eine voll funktionsfähige Knotengruppe und eine beeinträchtigte Knotengruppe. Die voll funktionsfähige, fehlerfreie Knotengruppe hat drei Gruppenmitglieder. In diesem Zustand erfüllen der Quell- und der Replikatdatenbankknoten ihren Zweck. Das erforderliche Quorum für diese Knotengruppe beträgt zwei Knoten.

Die beeinträchtigte Knotengruppe befindet sich in einem Zustand, in dem der Quellknoten aufgrund eines Infrastrukturausfalls keine Heartbeats mehr sendet. Dieser Zustand kann durch den Ausfall der Instanz des Quelldatenbankknotens hervorgerufen werden. Es kann aber auch sein, dass der Quellknoten immer noch ausgeführt wird. Es ist auch möglich, dass eine Netzwerkpartitionierung die Kommunikation zwischen dem Quellknoten und den anderen Knoten der Gruppe verhindert.

Unabhängig von der Ursache ist das Ergebnis, dass sowohl der Replikat- als auch der Witness-Knoten feststellen, dass der Quellknoten nicht mehr fehlerfrei ist. Die Gruppenmehrheit führt jetzt die Wahl des Quellknotens durch, stellt dabei fest, dass der Hot-Standby-Knoten zum Quellknoten hochgestuft werden sollte, und initiiert einen Failover.

Das folgende Diagramm zeigt die Datenbanktransaktion, die Replikation und den Heartbeat-Fluss in der Witness-Knotenarchitektur.

Diagramm: Architektur der Verwendung von Hot-Standby- und Witness-Knoten zum Erreichen von HA

Im obigen Diagramm stützt sich diese HA-Architektur darauf, dass der Hot-Standby-Replikatknoten bei einem Failover schnell mit der Verarbeitung von Produktionsschreibvorgängen beginnt. Die Funktionsweise des Failovers – z. B. das Hochstufen zum Quellknoten – wird von den Datenbankknoten in der Gruppe durchgeführt.

Ziehen Sie zum Implementieren dieser Architektur die folgenden beiden Projekte in Betracht:

Vorteile

Die Hot-Standby-Architektur besteht nur aus wenigen Komponenten, ist leicht zu implementieren und bietet verschiedene Vorteile:

  • Mit nur einem zusätzlichen, kostengünstigen Witness-Knoten steht ein vollständig automatisierter Failover zur Verfügung.
  • Diese Architektur kann einen langfristigen Infrastrukturausfall ebenso leicht wie einen ganz kurzen Ausfall (z. B. aufgrund eines Systemneustarts) abfangen.
  • Es wird multiregionale Hochverfügbarkeit mit einer gewissen Replikationslatenz bereitgestellt.

Hinweise

Der Failover erfolgt automatisch. Die folgenden operativen Aufgaben bleiben jedoch bestehen:

  • Sie verwalten die Replikation zwischen dem Quell- und dem Replikatknoten.
  • Sie verwalten die Witness-Knoten.
  • Sie müssen mit einem Load-Balancer das Verbindungsrouting einrichten und verwalten.
  • Wenn Sie Lesevorgänge zum Replikatknoten leiten möchten, müssen Sie dafür Änderungen an der Anwendungslogik vornehmen. Darauf wird in diesem Dokument jedoch nicht weiter eingegangen.

HA mit Orchestrator und ProxySQL

Wenn Sie die Open-Source-Komponenten Orchestrator und ProxySQL miteinander kombinieren, erhalten Sie eine Architektur, die Ausfälle erkennen und für Traffic automatisch den Failover von einem betroffenen Quellknoten zu einem neu hochgestuften, fehlerfreien Replikatknoten durchführen kann.

Außerdem können Sie Abfragen transparent an die entsprechenden Lese- bzw. Lese- und Schreibknoten leiten, um die Steady-State-Leistung der Datenstufe zu verbessern.

Orchestrator ist ein Open-Source-MySQL-Replikationstopologiemanager und eine Failover-Lösung. Mit der Software lassen sich komplexe Replikationstopologien erkennen, abfragen und refaktorieren. Außerdem ermöglicht sie eine zuverlässige Ausfallerkennung, eine intelligente Wiederherstellung sowie das Hochstufen.

ProxySQL ist ein hochverfügbarer, Datenbankprotokoll-sensitiver Open-Source-Hochleistungs-Proxy für MySQL. ProxySQL lässt sich auf Millionen von Verbindungen auf Hunderttausenden von Backend-Servern skalieren.

Das folgende Diagramm zeigt die kombinierte Architektur von Orchestrator und ProxySQL.

Diagramm: Architektur mit Orchestrator und ProxySQL zum Erreichen von HA

In dieser Architektur wird, wie im obigen Diagramm dargestellt, der datenbankgebundene Traffic durch einen internen Load-Balancer zu redundanten ProxySQL-Instanzen geleitet. Diese Instanzen leiten Traffic je nach ProxySQL-Konfiguration zu einer Datenbankinstanz, die Schreib- oder Lesevorgänge ausführen kann.

Orchestrator führt die folgenden Schritte zur Ausfallerkennung und Wiederherstellung durch:

  1. Orchestrator stellt fest, dass der Quelldatenbankknoten nicht verfügbar ist.
  2. Alle Replikatknoten werden abgefragt, um eine zweite Meinung zum Status des Quellknotens einzuholen.
  3. Wenn die Replikate übereinstimmend bestätigen, dass der Quellknoten nicht verfügbar ist, wird der Failover fortgesetzt.
  4. Gemäß der Topologie wird der hochgestufte Knoten während des Failovers zum neuen Quellknoten.
  5. Wenn der Failover abgeschlossen ist, trägt Orchestrator dazu bei, dass gemäß der Topologie die richtige Anzahl neuer Replikationsknoten bereitgestellt wird.

Eine fortlaufende Replikation zwischen der Quelldatenbank in Zone A und den Datenbankreplikaten in alternativen Zonen sorgt dafür, dass die Replikate über alle an die Quelldatenbank geleiteten Schreibvorgänge auf dem Laufenden sind. Orchestrator prüft den Zustand der Quelldatenbank und der Replikatdatenbanken durch kontinuierliches Senden von Heartbeats. Der Orchestrator-Anwendungsstatus wird in einer separaten Cloud SQL-Datenbank gespeichert. Wenn Änderungen an der Topologie erforderlich sind, kann Orchestrator auch Befehle an die Datenbanken senden.

Sobald der Failover abgeschlossen ist, leitet ProxySQL den Traffic ordnungsgemäß an die neuen Quell- und Replikatknoten weiter. Dienste greifen weiter über die IP-Adresse des Load-Balancers auf die Datenstufe zu. Die virtuelle IP-Adresse wird nahtlos vom vorherigen Quellknoten auf den neuen Quellknoten umgestellt.

Vorteile

Die Architekturkomponenten und die Automatisierung bieten folgende Vorteile:

  • Die in dieser Architektur verwendete Software bietet verschiedene Beobachtbarkeitsfeatures, unter anderem Grafiken zu Replikationstopologien sowie Sichtbarkeit des Abfragetraffics.
  • ProxySQL und Orchestrator stimmen sich miteinander ab, um für eine automatische Replikathochstufung und einen automatischen Failover zu sorgen.
  • Die Richtlinie für die Replikathochstufung ist vollständig konfigurierbar. Im Unterschied zu anderen HA-Konfigurationen können Sie bei einem Failover einen bestimmten Replikatknoten für das Hochstufen zum Quellknoten auswählen.
  • Nach einem Failover werden entsprechend der Topologie deklarativ neue Replikate bereitgestellt.
  • ProxySQL bietet den zusätzlichen Vorteil eines Load Balancing, da es Lese- und Schreibanfragen gemäß den konfigurierten Richtlinien transparent zu den entsprechenden Replikat- und Quellknoten leitet.

Hinweise

Diese Architektur erhöht die operative Verantwortung und verursacht aus folgenden Gründen zusätzliche Hosting-Kosten:

  • Sowohl Orchestrator als auch ProxySQL müssen bereitgestellt und verwaltet werden.
  • Orchestrator benötigt eine separate Datenbank zum Verwalten des Status.
  • Sowohl Orchestrator als auch ProxySQL müssen für HA eingerichtet sein. Dadurch sind die Konfiguration und die Bereitstellung komplexer.

Darüber hinaus unterstützt Orchestrator keine Replikationen aus mehreren Quellen, unterstützt nicht alle Arten paralleler Replikation und kann nicht mit Clustering-Software wie Galera oder Percona XtraDB kombiniert werden. Weitere Informationen zu den aktuellen Beschränkungen finden Sie in den FAQ zu Orchestrator.

Nächste Schritte