In diesem Abschnitt wird beschrieben, wie Sie die Einstellungen der Gruppenreplikation aktualisieren. Die grundlegenden Schritte zum Aktualisieren von Gruppenmitgliedern sind dieselben wie die Schritte zum Aktualisieren einer einzelnen Instanz. In Bezug auf die Aktualisierungsmethode können Sie speziell ein In-situ-Upgrade (mit dem Befehl mysql_upgrade zum Aktualisieren des Datenwörterbuchs basierend auf der ursprünglichen Datendatei) oder ein logisches Upgrade (Erstellen einer neuen Serverversion im Voraus) auswählen. Die Daten in der alten Version werden logisch exportiert und dann in die neue Version importiert. Dies hängt von der in der Gruppe gespeicherten Datenmenge ab. Im Allgemeinen ist ein direktes Upgrade schneller, daher wird empfohlen, für ein Upgrade ein direktes Upgrade zu verwenden.
Während des Online-Upgrades einer Gruppe muss für die Mitglieder der Gruppe ein fortlaufendes Upgrade (Aktualisierung nacheinander) durchgeführt werden, um die Verfügbarkeit der Gruppe zu maximieren (soweit dies möglich ist, um die Verfügbarkeit der Gruppe sicherzustellen). Daher kann es erforderlich sein, gleichzeitig verschiedene MySQL in einer Gruppe auszuführen Mitglied der Serverversion. Es gibt einige Kompatibilitätsstrategien, wenn eine Gruppe Mitglieder verschiedener Versionen enthält, mit denen Mitglieder, die während des Aktualisierungsprozesses verschiedene Versionen von MySQL in derselben Gruppe ausführen, sicher kombiniert werden können. Darüber hinaus können diese Strategien die Reihenfolge beeinflussen, in der Mitglieder der Upgrade-Gruppe befördert werden. Weitere Informationen finden Sie unter "7.1 Kompatible Mitglieder verschiedener Versionen in einer Gruppe".
Wenn die Gruppe offline aktualisiert werden kann, finden Sie Informationen zum jeweiligen Aktualisierungsprozess unter "7.2. Offline-Aktualisierung der Gruppenreplikation". Wenn Sie die Gruppe online aktualisieren müssen (normalerweise erfordert die Produktionsumgebung ein Online-Upgrade), finden Sie unter "7.3. Online-Aktualisierung der Gruppenreplikation" Informationen zu den verschiedenen Methoden zum Aktualisieren der Gruppe mit minimaler Ausfallzeit.
7.1. Kompatibel mit Mitgliedern verschiedener Versionen in einer Gruppe
Die Gruppenreplikation wird versioniert gemäß der Version von MySQL Server, die an das MGR-Plugin gebunden ist. Wenn beispielsweise ein Mitglied in MySQL Version 5.7.26 ausgeführt wird, ist dies die Version des MGR-Plugins. Verwenden Sie die folgende Anweisung, um die MySQL Server-Version in den Gruppenmitgliedern zu überprüfen:
root@localhost : (none):35: > SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| MEMBER_HOST | MEMBER_PORT | MEMBER_VERSION |
+-------------+-------------+----------------+
| node2 | 3306 | 8.0.17 |
| node3 | 3306 | 8.0.17 |
| node1 | 3306 | 8.0.17 |
+-------------+-------------+----------------+
3 rows in set (0.01 sec)
Um die beste Kompatibilität und Leistung zu erzielen, wird allen Mitgliedern der Gruppe empfohlen, dieselbe Version von MySQL Server auszuführen. Außerdem wird empfohlen, dieselbe Version des Kommunikationsprotokolls für die Gruppenreplikation auszuführen. Um jedoch die Verfügbarkeit der Gruppe während des Online-Upgrades der Gruppe zu maximieren, müssen möglicherweise gleichzeitig Mitglieder verschiedener MySQL Server-Versionen ausgeführt werden. Da einige Funktionen zwischen verschiedenen MySQL-Versionen unterschiedlich sein können (zum Beispiel: Die neuere Version unterstützt möglicherweise einige neue Funktionen, die alte Version jedoch nicht. Einige Funktionen, die in der älteren Version unterstützt werden, werden in der neueren Version gelöscht.) In diesem Fall kann es zu Inkompatibilitätsproblemen zwischen der alten und der neuen Version kommen. Wenn Sie in diesem Fall verschiedene Versionen von MySQL Server in einer Gruppe konfigurieren, kann dies dazu führen, dass Mitglieder, die auf veraltete Funktionen angewiesen sind, fehlschlagen. Außerdem können Probleme mit älteren Versionen auftreten, die in der neuen Version keine neuen Funktionen unterstützen.
Um diese Probleme zu vermeiden, unterstützt die Gruppenreplikation einige Kompatibilitätsstrategien, um eine Gruppe von Gruppenmitgliedern, die auf verschiedenen MySQL Server-Versionen ausgeführt werden, sicher und kompatibel zu machen. Gruppenmitglieder wenden diese Richtlinien an, um zu entscheiden, ob sie der Gruppe normal beitreten oder der Gruppe im schreibgeschützten Modus beitreten oder nicht, je nachdem, welche Auswahl die Sicherheit der Vorgänge zwischen dem neu hinzugefügten Server und den vorhandenen Mitgliedern der Gruppe gewährleisten kann. Wenn Sie ein fortlaufendes Upgrade für eine Gruppe durchführen, muss jedes Mitglied zuerst die Gruppe verlassen, dann auf die neue Version aktualisieren und dann mit der neuen Version erneut der Gruppe beitreten. Zu diesem Zeitpunkt müssen die Mitglieder in der Gruppe mit der entsprechenden Richtlinie für die neue Version übereinstimmen (die Die Richtlinie kann sich von der Richtlinie unterscheiden, die vor dem Upgrade des Gruppenmitglieds angewendet wurde.
Die Kompatibilitätsrichtlinie, die von Mitgliedern angewendet wird, die versuchen, der Gruppe beizutreten, lautet wie folgt:
Wenn die Version eines MySQL-Servers niedriger ist als die Mindestversion, die von den vorhandenen Gruppenmitgliedern in der Gruppe ausgeführt wird, darf der Server der Gruppe nicht beitreten.
Wenn die Version eines MySQL-Servers mit der Mindestversion übereinstimmt, die von den vorhandenen Mitgliedern der Gruppe ausgeführt wird, kann der Server normalerweise der Gruppe beitreten (und diese zulassen).
Wenn ein Server der Gruppe beitritt und die von ihm ausgeführte MySQL Server-Version höher ist als die Mindestversion, die von den vorhandenen Gruppenmitgliedern in der Gruppe ausgeführt wird, bleibt das Mitglied im schreibgeschützten Modus (wenn die Gruppe im Einzelprimärmodus ausgeführt wird, befinden sich die neu hinzugefügten Mitglieder in einer beliebigen In allen Fällen ist die Standardeinstellung schreibgeschützt. Wenn die Gruppe im Mehrfachprimärmodus ausgeführt wird, befinden sich die neu hinzugefügten Mitglieder möglicherweise im Lese- / Schreibmodus.
Server mit MySQL 8.0.17 oder höher berücksichtigen die Patch-Version der Version bei der Überprüfung der Kompatibilität (z. B. lautet die Versionsnummer 8.0.17, wobei 8.0 die Hauptversion darstellt, 17 die Patch-Version, die auch als Nebenversion bezeichnet werden kann Ausführung). Server mit MySQL 8.0.16 oder niedriger oder MySQL 5.7 berücksichtigen nur Hauptversionen (z. B. lautet die Versionsnummer 8.0.16, wobei 8.0 die Hauptversion ist). Angenommen, eine Gruppe, in der alle Mitglieder Version 8.0.13 ausführen, lautet die Kompatibilitätsrichtlinie, die vom Server angewendet wird, der versucht, der Gruppe beizutreten:
Ein Server mit MySQL 5.7.x darf der Gruppe nicht beitreten.
Ein Server, auf dem MySQL Version 8.0.16 ausgeführt wird, darf der Gruppe normal beitreten (da hier nur die Hauptversionszeichenfolge 8.0 berücksichtigt wird, die mit der Zeichenfolge 8.0 übereinstimmt, die von den vorhandenen Mitgliedern der Gruppe berücksichtigt wird).
Ein Server mit MySQL Version 8.0.17 kann der Gruppe beitreten, bleibt jedoch im schreibgeschützten Modus (da der neu hinzugefügte Server auch die Patch-Version 17 (8.0.17) berücksichtigt, während vorhandene Mitglieder in der Gruppe nur Zeichenfolgen berücksichtigen 8.0).
Beachten Sie, dass ein Server mit einer MySQL-Version vor 5.7.27, der einer Gruppe beitritt, die Version aller Gruppenmitglieder überprüft, um zu überprüfen, ob die Hauptversionsnummer von MySQL für jedes Gruppenmitglied niedriger ist. Entsprechend dem obigen Beispiel und der Kompatibilitätsrichtlinie schlägt diese Prüfung fehl, wenn ein Mitglied der Gruppe MySQL 8.0 ausführt, sodass der Server der MySQL-Version vor 5.7.27 der Gruppe nicht beitreten kann, selbst wenn andere Mitglieder der Gruppe bereits MySQL ausführen In Version 5.7 können Sie der Gruppe auch nicht beitreten. Ab der MySQL 5.7.27-Version überprüft der Server, der der Gruppe beitritt, nur die minimale Hauptversion, die von den vorhandenen Mitgliedern der Gruppe ausgeführt wird. Auf diese Weise kann der Server, der unter MySQL 5.7.27 und höher ausgeführt wird, einem Server beitreten, der ein gemischtes MySQL 5.7.x verwendet Die Gruppe der Versionsmitglieder.
In Gruppen im Multi-Master-Modus mit unterschiedlichen MySQL Server-Versionen verwaltet die Gruppenreplikation automatisch den Schreib- und Schreibstatus von Mitgliedern, die MySQL 8.0.17 oder höher ausführen. Wenn ein Mitglied die Gruppe verlässt, wird das Mitglied, auf dem die aktuell niedrigste Version ausgeführt wird, automatisch in den Lese- / Schreibmodus versetzt. Wenn Sie group_replication_switch_to_multi_primary_mode () UDF online verwenden, um eine Gruppe im Einzelprimärmodus in den Mehrprimärmodus zu ändern, setzt die Gruppenreplikation die Mitglieder automatisch auf den richtigen Modus. Wenn ein Mitglied, auf dem MySQL Server ausgeführt wird, höher als die niedrigste Version in der Gruppe ist, wird es automatisch in den schreibgeschützten Modus und das Mitglied, in dem die niedrigste Version ausgeführt wird, automatisch in den Lese- / Schreibmodus versetzt.
7.1.1. Gruppenmitglieder aktualisieren
Wenn sich die Gruppe während des Online-Upgrade-Prozesses im Single-Master-Modus befindet, wird die Gruppe nicht ausgeführt, nachdem das Mitglied, das den Upgrade-Vorgang ausführt, offline geschaltet wurde (das Mitglied der Gruppe, das den Upgrade-Vorgang ausführt, muss offline sein, das Mitglied der Gruppe, das den Upgrade-Vorgang nicht ausführt) Die Mitglieder der Upgrade-Gruppe wählen einen neuen Primärknoten gemäß der in "1.3.1 Single-Master-Modus" beschriebenen Wahlstrategie. Beachten Sie, dass Sie, wenn der Primärknoten immer unverändert bleiben muss (es sei denn, er führt das Upgrade selbst durch), zuerst das Upgrade für alle anderen Gruppenmitglieder und dann das Upgrade zuletzt für den Primärknoten durchführen müssen (wenn der Primärknoten aktualisiert wird, ist der Primärknoten aufgrund von offline Der neue Primärknoten wird also in der Gruppe wiedergewählt. Wenn Sie nach Abschluss des Upgrades möchten, dass der Primärknoten das ursprüngliche Mitglied bleibt, können Sie ihn mit group_replication_set_as_primary () UDF als Primärknoten neu festlegen.
Wenn sich die Gruppe im Mehrfachprimärmodus befindet, werden die Gruppenmitglieder, die während des Aktualisierungsvorgangs normalerweise Schreibvorgänge ausführen können, immer weniger, da die aktualisierten Mitglieder in den schreibgeschützten Modus versetzt werden und der Gruppe wieder beitreten (dies soll verhindern, dass die neue Version ausgeführt wird) Features können in der alten Version nicht erfolgreich kopiert werden. Wenn alle Mitglieder auf MySQL 8.0.17 und neuere Versionen aktualisiert werden, kehren sie automatisch in den Lese- / Schreibmodus zurück. Bei früheren Versionen müssen Sie nach Abschluss des Upgrades die Systemvariablen super_read_only und read_only für jedes Gruppenmitglied manuell auf OFF setzen (Lese- / Schreibmodus festlegen), um es zum Hauptknoten zu machen.
Hinweis: Beim Vergleich neuer und alter Versionen ab MySQL 8.0.17 muss beim Vergleich die Nebenversionsnummer berücksichtigt werden. Bei Versionen 8.0.16 und früheren Versionen wird beim Vergleich der Versionen nur die Hauptversionsnummer berücksichtigt.
Wenn Sie während des Upgrade-Prozesses für Gruppenmitglieder Upgrade-Rollback-Mitglieder erstellen oder der Gruppe im Notfall ein neues Mitglied hinzufügen müssen, können Sie einem Mitglied, dessen MySQL Server-Version niedriger als die niedrigste Version in der Gruppe ist, erlauben, der Gruppe beizutreten (mithilfe der Gruppe) Kopieren Sie die Systemvariable group_replication_allow_local_lower_version_join, um die normale Kompatibilitätsrichtlinie zu überschreiben. Es sollte beachtet werden, dass das Setzen dieser Systemvariablen auf ON das neue Mitglied nicht mit der Gruppe kompatibel macht. Daher kann diese Systemvariable nur in bestimmten Situationen mit Vorsicht verwendet werden Weitere Informationen finden Sie in der Beschreibung der Systemvariablen group_replication_allow_local_lower_version_join unter "8. Gruppenreplikationssystemvariablen".
7.1.2. Version des Kommunikationsprotokolls für Gruppenkopien
Die Versionsnummer des Gruppenkommunikationsprotokolls, die von der Gruppenreplikation verwendet wird, muss nicht unbedingt mit der MySQL Server-Versionsnummer der Gruppenmitglieder übereinstimmen (Beispiel: Die von MySQL Server 8.0.17 verwendete Kommunikationsprotokollversion ist 8.0.16 anstelle von 8.0.17, die Protokollversion repräsentiert Die niedrigste MySQL Server-Version, die derzeit von dieser Gruppe unterstützt wird, MySQL Version 5.7.14 unterstützt komprimierte Nachrichten und MySQL Version 8.0.16 unterstützt die Nachrichtensegmentierung. Um die Kommunikationsprotokollversion der Gruppe anzuzeigen, können Sie die folgende Anweisung in jedem abzufragenden Mitglied der Gruppe ausführen:
root@localhost : (none):35: > SELECT group_replication_get_communication_protocol();
+------------------------------------------------+
| group_replication_get_communication_protocol() |
+------------------------------------------------+
| 8.0.16 |
+------------------------------------------------+
1 row in set (0.00 sec)
Hinweis: Die von group_replication_get_communication_protocol () UDF zurückgegebene Version des Gruppenkommunikationsprotokolls stellt die niedrigste MySQL Server-Version dar, die derzeit von der Gruppe unterstützt wird. Wenn group_replication_set_communication_protocol () UDF zur Durchführung der Konfiguration des Gruppenkommunikationsprotokolls verwendet wird, kann der endgültige effektive Wert von dem an die Funktion übergebenen Wert abweichen. Beispiel: Der an diese Funktion übergebene Wert ist 8.0.17 und der endgültige effektive Wert ist 8.0.16.
Wenn alle Mitglieder einer Replikationsgruppe auf eine neue MySQL Server-Version aktualisiert werden, wird die Version des Gruppenreplikationskommunikationsprotokolls nicht automatisch aktualisiert, falls weiterhin Mitglieder der früheren Version der Gruppe beitreten müssen. Wenn nach dem Upgrade auf die neue Version festgestellt wird, dass Sie die alte Version von Server nicht unterstützen müssen und einige zusätzliche Funktionen der neuen Version verwenden möchten, können Sie die UDF-Funktion group_replication_set_communication_protocol () verwenden, um die Version des Gruppenkommunikationsprotokolls (alle Mitglieder der Gruppe) zu aktualisieren Nur ein Mitglied kann den Versionsvorgang des Gruppenkommunikationsprotokolls ändern. Weitere Informationen finden Sie unter "4.1.4 Festlegen der Kommunikationsprotokollversion der Gruppe".
7.2. Offline-Upgrade der Gruppenreplikation
Um ein Offline-Upgrade für die Gruppenreplikation durchzuführen, müssen Sie alle Mitglieder der Gruppe einzeln aus der Gruppe entfernen. Nachdem Sie sichergestellt haben, dass die Gruppe offline ist, führen Sie auf jedem Server Versions-Upgrades durch. Starten Sie die Gruppe nach dem Upgrade aller Serverversionen normal neu. In einer Gruppe mit mehreren Master-Modi können Sie Gruppenmitglieder in beliebiger Reihenfolge entfernen und schließen. In einer Einzelmaster-Modusgruppe müssen Sie zuerst die Server der schreibgeschützten Mitglieder einzeln entfernen und schließen und schließlich die Server des Hauptknotenmitglieds (Schreibknoten) schließen. Informationen zum Entfernen von Mitgliedern aus der Gruppe und zum Herunterfahren von MySQL Server finden Sie unter "7.3.2. Aktualisieren von Gruppenreplikationsmitgliedern".
Nachdem alle Mitglieder einer Gruppe erfolgreich auf die neue Version aktualisiert wurden, verwenden diese Mitglieder beim Neustart der Gruppe die neue Version des Gruppenreplikations-Kommunikationsprotokolls, um eine Verbindung herzustellen. Wenn Sie zu diesem Zeitpunkt zulassen müssen, dass eine frühere Version von Server der Gruppe beitritt, können Sie die UDF group_replication_set_communication_protocol () verwenden, um die Version des Gruppenkommunikationsprotokolls auf die Versionsnummer des von der alten Version unterstützten Kommunikationsprotokolls herunterzustufen (oder direkt die Versionsnummer der alten Version von MySQL Server eingeben).
7.3 Online-Upgrade der Gruppenreplikation
Wenn Sie ein Versions-Upgrade einer laufenden Gruppe durchführen möchten und sicherstellen müssen, dass die Gruppe während des Upgrade-Prozesses Dienste für die Außenwelt bereitstellt, müssen Sie die richtige Upgrade-Methode verwenden. In diesem Abschnitt werden einige Methoden zum Ausführen einer Online-Upgrade-Gruppe vorgestellt.
7.3.1 Vorsichtsmaßnahmen für das Online-Upgrade
Beim Online-Upgrade einer Gruppe müssen folgende Punkte berücksichtigt werden:
Unabhängig davon, wie die Gruppenmitglieder aktualisiert werden, ist es verboten, Schreibvorgänge für die Mitglieder auszuführen, bis die Gruppenmitglieder aktualisiert wurden und der Gruppe wieder beitreten.
Wenn ein Mitglied die Gruppenreplikation stoppt, wird die Systemvariable super_read_only automatisch auf on gesetzt, aber dieser geänderte Wert ist nicht dauerhaft. Das heißt, der geänderte Wert wird nach dem Neustart des Servers durch die Einstellung in der Konfigurationsdatei oder den Standardwert überschrieben.
Wenn ein Mitglied von MySQL 5.7.22 oder MySQL 8.0.11 versucht, einer Gruppe beizutreten, in der MySQL 5.7.21 oder niedriger ausgeführt wird, schlägt dies fehl, da MySQL 5.7.21 den Wert der Systemvariablen lower_case_table_names nicht sendet
7.3.2. Aktualisieren Sie die Gruppenreplikationsmitglieder
In diesem Abschnitt werden die Schritte beschrieben, die zum Aktualisieren von Gruppenmitgliedern erforderlich sind. Dieser Vorgang ist Teil von "7.3.3 Online-Upgrade-Methode für Gruppenkopien". Die Methode zum Aktualisieren aller Mitglieder der Gruppe ist üblich. Es ist jedoch zu beachten, dass die Gruppe im Einzelmaster- oder Multi-Master-Modus ausgeführt wird. Dies wirkt sich auf die Reihenfolge aus, in der die Gruppenmitglieder aktualisiert und wieder verbunden werden.
Das Aktualisieren von Gruppenmitgliedern umfasst: Entfernen aus der Gruppe, Durchführen des Upgrades gemäß der ausgewählten Methode zum Aktualisieren von Mitgliedern und anschließendes erneutes Hinzufügen der aktualisierten Mitglieder zur Gruppe. Wenn Sie Mitglieder in einer Single-Master-Modusgruppe aktualisieren, wird empfohlen, zuerst die schreibgeschützten Knoten und dann die schreibgeschützten Knoten (Primärknoten) zu aktualisieren. Wenn die schreibgeschützten Knoten vor den schreibgeschützten Knoten aktualisiert werden müssen, müssen Sie einen alten auswählen. Die anderen Mitglieder der Version dienen als neue Hauptknoten. Um die Arbeitslast zu verringern, wird normalerweise empfohlen, die Lese- und Schreibknoten zuletzt zu aktualisieren.
Gruppenmitglieder aktualisieren:
Verwenden Sie den Client, um sich bei dem zu aktualisierenden Gruppenmitglied anzumelden, und führen Sie die Anweisung STOP GROUP_REPLICATION aus, um die Gruppenreplikation zu stoppen. Überprüfen Sie anschließend die Tabelle performance_schema.replication_group_members, um sicherzustellen, dass sich das Mitglied im Status OFFLINE befindet (beachten Sie, dass sich zu diesem Zeitpunkt nur eine Zeile in der Tabelle befinden sollte , Und der MEMBER_STATE-Feldwert dieses Zeilendatensatzes ist OFFLINE).
Indem Sie die Systemvariable group_replication_start_on_boot = 0 festlegen, um zu verhindern, dass das Mitglied beim Neustart automatisch der Gruppe beitritt, nachdem das Upgrade und die Konfigurationsvorgänge abgeschlossen sind, verbinden Sie das Mitglied manuell und sicher wieder mit der Gruppe. Hinweis: Wenn das Mitglied, das das Upgrade durchführt, die Systemvariable group_replication_start_on_boot = 1 setzt. Wenn der Upgrade-Vorgang fehlschlägt, versucht das fehlgeschlagene Mitglied, der Gruppe automatisch beizutreten, wenn der Server neu gestartet wird.
Stoppen Sie den MySQL Server-Prozess von Gruppenmitgliedern. Verwenden Sie beispielsweise den Befehl mysqladmin shutdown auf dem Server, auf dem sich der Server befindet, oder melden Sie sich bei der Datenbank an, und verwenden Sie die Anweisung shutdown, um den Serverprozess von Gruppenmitgliedern zu stoppen, die aktualisiert werden müssen. Zu diesem Zeitpunkt werden andere Mitglieder der Gruppe weiterhin ausgeführt, ohne betroffen zu sein.
Verwenden Sie in-situ (verwenden Sie den Befehl mysql_upgrade, um die Datenwörterbuchmethode zu aktualisieren) oder verwenden Sie die vorinstallierte und konfigurierte neue Version des Servers, um die logische Ableitung zu aktualisieren. Wenn der Server nach dem Upgrade neu gestartet wird, wird die Gruppenreplikation nicht automatisch gestartet und der Gruppe wieder beigetreten, da die Systemvariable group_replication_start_on_boot auf 0 gesetzt ist. Daher sind manuelle Vorgänge erforderlich, um der Gruppe wieder beizutreten.
Nach Abschluss des Mitglieder-Upgrades muss die Systemvariable group_replication_start_on_boot auf 1 gesetzt werden, um sicherzustellen, dass das Mitglied nach dem nächsten Neustart automatisch wieder der Gruppe beitreten kann.
Verwenden Sie den Client, um sich beim aktualisierten Server anzumelden und die Anweisung START GROUP_REPLICATION auszuführen, um die Gruppenreplikation zu starten. Stellen Sie sicher, dass der Server wieder der Gruppe beitritt. Zu diesem Zeitpunkt sind die Metadaten der Gruppenreplikation in den aktualisierten Mitgliedern bereit, sodass die Gruppenreplikation normalerweise nicht neu konfiguriert werden muss. Es muss jedoch die neueste Transaktion in der Gruppe einholen. Wenn es die neueste Transaktion in der Gruppe einholt, wird es ein Online-Mitglied dieser Gruppe. Hinweis: Je länger das Upgrade des Servers dauert (dh je länger das Verlassen der Gruppe dauert), desto größer ist der Unterschied zwischen den Daten auf dem Server und der Gruppe und die Zeit, die erforderlich ist, um sie wieder zur Gruppe hinzuzufügen. Je mehr (weil möglicherweise mehr Transaktionen aufgeholt werden müssen).
Wenn der aktualisierte Server einer Gruppe beitritt und festgestellt wird, dass die Mitglieder der Gruppe eine ältere Version von MySQL Server ausführen, setzt der aktualisierte Server seine Systemvariable super_read_only auf on, wenn er der Gruppe wieder beitritt. Dadurch kann sichergestellt werden, dass keine neuen Daten auf den neu aktualisierten Server geschrieben werden, bevor alle Mitglieder auf die neue Version aktualisiert wurden (verhindern Sie, dass die in der neuen Version des Servers geschriebenen Daten nicht mit der alten Version des Servers kompatibel sind). In einer Gruppe mit mehreren Master-Modi müssen Mitglieder, die den beschreibbaren Master-Modus verwenden möchten, auf den Lese- / Schreibmodus eingestellt werden, wenn das Gruppen-Upgrade abgeschlossen ist und bereit ist, externe Dienste bereitzustellen. Ab MySQL 8.0.17 werden alle Mitglieder automatisch in den Lese- / Schreibmodus versetzt, wenn alle Mitglieder einer Gruppe auf dieselbe Version aktualisiert werden. Bei früheren Versionen müssen Sie jedoch jedes Mitglied, das Lese- und Schreibvorgänge ausführen muss, manuell auf den Lese- und Schreibmodus einstellen. Wird durch die folgende Anweisung festgelegt:
root@localhost : (none):30: > SET GLOBAL super_read_only=OFF; set global read_only=OFF;
Query OK, 0 rows affected (0.00 sec)
7.3.3 Online-Upgrade-Methode für die Gruppenreplikation
Es gibt verschiedene Optionen für die Online-Aktualisierung der Gruppenreplikation, die entsprechend Ihrer tatsächlichen Situation ausgewählt werden können.
7.3.3.1. Rollendes Upgrade innerhalb der Gruppe
Rollendes Upgrade innerhalb der Gruppe: Bezieht sich darauf, dass die Gruppenmitglieder einzeln aus der Gruppe entfernt werden, ein In-situ-Upgrade durchführen (keine Datenmigration erforderlich, kein Serveraustausch erforderlich) und nach Abschluss des Upgrades wieder der Gruppe beitreten. Während des Aktualisierungsprozesses kann die Gruppe Lese- und Schreibdienste für die Außenwelt bereitstellen, aber die Mitglieder, die aus der Gruppe entfernt werden und das Upgrade durchführen, tragen während des Aktualisierungsprozesses keine Arbeitslast (schreibgeschützte oder schreibgeschützte Dienste werden nicht bereitgestellt). Wenn nach Abschluss des Upgrades beim erneuten Beitritt zur Gruppe Mitglieder mit einer niedrigeren Versionsnummer in der Gruppe vorhanden sind, wird die Gruppe in einem schreibgeschützten Modus wieder verbunden (derzeit werden nur schreibgeschützte Dienste bereitgestellt). Ob die neu hinzugefügten Mitglieder in Zukunft vom schreibgeschützten Modus in den schreibgeschützten Modus wechseln müssen, hängt davon ab, ob die Gruppe im Single-Master-Modus oder im Multi-Master-Modus ausgeführt wird.
Einzelprimärmodus: Die fortlaufende Aktualisierungsmethode innerhalb der Gruppe eignet sich sehr gut für die Einzelprimärmodusgruppe. Im Einzelprimärmodus werden beim Durchführen eines fortlaufenden Upgrades die Sekundärknoten (schreibgeschützte Knoten) nacheinander und der Primärknoten (Lese- / Schreibknoten) aktualisiert. Führen Sie schließlich das Upgrade durch, damit Sie während des gesamten Upgrade-Prozesses eine Wiederwahl so weit wie möglich vermeiden können. Natürlich ist es beim endgültigen Upgrade des Hauptknotens unvermeidlich, den Master wiederzuwählen, aber gemäß dieser empfohlenen Reihenfolge erfolgt die Wiederwahl nur einmal, dh sie wird ausgelöst, wenn der Hauptknoten aus der Gruppe entfernt und das Upgrade durchgeführt wird Wählen Sie den Master einmal wieder. Wenn das letzte Mitglied (dh der vorherige Primärknoten) aktualisiert wird, können Sie die UDF group_replication_set_as_primary () verwenden, um es als Primärknoten neu zuzuweisen. Wenn es Ihnen nichts ausmacht, welches Gruppenmitglied der Hauptknoten ist, können Sie den Hauptknoten natürlich ohne Verwendung von UDF neu zuweisen. Informationen zur Master-Auswahlstrategie im Single-Master-Modus finden Sie unter "1.3.1 Single-Master-Modus".
Multi-Primärmodus: Für eine Gruppe im Multi-Primärmodus können mehrere Primärknoten (Lese- und Schreibknoten) vorhanden sein. Bei Verwendung eines fortlaufenden Upgrades innerhalb der Gruppe gibt es keine spezifische Regel für die Aktualisierungsreihenfolge (die Reihenfolge der Aktualisierungsmitglieder kann entsprechend der tatsächlichen Situation festgelegt werden). Bevor jedoch alle Mitglieder in der Gruppe auf die neueste Version aktualisiert werden, müssen die aktualisierten Mitglieder beim erneuten Beitritt zur Gruppe in den schreibgeschützten Modus versetzt werden (setzen Sie die Systemvariable super_read_only = ON, da Mitglieder mit niedrigeren Versionen in der Gruppe vorhanden sind. Hinweis: Wenn super_read_only = ON ist, wird read_only automatisch auf ON gesetzt, aber wenn super_read_only = OFF, wird read_only nicht automatisch auf OFF gesetzt, da mehrere Knoten in einer Multi-Master-Modusgruppe gleichzeitig Lese- und Schreibdienste bereitstellen können In diesem Fall nimmt die Schreibverfügbarkeit der Gruppe allmählich ab, bis alle Mitglieder der Gruppe auf die neueste Version aktualisiert wurden. Wenn alle Mitglieder der Gruppe auf die neueste Version aktualisiert werden und die MySQL Server-Versionsnummer kleiner als 8.0.16 ist, muss sie im schreibgeschützten Modus ein Gruppenmitglied sein. Sie müssen die Systemvariablen super_read_only = OFF, read_only = OFF manuell deaktivieren, um sie zu deaktivieren Lesen (zurück zum Lese- / Schreibmodus). Wenn die MySQL Server-Versionsnummer größer oder gleich 8.0.17 ist, werden nach der Aktualisierung aller Mitglieder auf die neue Version die Systemvariablen super_read_only = OFF, read_only = OFF automatisch so eingestellt, dass schreibgeschützt deaktiviert wird (Rückkehr zum Lese- / Schreibmodus). Informationen zur Versionskompatibilität im Multi-Master-Modus finden Sie unter "1.3.2.3. Versionskompatibilität".
Ausführliche Informationen zur Versionskompatibilität in einer Gruppe und zu den Auswirkungen auf das Verhalten der Gruppe während des Aktualisierungsprozesses finden Sie unter "7.1. Kompatible Mitglieder verschiedener Versionen in einer Gruppe".
PS: Im fortlaufenden Upgrade-Plan innerhalb der Gruppe treten Gruppenmitglieder nach Abschluss des Upgrades wieder der ursprünglichen Gruppe bei.
7.3.3.2. Migration und fortlaufendes Upgrade
Rollendes Upgrade für Migration: Bezieht sich darauf, dass die Gruppenmitglieder einzeln aus der Gruppe entfernt werden und nach dem Upgrade nicht wieder der ursprünglichen Gruppe beitreten, sondern mit den aktualisierten Mitgliedern eine zweite Gruppe (neue Gruppe) erstellen. Bei einer Gruppe, die im Multi-Master-Modus ausgeführt wird, nimmt die Anzahl der Hauptknoten (Lese- und Schreibknoten) während dieses Vorgangs allmählich ab, was zu einer verringerten Schreibverfügbarkeit führt. Bei einer Gruppe, die im Einzelprimärmodus ausgeführt wird, hat dies jedoch keine Auswirkungen auf die Schreibverfügbarkeit der Gruppe (wenn jedoch der Lese- / Schreibknoten am Ende der Gruppe aktualisiert wird, muss die Anwendung einen Schreibanforderungswechsel zwischen der alten und der neuen Gruppe durchführen, und die Anwendung ist zu diesem Zeitpunkt betroffen).
Während des Upgrades der Gruppe muss die neue Gruppe, die sich aus Mitgliedern mit der aktualisierten Version zusammensetzt, den Upgrade-Prozess nachholen, da die Gruppe, in der die alte Version ausgeführt wird, immer online ist (kontinuierlich Lese-, Schreib- und Nur-Lese-Dienste für die Außenwelt bereitstellt). Alle neu geschriebenen Transaktionen in der Gruppe. Daher ist es erforderlich, ein Mitglied in der neuen Gruppe als Slave-Bibliothek auszuwählen und einen asynchronen Master-Slave-Replikationskanal mit dem Hauptknoten (Lese- / Schreibknoten) in der alten Gruppe einzurichten, um die neuesten Daten zu erhalten. Um Unfälle beim Aufholen von Daten über asynchrone Replikationskanäle zu vermeiden, muss sichergestellt werden, dass die Systemkonfigurationsparameter für die Gruppenreplikation und die Master-Slave-Replikation zwischen der alten und der neuen Gruppe vollständig konsistent sind. Bei einer Gruppe, die im Single-Master-Modus ausgeführt wird, muss das Mitglied der Slave-Bibliothek in der neuen Gruppe der primäre Knoten (Lese- / Schreibknoten) in der neuen Gruppe sein. Bei einer Gruppe im Multi-Master-Modus kann das Mitglied der Slave-Bibliothek in der neuen Gruppe ein neues sein Jedes Mitglied der Gruppe (Lese- / Schreibknoten).
Der gesamte Upgrade-Prozess sieht ungefähr wie folgt aus:
Entfernen Sie nacheinander Mitglieder aus der ursprünglichen Gruppe, in der die alte Version ausgeführt wird (siehe "7.3.2. Aktualisieren von Gruppenkopie-Mitgliedern").
Aktualisieren Sie die MySQL Server-Version, die auf den Mitgliedern der ausgeschlossenen Gruppe ausgeführt wird. Informationen zu den Upgrade-Schritten finden Sie unter "Eine Formel für die MySQL-Leistungsoptimierungspyramide". Kapitel 2 Zwei häufig verwendete Upgrade-Methoden für MySQL.
Erstellen Sie eine neue Gruppe mit den Mitgliedern der Gruppe, die auf die neue Version aktualisiert wurden. Die Schritte zum Bereitstellen der neuen Gruppe werden unter "2. Installation und Bereitstellung von Gruppenkopien" beschrieben. Da die alte Gruppe ausgeführt wird, müssen Sie der neuen Gruppe einen neuen Gruppennamen geben und das erste aktualisierte Mitglied als Leitfaden für die neue Gruppe verwenden. Die nachfolgenden aktualisierten Mitglieder können der neuen Gruppe beitreten.
Richten Sie einen asynchronen Replikationskanal zwischen der alten und der neuen Gruppe ein. Legen Sie den Hauptknoten in der alten Gruppe als Hauptbibliothek für die asynchrone Replikation fest und konfigurieren Sie den Hauptknoten in der neuen Gruppe als Slave-Bibliothek für die GTID-Replikation.
Bevor Sie die Anwendung auf die neue Gruppe umleiten (umschalten), müssen Sie sicherstellen, dass die neue Gruppe über eine angemessene Anzahl von Gruppenmitgliedern verfügt, damit die neue Gruppe normal reagieren kann, wenn ein Mitglied ausfällt. Sie können die Gruppengröße der alten und der neuen Gruppe anzeigen, indem Sie die Gruppenmitgliedsansicht über die Tabelle performance_schema.replication_group_members in einem beliebigen Mitglied der neuen Gruppe abfragen. Nachdem Sie diese Informationen sichergestellt haben, können Sie das Schreiben von Daten in der alten Gruppe blockieren (Sie müssen den Unterschied zwischen der alten und der neuen Gruppe beobachten). Asynchrone Replikationsverzögerung zwischen der Zeit, dieser Schritt kann ausgeführt werden, wenn die Verzögerung nicht groß ist. Warten Sie, bis die neue Gruppe die neuesten Daten in der alten Gruppe eingeholt hat, bis die neue Gruppe alle Daten in der alten Gruppe eingeholt hat, und wechseln Sie dann die Anwendung zur neuen Gruppe , Und löschen Sie die asynchrone Replikationsverbindung zwischen der neuen und der alten Gruppe. Aktualisieren Sie abschließend alle Gruppenmitglieder der alten Version. Fügen Sie sie nach Abschluss des Upgrades nacheinander zur neuen Gruppe hinzu.
PS: Migrieren Sie den fortlaufenden Upgrade-Plan. Nach dem Upgrade der Gruppenmitglieder bilden sie eine neue Gruppe, und der Server (Host) ist immer noch der ursprüngliche.
7.3.3.3. Rollendes Replikat-Upgrade
Rolling Copy Upgrade: Im Vergleich zu den beiden Schemata "Rolling Upgrade innerhalb einer Gruppe" und "Rolling Migration Upgrade" müssen Gruppenmitglieder die Gruppe nicht aus der Gruppe entfernen. Stattdessen verwenden sie ein Sicherungstool, um die Datenkopien in der Gruppe in eine zu kopieren. Führen Sie in der neuen Servergruppe das Upgrade nacheinander durch und erstellen Sie eine zweite Gruppe (neue Gruppe). Während des Upgrades müssen die inkrementellen Daten zwischen der neuen und der alten Gruppe zwischen der neuen und der alten Gruppe übertragen werden, da die alte Gruppe weiterhin Dienste online bereitstellt. Richten Sie einen asynchronen Replikationskanal für die Datensynchronisation ein (Einzelheiten zum Erstellen eines asynchronen Replikationskanals zwischen der alten und der neuen Gruppe finden Sie unter "7.3.3.2. Migration und fortlaufendes Upgrade" für Details). Wenn die neue Gruppe die neuesten Daten in der alten Gruppe einholt, wird sie angewendet Der Zugriff auf das Programm wird auf die neue Gruppe umgeschaltet. Bei Gruppen, die im Multi-Master-Modus ausgeführt werden, wird die Anzahl der Primärknoten (Lese- und Schreibknoten) während des Aktualisierungsprozesses nicht verringert, sodass die Verfügbarkeit von Schreibvorgängen nicht beeinträchtigt wird (daher ist diese Aktualisierungsmethode sehr gut für Gruppen geeignet, die im Multi-Master-Modus ausgeführt werden.) . Bei Gruppen, die im Einzelprimärmodus ausgeführt werden, ist die Schreibverfügbarkeit ebenfalls nicht betroffen.
Der gesamte Upgrade-Prozess sieht ungefähr wie folgt aus:
Verwenden Sie die neue Version des Server-Pakets, um den neuen Server zu initialisieren und zu installieren. Es muss sichergestellt werden, dass die Anzahl der Mitglieder der neuen Version normal reagieren kann, wenn ein Mitglied ausfällt. Beachten Sie, dass zu diesem Zeitpunkt keine Gruppe auf der neuen Version des Servers erstellt werden muss. Verwenden Sie einfach die neue Version des Pakets, um den Datenbankserver zu initialisieren und zu installieren, und stellen Sie sicher, dass der Server normal gestartet werden kann.
Sichern Sie die vorhandenen Daten (vollständige Sicherung) von einem Mitglied der ursprünglichen Gruppe. Ausführliche Informationen zur Sicherung finden Sie unter "4.6. Verwenden Sie Sicherungsdaten, um fehlgeschlagene Mitglieder wiederherzustellen oder neue Mitglieder in der Gruppenreplikation zu erweitern".
Verwenden Sie die Sicherungsdaten, um auf dem Server wiederherzustellen, auf dem Sie eine neue Gruppe erstellen möchten, und führen Sie ein direktes Upgrade durch.
Erstellen Sie eine neue Gruppe, wobei der Server auf die neue Version aktualisiert wurde. Die Schritte zum Bereitstellen der neuen Gruppe werden unter "2. Installation und Bereitstellung von Gruppenkopien" beschrieben. Da die alte Gruppe ausgeführt wird, müssen Sie der neuen Gruppe einen neuen Gruppennamen geben und den ersten aktualisierten Server als Leitfaden für die neue Gruppe verwenden. Der nachfolgende aktualisierte Server kann der neuen Gruppe beitreten.
Richten Sie einen asynchronen Replikationskanal zwischen der alten und der neuen Gruppe ein. Legen Sie den Hauptknoten in der alten Gruppe als Hauptbibliothek für die asynchrone Replikation fest und konfigurieren Sie den Hauptknoten in der neuen Gruppe als Slave-Bibliothek für die GTID-Replikation.
Sobald die Daten in der neuen Gruppe im Vergleich zur Replikation der alten Gruppe ausreichend verzögert sind, kann der Anwendungswechsel durchgeführt werden (Anwendungszugriff auf die neue Gruppe umleiten), und dann wird der asynchrone Replikationskanal zwischen der alten und der neuen Gruppe gelöscht (Details) Informationen zu den Anforderungen für den Anwendungswechsel finden Sie unter "7.3.3.2. Upgrade der Migration".
PS: Nach dem Upgrade der Gruppenmitglieder sind die Gruppenmitglieder und Server (Hosts) brandneu.
Über den Autor
Luo Xiaobo · Experte für Datenbanktechnologie
Einer der Autoren von "Tausend goldene Rezepte - MySQL-Leistungsoptimierungspyramidenregel". Mit der MySQL-Architektur vertraut, gut in der allgemeinen Datenbankoptimierung, auf Spezialisierung auf Open Source-Technologie spezialisiert und auf die Förderung der Open Source-Technologie spezialisiert, haben viele öffentliche Datenbankthemen online und offline geteilt und fast 100 datenbankbezogene Forschungsartikel veröffentlicht.
Weiterführende Literatur
Gruppenreplikationssicherheit | Ein umfassendes Verständnis der Gruppenreplikation in MySQL 8.0
Überwachung der Gruppenreplikation | Ein umfassendes Verständnis der Gruppenreplikation in MySQL 8.0
Hintergrund der Gruppenreplikation | Ein umfassendes Verständnis der Gruppenreplikation in MySQL 8.0
Der vollständige Text ist vorbei.
Viel Spaß mit MySQL 8.0 :)
Die Klasse "MySQL Core Optimization" von Lehrer Ye wurde auf MySQL 8.0 aktualisiert. Scannen Sie den Code, um die Reise von MySQL 8.0 zu beginnen