Automatisches Failover von Slave-Knoten in der Replikationsarchitektur in MySQL 8.0.23

Ich stehe seit einiger Zeit mit MGR in Kontakt. Mit der Veröffentlichung von MySQL 8.0.23 bietet die auf MySQL Group Replication (MGR) basierende Hochverfügbarkeitsarchitektur neue Architekturideen.

Wie kann der Slave im Notfallwiederherstellungsraum den MGR im Hauptcomputerraum besser unterstützen?

Wie viele Knoten können bei MGR ausfallen?

Dieses Mal werde ich Ihnen basierend auf den beiden oben genannten Fragen kurz einige der Ideen und Funktionen von MGR erläutern.

1. Fehlertoleranz der Anzahl der MySQL Group Relication-Mitglieder

Ich glaube, jeder kennt die obige Tabelle. In Interviews frage ich oft: „Wie viele MGR-Knoten von 4 Knoten können höchstens ausfallen?“ Die meisten Leute antworten: „Höchstens ein Knoten kann ausfallen. Wenn zwei Knoten ausfallen, spaltet sich das Gehirn und das System funktioniert nicht.“

Dann schauen wir uns an, wie MGR damit umgeht. Ist das die Antwort?

1) Wir haben einen 4-Knoten-MGR

Hier ist eine Frage: Dieses Diagramm ist offensichtlich im Einzelmodus, aber der Pfeil ist nicht unidirektional. Ist er falsch gezeichnet?

2) Zu diesem Zeitpunkt stürzt Second-04 plötzlich ab. Was passiert also mit dem MGR-Cluster?

Der Clusterstatus ändert sich:

• Jeder Knoten tauscht zu einem festgelegten Zeitpunkt seine eigenen Informationen aus.
• Wenn keine Informationen vom Knoten Second-04 empfangen werden, warten die anderen Mitglieder 5 Sekunden.
• Während dieser Zeit hat Second-04 definitiv keine Nachrichten gesendet, daher betrachteten die gesunden Mitglieder Second-04 als in einem verdächtigen Zustand befindlich und markierten es als UNERREICHBAR.
• Dann wartet das fehlerfreie Mitglied gemäß dem Parameter „group_replication_member_expel_timeout“ weiter (zu diesem Zeitpunkt befindet sich Second-04 noch im Status „UNREACHABLE“).
• Wenn die Zeit „group_replication_member_expel_timeout“ überschritten wird, schließt das fehlerfreie Mitglied den Knoten Second-04 aus dem Cluster.

Jetzt kommt der Punkt, achten Sie auf die Tafel

In Second-04, wenn nicht ausgewiesen:

Zu diesem Zeitpunkt besteht der Cluster aus (4 Knoten – 3 fehlerfrei – 1 fehlerhaft). Wenn während dieser Zeit ein Knoten ausfällt, wird der Cluster zu (4 Knoten – 2 fehlerfrei – 2 fehlerhaft). Der Cluster erfüllt nicht das Mehrheitsprinzip und jeder Knoten kann nicht geschrieben werden (es sei denn, es wird manuell eingegriffen, um die Cluster-Mitgliederliste zwangsweise anzugeben).

In Sekunde 04, nach dem Rauswurf:

Zu diesem Zeitpunkt ist der Cluster (3 Knoten – 3 fehlerfrei – 0 fehlerhaft). Der 4-Knoten-Cluster degeneriert zu einem 3-Knoten-Cluster fehlerfrei. Zu diesem Zeitpunkt kann im Cluster weiterhin ein Knoten ausfallen und (3 Knoten – 2 fehlerfrei – 1 fehlerhaft) werden.

Ob ein oder zwei Knoten in einem 4-Knoten-Cluster ausfallen können, hängt daher vom Stadium der Clusterverarbeitung ab.

PS:

Lassen Sie uns über das gerade erwähnte Problem sprechen: Dieses Bild ist offensichtlich im Einzelmodus, aber der Pfeil ist nicht unidirektional. Ist es falsch gezeichnet?

Erstens kann im Einzelmodus standardmäßig nicht in den zweiten Knoten geschrieben werden. Dies liegt jedoch nur daran, dass die Super-Read-Only-Einstellung des zweiten Knotens aktiviert ist.

Setzen Sie den Super-Read-Only-Zugriff auf den zweiten Knoten = 0. Der zweite Knoten kann normal beschrieben werden und sich mit anderen Knoten (Primärknoten und anderen zweiten Knoten) synchronisieren. Die Übertragung basiert weiterhin auf dem Paxos-Protokoll.

