So steuern Sie das Replikations-Failover für MySQL und MariaDB

Automatisiertes Failover ist für viele Anwendungen so ziemlich ein Muss – Betriebszeit wird als selbstverständlich angesehen. Es ist ziemlich schwer zu akzeptieren, dass eine Anwendung 20 oder 30 Minuten lang nicht verfügbar ist, weil jemand angerufen werden muss, um sich anzumelden und die Situation zu untersuchen, bevor er etwas unternimmt.

In der realen Welt neigen Replikations-Setups dazu, mit der Zeit zu wachsen und komplex und manchmal chaotisch zu werden. Und es gibt Einschränkungen. Beispielsweise ist nicht jeder Knoten in einem Setup ein guter Master-Kandidat. Vielleicht unterscheidet sich die Hardware und einige der Replikate haben weniger leistungsstarke Hardware, da sie für die Verarbeitung bestimmter Arten von Workloads vorgesehen sind? Vielleicht sind Sie mitten in der Migration auf eine neue MySQL-Version und einige der Slaves wurden bereits aktualisiert? Sie möchten lieber keinen Master in einer neueren Version haben, der auf alte Replikate repliziert, da dies die Replikation unterbrechen kann. Wenn Sie zwei Rechenzentren haben, eines aktiv und eines für die Notfallwiederherstellung, ziehen Sie es möglicherweise vor, Masterkandidaten nur im aktiven Rechenzentrum auszuwählen, um den Master in der Nähe der Anwendungshosts zu halten. Dies sind nur Beispielsituationen, in denen Sie möglicherweise während des Failover-Prozesses manuell eingreifen müssen. Glücklicherweise haben viele Failover-Tools die Möglichkeit, den Prozess mithilfe von Whitelists und Blacklists zu kontrollieren. In diesem Blogbeitrag möchten wir Ihnen einige Beispiele zeigen, wie Sie den Algorithmus von ClusterControl zur Auswahl von Master-Kandidaten beeinflussen können.

Whitelist- und Blacklist-Konfiguration

ClusterControl bietet Ihnen die Möglichkeit, sowohl eine Whitelist als auch eine Blacklist von Replikaten zu definieren. Eine Whitelist ist eine Liste von Replikaten, die Masterkandidaten werden sollen. Wenn keiner von ihnen verfügbar ist (entweder weil sie ausgefallen sind oder fehlerhafte Transaktionen vorliegen oder andere Hindernisse vorliegen, die verhindern, dass einer von ihnen heraufgestuft wird), wird kein Failover durchgeführt. Auf diese Weise können Sie festlegen, welche Hosts verfügbar sind, um Masterkandidat zu werden. Schwarze Listen hingegen definieren, welche Replikate nicht geeignet sind, Meisterkandidat zu werden.

Diese beiden Listen können in der cmon-Konfigurationsdatei für einen bestimmten Cluster definiert werden. Wenn Ihr Cluster beispielsweise die ID „1“ hat, möchten Sie „/etc/cmon.d/cmon_1.cnf“ bearbeiten. Für die Whitelist verwenden Sie die Variable „replication_failover_whitelist“, für die Blacklist eine „replication_failover_blacklist“. Beide akzeptieren eine kommagetrennte Liste von „host:port“.

Betrachten wir die folgende Replikationskonfiguration. Wir haben einen aktiven Master (10.0.0.141), der zwei Replikate (10.0.0.142 und 10.0.0.143) hat, die beide als Zwischenmaster fungieren und jeweils ein Replikat haben (10.0.0.144 und 10.0.0.147). Wir haben auch einen Standby-Master in einem separaten Rechenzentrum (10.0.0.145), der ein Replikat (10.0.0.146) hat. Diese Hosts sollen im Katastrophenfall verwendet werden. Replikate 10.0.0.146 und 10.0.0.147 fungieren als Backup-Hosts. Siehe Screenshot unten.

Da das zweite Rechenzentrum nur für die Notfallwiederherstellung vorgesehen ist, möchten wir nicht, dass einer dieser Hosts zum Master befördert wird. Im schlimmsten Fall greifen wir manuell ein. Die Infrastruktur des zweiten Rechenzentrums ist nicht auf die Größe des Produktionsrechenzentrums skaliert (es gibt drei Replikate weniger im DR-Rechenzentrum), sodass ohnehin manuelle Maßnahmen erforderlich sind, bevor wir einen Host im DR-Rechenzentrum hochstufen können. Wir möchten auch nicht, dass ein Backup-Replikat (10.0.0.147) heraufgestuft wird. Wir wollen auch nicht, dass ein drittes Replikat in der Kette als Master aufgenommen wird (obwohl dies mit GTID möglich wäre).

