MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Bereitstellen von MariaDB-Replikation für Hochverfügbarkeit

MariaDB Server bietet asynchrone und synchrone Replikation. Es kann mit einer Multi-Source-Replikation oder mit einem Multi-Master-Setup eingerichtet werden.

Für eine lese- und schreibintensive Anwendung ist ein Master-Slave-Setup üblich, kann sich jedoch je nach dem zugrunde liegenden Stack unterscheiden, der zum Aufbau einer hochverfügbaren Datenbankumgebung erforderlich ist.

Ein Master-Slave-Replikationssetup wird Ihren Anforderungen möglicherweise nicht gerecht, insbesondere in einer Produktionsumgebung. Ein MariaDB-Server allein (Master-Slave-Setup) reicht nicht aus, um Hochverfügbarkeit zu bieten, da er immer noch einen Single Point of Failure (SPOF) hat.

MariaDB hat ein Unternehmensprodukt (MariaDB Platform) eingeführt, um dieses Hochverfügbarkeitsproblem anzugehen. Es enthält verschiedene Komponenten:eine Unternehmensversion von MariaDB, MariaDB ColumnStore, MaxScale und leichtgewichtige MariaDB Connectors. Im Vergleich zu anderen Anbietern mit dem gleichen Angebot an Unternehmenslösungen könnte dies eine kostengünstige Option sein, aber nicht jeder benötigt dieses Maß an Komplexität.

In diesem Blog zeigen wir Ihnen, wie Sie MariaDB Server mit Replikation in einer hochverfügbaren Umgebung verwenden, mit der Option, alle kostenlosen Tools oder unsere kostengünstige Verwaltungssoftware zum Ausführen und Verwenden zu verwenden Überwachen Sie Ihre MariaDB Server-Infrastruktur.

Einrichtung der MariaDB-Hochverfügbarkeitstopologie

Ein übliches Setup für eine Master-Slave-Topologie mit MariaDB Server verwendet einen asynchronen oder synchronen Ansatz mit nur einem Master, der Schreibvorgänge erhält, und repliziert dann seine Änderungen auf die Slaves, genau wie im folgenden Diagramm:

Aber andererseits dient dies keiner Hochverfügbarkeit und hat eine der Punkt des Versagens. Wenn der Master stirbt, funktioniert Ihr Anwendungsclient nicht mehr. Jetzt müssen wir den Stapel hinzufügen, um einen automatischen Failover-Mechanismus zu haben, um SPOF zu vermeiden, und bieten auch einen Lastausgleich zum Aufteilen von Lese- und Schreibvorgängen und im Round-Robin-Modus. Fürs Erste haben wir also die Art der Topologie,

Nun dient diese Topologie mehr Sicherheit in Bezug auf SPOF. MaxScale führt die Lese- und Schreibaufteilung über die Datenbankknoten von Ihrem Master gegenüber den Slaves durch. MaxScale hat einen perfekten Ansatz, wenn es um diese Art von Setup geht. MaxScale hat auch eine eingebaute automatische Erkennung. Unabhängig davon, welche Änderungen am Zustand Ihrer Datenbankknoten auftreten, werden diese erkannt und entsprechend reagiert. MaxScale hat die Verfügbarkeit, um ein Failover oder sogar ein Switchover durchzuführen. Um mehr über den Failover-Mechanismus zu erfahren, lesen Sie unseren vorherigen Blog, der sich mit dem Mechanismus des MariaDB MaxScale-Failovers befasst.

Beachten Sie, dass der MaxScale-Failover-Mechanismus mit MariaDB Monitor auch seine Grenzen hat. Es wird am besten nur für ein Master-Slave-Setup ohne zu kompliziertes Setup angewendet. Das bedeutet, dass ein Master-Master-Setup nicht unterstützt wird. MaxScale hat jedoch noch mehr zu bieten. Es führt nicht nur einen Lastausgleich durch, da es Lese-Schreib-Splits durchführt, es verfügt über einen integrierten SmartRouter, der die Abfrage an den leistungsstärksten Knoten sendet. Obwohl dies nicht die Funktion der Hochverfügbarkeit hinzufügt, hilft es den Knoten, im Datenverkehr stecken zu bleiben, und verhindert, dass bestimmte Datenbankknoten zu wenig Leistung erbringen, was zu Zeitüberschreitungen oder zu einem vollständig nicht verfügbaren Server führen kann, der durch hohe ressourcenintensive Aktivitäten verursacht wird .

Eine Einschränkung bei der Verwendung von MaxScale:Sie verwenden BSL (Business Source LIcense). Möglicherweise müssen Sie die FAQ lesen, bevor Sie diese Software übernehmen.

Eine weitere Option zur Auswahl ist die Verwendung eines bequemeren Ansatzes. Es kann für Sie kosteneffizient sein, sich für die Verwendung von ClusterControl zu entscheiden und Proxys in der Mitte mit HaProxy, MaxScale oder ProxySQL zu haben, wobei letzteres so konfiguriert werden kann, dass es von einer leichten bis zu einer Konfiguration auf Produktionsebene reicht, die das Abfragerouting übernimmt. Abfragefilterung, Firewall oder Sicherheit. Siehe Abbildung unten:

Darüber sitzt jetzt das ClusterControl. ClusterControl ist hochverfügbar, d. h. CMON HA, eingerichtet. Alternativ kann die Proxy-Ebene entweder aus HaProxy ausgewählt werden – einer sehr einfachen Option zur Auswahl, MaxScale, wie zuvor erwähnt, oder ProxySQL, das über einen verfeinerten Satz von Parametern verfügt, wenn Sie mehr Flexibilität und Konfiguration wünschen, ideal für eine hochskalierte Produktionsaufbau. ClusterControl übernimmt die automatische Erkennung in Bezug auf den Gesundheitszustand der Knoten, insbesondere des Masters, der der Hauptknoten ist, um festzustellen, ob ein Failover erforderlich ist oder nicht. Dies kann jetzt autarker sein, verursacht jedoch mehr Kosten aufgrund einer Reihe von Knoten, die zur Implementierung dieses Setups erforderlich sind, und auch der Verwendung von ClusterControl Auto-Failover, das für unsere Vorab- und Unternehmenslizenz gilt. Aber auf der anderen Seite bietet es Ihnen die gesamte Sicherheit und Beobachtbarkeit Ihrer Datenbankinfrastruktur. Im Vergleich zu den verfügbaren Lösungen auf dem globalen Markt handelt es sich eher um eine kostengünstige Unternehmensimplementierung.

Bereitstellen Ihrer MariaDB-Master-Slave-Replikation für Hochverfügbarkeit

Nehmen wir an, Sie haben ein bestehendes Master-Slave-Setup von MariaDB. Für dieses Beispiel verwenden wir ClusterControl mit der kostenlosen Community-Edition, die Sie kostenlos installieren und verwenden können. Es macht Ihre Arbeit einfach und schnell einzurichten. Dazu müssen Sie lediglich Ihren vorhandenen MariaDB-Replikationscluster importieren. Sehen Sie sich unseren vorherigen Blog an, wie Sie MariaDB mit ClusterControl verwalten. Für diesen Blog habe ich zunächst das folgende Setup als meinen MariaDB-Replikationscluster, wie unten gezeigt:

Lassen Sie uns nun MaxScale hier als alternative Lösung von MariaDB Platform verwenden, die ebenfalls bietet eine hohe Verfügbarkeit. Dazu ist es sehr einfach mit ClusterControl zu verwenden, mit nur wenigen Klicks können Sie dann Ihr MaxScale einrichten, das auf Ihrem bestehenden MariaDB-Replikationscluster läuft. Gehen Sie dazu einfach zu Manage → Load Balancer → MaxScale, und Sie können die entsprechenden Werte wie unten gezeigt einrichten und bereitstellen,

Aktivieren oder klicken Sie dann einfach auf die Checkbox-Option, um auszuwählen, welche Server aktiviert werden müssen als Teil Ihrer MaxScale-Überwachung hinzugefügt. Siehe unten,

Angenommen, Sie haben mehr als einen MaxScale-Knoten hinzuzufügen, wiederholen Sie einfach die gleichen Schritte.

Zuletzt richten wir Keepalived ein, um unsere MaxScale-Knoten bei Bedarf immer verfügbar zu halten. Dies geht sehr schnell mit nur einfachen Schritten mit ClusterControl. Auch hier müssen Sie zu Manage → Load Balancer gehen, aber wählen Sie stattdessen Keepalived,

Wie Sie bemerkt haben, habe ich mein Keepalived zusammen mit MaxScale platziert auf demselben Knoten wie mein Slave (192.168.10.30). Wohingegen das zweite (2.) Keepalived auf 192.168.10.40 zusammen mit Maxscale auf demselben Host läuft.

Das Ergebnis der Topologie ist produktionsreif und bietet Ihnen Abfragerouting, Hochverfügbarkeit und Auto-Failover, ausgestattet mit umfassender Überwachung und Beobachtbarkeit mit ClusterControl. Siehe unten,

Fazit

Die alleinige Verwendung der MariaDB-Server-Replikation bietet Ihnen keine hohe Verfügbarkeit. Durch die Erweiterung und Verwendung von Tools von Drittanbietern können Sie Ihren Datenbank-Stack hochverfügbar machen, indem Sie sich nicht nur auf MariaDB-Produkte verlassen oder sogar MariaDB Platform verwenden.

Es gibt Möglichkeiten, dies zu erreichen und kostengünstiger zu verwalten. Es gibt jedoch einen großen Unterschied zu diesen auf dem Markt erhältlichen Lösungen wie ClusterControl, da es Ihnen Geschwindigkeit, weniger Ärger und natürlich die ultimative Beobachtbarkeit mit Echtzeit- und aktuellen Ereignissen bietet, nicht nur die Gesundheit sondern auch die Ereignisse, die in Ihrem Datenbank-Cluster auftreten.