Einen Zug ausführen: Der zweite Knoten synchronisiert andere Knoten umgekehrt, ohne die Konflikterkennungsphase zu durchlaufen (die theoretische Effizienz ist höher als im Mehrfachschreibmodus). Dies wurde nicht überprüft, Sie können es also studieren, wenn Sie interessiert sind.

2. Asynchrones Verbindungs-Failover

MySQL 8.0.22 führte das Failover für asynchrone Replikationsverbindungen ein. Viele Freunde haben Artikel veröffentlicht, in denen es vorgestellt wurde. Hier werde ich es nur kurz beschreiben:

1) Ein Master und ein Slave im selben Computerraum und ein Slave-Knoten in einem entfernten Computerraum

2) Master fällt aus, Slave-01 wird zum Master und Slave-02 kann keine Verbindung zum ursprünglichen Master herstellen

3) Wenn für Slave-02 die „Konfiguration für asynchrones Verbindungs-Failover“ konfiguriert ist, versucht Slave-02, nachdem er den Ausfall des ursprünglichen Masters erkannt hat, automatisch, eine Replikationsbeziehung mit dem ursprünglichen Slave-01 (neuer Master) gemäß der vordefinierten Konfiguration herzustellen:

Diese Funktion ist sehr gut. Die referenzierten Tools von Drittanbietern (wie MHAs Reparatur von Master-Slave-Beziehungen) können durch native MySQL-Funktionen ersetzt werden.

Aber nachdem ich mit dem Testen fertig war, kamen mir einige Zweifel:

1. Unterstützt das „asynchrone“ Replikations-Failover keine halbsynchrone Architektur? Es kann nicht garantieren, dass keine Daten verloren gehen, und es kann MHA nicht vollständig ersetzen?
Antwort: Tatsächlich unterstützt es eine erweiterte Halbsynchronisierung.

2. Wenn die Masterliste für das Failover vorkonfiguriert werden muss, müssen wir dann bei einer Änderung der Architektur von Computerraum A die Knoten im Computerraum B weiterhin warten?
A: Ja.

3. Wenn Computerraum A MGR ist und der Knoten (Master) von MGR abnormal ist, der Dienst jedoch nicht heruntergefahren ist und darauf zugegriffen werden kann, sollte der Knoten in Computerraum B dann nicht immer verbunden sein?
Antwort: Ja

Dann wurde MySQL 8.0.23 veröffentlicht, das diese Funktionserweiterung brachte:

Slave kann MGR-Cluster unterstützen und MGR-Mitglieder dynamisch identifizieren, um eine Master-Slave-Beziehung herzustellen.

Zum Abschluss noch eine Runde laufen:

1) Zuerst haben wir einen 3-Knoten-MGR-Cluster, Version 8.0.22 (asynchrones Verbindungs-Failover funktioniert auf dem IO-Thread des Slaves, daher ist die Slave-Version 8.0.23)

+----------------------------+----------+--------------+-------------+---------------------+
| jetzt(6) | Mitgliedshost | Mitgliedsstatus | Mitgliedsrolle | VIEW_ID |
+----------------------------+----------+--------------+-------------+---------------------+
| 22.01.2021 13:41:27.902251 | mysql-01 | ONLINE | SEKUNDÄR | 16112906030396799:9 |
| 22.01.2021 13:41:27.902251 | mysql-02 | ONLINE | PRIMARY | 16112906030396799:9 |
| 22.01.2021 13:41:27.902251 | mysql-03 | ONLINE | SEKUNDÄR | 16112906030396799:9 |
+----------------------------+----------+--------------+-------------+---------------------+

2) Anschließend geben wir die „Failover-Liste für Master-Verbindung“ auf dem unabhängigen Slave-Knoten an

Wählen Sie asynchronous_connection_failover_add_managed('ch1', 'Gruppenreplikation', 'aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaa1', 'mysql-02', 3306, '', 80, 60);

Erklären Sie kurz die Parameter:
ch1: Kanalname GroupReplication: ein fest codierter Parameter. Unterstützt derzeit MGR-Cluster aaaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaa1: MGR-Gruppenname (Parameter group_replication_group_name)
mysql-02: Eines der MGR-Mitglieder 80: Die Priorität des primären Knotens (0-100). Wenn mehrere Master mit derselben Priorität vorhanden sind, wird ein Knoten nach dem Zufallsprinzip als Master ausgewählt.
60: Die Priorität des zweiten Knotens (0-100), der grundsätzlich für den Einzelmodus vorbereitet ist