Whitelist-Konfiguration

Wir können entweder eine Whitelist oder eine Blacklist konfigurieren, um sicherzustellen, dass das Failover nach unseren Wünschen gehandhabt wird. In diesem speziellen Setup kann die Verwendung einer Whitelist besser geeignet sein – wir werden definieren, welche Hosts für das Failover verwendet werden können, und wenn jemand dem Setup einen neuen Host hinzufügt, wird dieser nicht als Master-Kandidat berücksichtigt, bis jemand manuell entscheidet, dass dies der Fall ist OK, um es zu verwenden und zur Whitelist hinzuzufügen. Wenn wir eine schwarze Liste verwenden, könnte das Hinzufügen eines neuen Replikats irgendwo in der Kette bedeuten, dass ein solches Replikat theoretisch automatisch für das Failover verwendet werden könnte, es sei denn, jemand sagt ausdrücklich, dass es nicht verwendet werden kann. Bleiben wir auf der sicheren Seite und definieren eine Whitelist in unserer Cluster-Konfigurationsdatei (in diesem Fall ist es /etc/cmon.d/cmon_1.cnf, da wir nur einen Cluster haben):

replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306

Wir müssen sicherstellen, dass der cmon-Prozess neu gestartet wurde, um die Änderungen zu übernehmen:

service cmon restart

Nehmen wir an, unser Master ist abgestürzt und für ClusterControl nicht erreichbar. Ein Failover-Job wird initiiert:

Die Topologie sieht wie folgt aus:

Wie Sie sehen können, ist der alte Master deaktiviert und ClusterControl wird nicht versuchen, ihn automatisch wiederherzustellen. Es ist Sache des Benutzers, zu überprüfen, was passiert ist, alle Daten zu kopieren, die möglicherweise nicht auf den Masterkandidaten repliziert wurden, und den alten Master neu aufzubauen:

Dann sind es nur noch ein paar Topologieänderungen und wir können die Topologie in den ursprünglichen Zustand bringen, indem wir einfach 10.0.0.141 durch 10.0.0.142 ersetzen:

Blacklist-Konfiguration

Jetzt werden wir sehen, wie die schwarze Liste funktioniert. Wir haben erwähnt, dass dies in unserem Beispiel möglicherweise nicht die beste Option ist, aber wir werden es zur Veranschaulichung versuchen. Wir werden jeden Host außer 10.0.0.141, 10.0.0.142 und 10.0.0.143 auf die schwarze Liste setzen, da dies die Hosts sind, die wir als Master-Kandidaten sehen möchten.

replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306

Wir werden auch den cmon-Prozess neu starten, um Konfigurationsänderungen zu übernehmen:

service cmon restart

Der Failover-Prozess ist ähnlich. Sobald der Master-Absturz erkannt wird, startet ClusterControl erneut einen Failover-Job.

Wenn eine Replik möglicherweise kein guter Master-Kandidat ist

In diesem kurzen Abschnitt möchten wir einige der Fälle ausführlicher besprechen, in denen Sie eine bestimmte Replik möglicherweise nicht zu einem neuen Master befördern möchten. Hoffentlich gibt Ihnen dies eine Vorstellung von den Fällen, in denen Sie möglicherweise eine stärkere manuelle Kontrolle des Failover-Prozesses in Betracht ziehen sollten.

Andere MySQL-Version

Erstens:Wenn Ihr Replikat eine andere MySQL-Version als der Master verwendet, ist es keine gute Idee, es zu bewerben. Generell ist eine neuere Version immer ein No-Go, da die Replikation von der neuen auf die alte MySQL-Version nicht unterstützt wird und möglicherweise nicht richtig funktioniert. Dies ist hauptsächlich für Hauptversionen relevant (z. B. 8.0, die auf 5.7 repliziert wird), aber es empfiehlt sich, dieses Setup ganz zu vermeiden, selbst wenn wir über kleine Versionsunterschiede sprechen (5.7.x+1 -> 5.7.x). Die Replikation von einer niedrigeren auf eine höhere/neuere Version wird unterstützt, da dies ein Muss für den Upgrade-Prozess ist, aber Sie möchten dies dennoch lieber vermeiden (wenn Ihr Master beispielsweise auf 5.7.x+1 ist, möchten Sie ihn lieber nicht ersetzen mit einer Replik auf 5.7.x).

Unterschiedliche Rollen

Sie können Ihren Replikaten unterschiedliche Rollen zuweisen. Sie können eine davon auswählen, die Entwicklern zum Testen ihrer Abfragen in einem Produktionsdataset zur Verfügung stehen soll. Sie können einen davon für die OLAP-Arbeitslast verwenden. Sie können einen davon für Backups verwenden. Egal was es ist, normalerweise möchten Sie eine solche Replik nicht zum Master befördern. All diese zusätzlichen, nicht standardmäßigen Workloads können aufgrund des zusätzlichen Overheads zu Leistungsproblemen führen. Eine gute Wahl für einen Masterkandidaten ist ein Replikat, das „normale“ Last handhabt, mehr oder weniger die gleiche Art von Last wie der aktuelle Master. Sie können dann sicher sein, dass es den Master-Load nach dem Failover handhaben wird, wenn es ihn vorher gehandhabt hat.

Unterschiedliche Hardwarespezifikationen

Wir haben verschiedene Rollen für Replikate erwähnt. Auch unterschiedliche Hardwarespezifikationen sind keine Seltenheit, insbesondere in Verbindung mit unterschiedlichen Rollen. Beispielsweise muss ein Backup-Slave höchstwahrscheinlich nicht so leistungsfähig sein wie eine normale Replik. Entwickler können ihre Abfragen auch auf einer langsameren Datenbank als der Produktionsdatenbank testen (hauptsächlich, weil Sie nicht das gleiche Maß an Parallelität in der Entwicklungs- und Produktionsdatenbank erwarten würden) und beispielsweise die Anzahl der CPU-Kerne reduziert werden kann. Notfallwiederherstellungs-Setups können auch verkleinert werden, wenn ihre Hauptaufgabe darin besteht, mit der Replikation Schritt zu halten, und erwartet wird, dass das DR-Setup skaliert werden muss (sowohl vertikal durch Vergrößern der Instanz als auch horizontal durch Hinzufügen weiterer Replikate). bevor der Datenverkehr dorthin umgeleitet werden kann.

Verzögerte Repliken

Einige der Replikate können sich verzögern – es ist eine sehr gute Möglichkeit, die Wiederherstellungszeit zu verkürzen, wenn Daten verloren gegangen sind, aber es macht sie zu sehr schlechten Master-Kandidaten. Wenn ein Replikat um 30 Minuten verzögert wird, verlieren Sie entweder diese 30 Minuten an Transaktionen oder Sie müssen warten (wahrscheinlich nicht 30 Minuten, da das Replikat höchstwahrscheinlich schneller aufholen kann), bis das Replikat alle verzögerten Transaktionen angewendet hat. Mit ClusterControl können Sie auswählen, ob Sie warten oder sofort ein Failover durchführen möchten, aber dies würde für eine sehr kleine Verzögerung funktionieren - höchstens zehn Sekunden. Wenn das Failover Minuten dauern soll, macht es keinen Sinn, ein solches Replikat zu verwenden, und daher ist es eine gute Idee, es auf die schwarze Liste zu setzen.

Anderes Rechenzentrum

Wir haben reduzierte DR-Setups erwähnt, aber selbst wenn Ihr zweites Rechenzentrum auf die Größe der Produktion skaliert wird, kann es dennoch eine gute Idee sein, die Failover in nur einem einzigen DC zu belassen. Zunächst einmal können sich Ihre aktiven Anwendungshosts im Hauptrechenzentrum befinden, sodass das Verschieben des Masters in einen Standby-DC die Latenz für Schreibabfragen erheblich erhöhen würde. Auch im Falle einer Netzwerkaufteilung möchten Sie diese Situation möglicherweise manuell handhaben. MySQL hat keinen eingebauten Quorum-Mechanismus, daher ist es ziemlich schwierig, Netzwerkverluste zwischen zwei Rechenzentren korrekt (automatisch) zu handhaben.