3) Geben Sie die Replikationskanalinformationen für den Slave an

ÄNDERN SIE DIE REPLIKATIONSQUELLE IN SOURCE_USER='rpl_user', SOURCE_PASSWORD='123456', SOURCE_HOST='mysql-02', SOURCE_PORT=3306, SOURCE_RETRY_COUNT=2, SOURCE_CONNECTION_AUTO_FAILOVER=1, SOURCE_AUTO_POSITION=1 für KANAL 'ch1';

4) Starten Sie den Slave und überprüfen Sie die „Connected Transferable List“

Wenn der E/A-Thread nicht aktiviert ist, werden die MGR-Mitglieder nicht automatisch erkannt. Und kopieren Sie den Benutzer

rpl_user muss über ausgewählte Berechtigungen für performance_schema auf dem MGR-Knoten verfügen

Slave starten;
WÄHLEN SIE * AUS performance_schema.replication_asynchronous_connection_failover;
+--------------+----------+------+-------------------+--------+---------------------------------------+
| KANALNAME | HOST | PORT | NETZWERKNAMENSPACE | GEWICHT | VERWALTETER NAME |
+--------------+----------+------+-------------------+--------+---------------------------------------+
| ch1 | mysql-01 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1 |
| ch1 | mysql-02 | 3306 | | 80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1 |
| ch1 | mysql-03 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+---------------------------------------+

5) Dann stoppen wir group_replication in mysql-02 (ohne den Dienst herunterzufahren),

Die Slave-Liste eliminiert automatisch mysql-02 und stellt die Verbindung mit anderen Knoten wieder her – mysql-02 (Primär):

Stoppen Sie die Gruppenreplikation.

-- Sklave:
WÄHLEN SIE * AUS performance_schema.replication_asynchronous_connection_failover;
+--------------+----------+------+-------------------+--------+---------------------------------------+
| KANALNAME | HOST | PORT | NETZWERKNAMENSPACE | GEWICHT | VERWALTETER NAME |
+--------------+----------+------+-------------------+--------+---------------------------------------+
| ch1 | mysql-01 | 3306 | | 80 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1 |
| ch1 | mysql-03 | 3306 | | 60 | aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1 |
+--------------+----------+------+-------------------+--------+---------------------------------------+

Slave-Status anzeigen\G
*************************** 1. Reihe ***************************
        Slave_IO_State: Wartet darauf, dass der Master ein Ereignis sendet
         Master_Host: mysql-01
         Master_Benutzer: rpl_user
         Master_Port: 3306
        Verbindungswiederholung: 60
       Master_Log_File: mybinlog.000003
     Read_Master_Log_Pos: 4904
        Relay_Log_File:mysql-01-relay-bin-ch1.000065
        Relay_Log_Pos: 439
    Relay_Master_Log_File: mybinlog.000003
       Slave_IO_Running: Ja
      Slave_SQL_Running: Ja
      ...

Nun ist die Konfiguration abgeschlossen. Wenn später MGR-Knoten hinzugefügt oder entfernt werden, kann Slave diese Liste automatisch verwalten. Es werden keine weiteren Anwendungsfälle veröffentlicht.

PS:

Wenn Sie die vom Slave hergestellte Verbindung des Masterknotens (Primärknoten) manuell auf einen anderen Knoten (Zweiter Knoten) umstellen möchten, müssen Sie lediglich die „Übertragbare Liste der Replikationsverbindungen“ löschen, die Zweite Priorität neu anpassen und wieder hinzufügen.

-- Konfiguration löschen SELECT asynchronous_connection_failover_delete_managed('ch1', 'aaaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaa1');


-- Fügen Sie die Priorität von „Second“ erneut hinzu und passen Sie sie so an, dass sie höher ist als „Primary“.
Wählen Sie asynchronous_connection_failover_add_managed('ch1', 'Gruppenreplikation', 'aaaaaaaaaaaaaa-aaaa-aaaa-aaaaaaaaa1', 'mysql-03', 3306, '', 60, 80);

Referenzlinks:

https://mysqlhighavailability.com/automatic-asynchronous-replication-connection-failover/

https://my.oschina.net/u/4591256/blog/4813037

https://dev.mysql.com/doc/refman/8.0/en/replication-functions-source-list.html

Dies ist das Ende dieses Artikels über das automatische Failover von Slave-Knoten der Replikationsarchitektur in MySQL 8.0.23. Weitere Informationen zum automatischen Failover von MySQL finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!