Immer wenn ein MySQL-Server einem MGR-Cluster neu beitritt oder wieder beitritt, muss er mit den verschiedenen Transaktionen im Cluster Schritt halten, um sicherzustellen, dass die Daten dieses Knotens auf dem neuesten Stand sind Der Cluster Die Daten werden synchronisiert. Der Prozess, bei dem der neu hinzugefügte Knoten die Daten im Cluster aufholt oder der Knoten, der dem Cluster wieder beitritt, die Transaktionsdaten aufholt, die sich seit dem Verlassen des Clusters bis heute geändert haben, wird als verteilte Wiederherstellung bezeichnet.
Der Knoten, der sich für den Beitritt zum Cluster bewirbt, überprüft zunächst das Relay-Protokoll im GroupreplicationApplier-Kanal, um die Transaktionsdaten des Knotens zu überprüfen, der noch nicht vom Cluster synchronisiert wurde. Wenn es sich um einen Knoten handelt, der dem Cluster wieder beitritt, findet der Knoten Transaktionsdaten, die seit dem Verlassen des Clusters nicht wiedergegeben wurden, und die neuesten Daten im Cluster. In diesem Fall wendet der Knoten zuerst diese nicht synchronisierten Transaktionen an. Für neu zum Cluster hinzugefügte Knoten kann die vollständige Datenwiederherstellung direkt von einem Boot-Knoten aus durchgeführt werden.
Danach stellt der neu hinzugefügte Knoten eine Verbindung mit dem vorhandenen Online-Knoten (Boot-Knoten) im Cluster zur Statusübertragung her. Der neu hinzugefügte Knoten synchronisiert die nicht synchronisierten Daten vor dem Beitritt zum Cluster oder nach dem Verlassen des Clusters vom Boot-Knoten im Cluster. Diese verschiedenen Transaktionen werden vom Boot-Knoten im Cluster bereitgestellt. Als Nächstes wendet der neu hinzugefügte Knoten die nicht angewendeten Transaktionen an, die vom Bootstrap-Knoten im Cluster synchronisiert wurden. Zu diesem Zeitpunkt wendet der Knoten, der sich um den Beitritt zum Cluster bewirbt, die von der neuen Transaktion im Cluster während des Statusübertragungsprozesses geschriebenen Daten an. (Zu diesem Zeitpunkt werden die von neuen Dingen im Cluster geschriebenen Daten vorübergehend in der Cache-Warteschlange gespeichert und die Daten werden nicht auf die Festplatte geschrieben.) Nach Abschluss dieses Vorgangs werden die Daten der neu hinzugefügten Knoten auf einer Ebene verglichen mit den Daten des gesamten Clusters und der Knoten wird in den Online-Status versetzt.
Hinweis: Neue Knoten, die dem Cluster beitreten, unabhängig davon, ob sie zuvor in diesem Cluster waren oder nicht, wählen zunächst zufällig einen Online-Knoten aus, um den Knoten zu synchronisieren und Cluster-unterschiedliche Transaktionen.
Die Gruppenreplikation verwendet die folgende Methode, um die Statusübertragung während der verteilten Wiederherstellung zu implementieren:
Verwenden Sie die Funktionalität des Klon-Plugins. Für den Remote-Klonbetrieb kann dieses Plug-in ab MySQL 8.0.17 unterstützt werden. Um diese Methode nutzen zu können, muss das Klon-Plug-in vorab auf dem Boot-Knoten und dem neu beigetretenen Knoten installiert werden. Die Gruppenreplikation konfiguriert automatisch die erforderlichen Klon-Plug-in-Einstellungen und verwaltet Remote-Klonvorgänge.
Kopieren Sie Daten aus dem Binärprotokoll des Boot-Knotens und wenden Sie diese Transaktionen auf den neu beigetretenen Knoten an. Für diese Methode ist ein standardmäßiger asynchroner Replikationskanal namens „groupreplicationrecovery“ erforderlich, der zwischen dem Startknoten und dem beitretenden Knoten eingerichtet wird.
Nach der Ausführung von STARTGROUP_REPLICATION auf dem beitretenden Knoten wählt die Gruppenreplikation automatisch die beste Kombination der oben genannten Methoden für die Statusübertragung aus. Zu diesem Zweck prüft die Gruppenreplikation, welche vorhandenen Knoten im Cluster als Boot-Knoten geeignet sind, wie viele Transaktionen der beitretende Knoten vom Boot-Knoten benötigt und ob in den binären Protokolldateien von keine Transaktionen mehr vorhanden sind Jeder Knoten im Cluster. Wenn zwischen dem beitretenden Knoten und dem Startknoten eine große Transaktionslücke besteht oder einige der erforderlichen Transaktionen nicht in den binären Protokolldateien des Startknotens enthalten sind, startet die Gruppenreplikation eine verteilte Wiederherstellung über einen Remote-Klonvorgang. Wenn keine großen Transaktionslücken vorhanden sind oder das Klon-Plug-in nicht installiert ist, überträgt die Gruppenreplikation den Status direkt aus dem Binärprotokoll des Startknotens.
Während eines Remote-Klonvorgangs werden vorhandene Daten auf dem beitretenden Knoten gelöscht und durch eine Kopie der Boot-Knotendaten ersetzt. Wenn der Remote-Klonvorgang abgeschlossen ist und der neu beigetretene Knoten neu gestartet wurde, ruft die Statusübertragung aus dem Binärprotokoll des Startknotens weiterhin die vom Cluster während des Remote-Klonvorgangs geschriebenen inkrementellen Daten ab.
Während der Statusübertragung vom Binärprotokoll des Boot-Knotens kopiert und wendet der neu beitretende Knoten die erforderlichen Transaktionen aus dem Binärprotokoll des Boot-Knotens an und wendet die empfangenen Transaktionen an, bis das Binärprotokoll den neu hinzugefügten Knoten aufzeichnet dem Cluster beitreten. (Wenn der beitretende Knoten erfolgreich dem Cluster beitritt, wird das entsprechende Ansichtsänderungsereignis im Binärprotokoll aufgezeichnet.) Während dieses Vorgangs puffert der beitretende Knoten neue Transaktionsdaten, die auf den Cluster angewendet werden. Nachdem die Statusübertragung vom Binärprotokoll abgeschlossen ist, wendet der neu beitretende Knoten die gepufferten Transaktionen an.
Wenn der beitretende Knoten mit allen Transaktionen für den Cluster auf dem neuesten Stand ist, wird der Knoten online geschaltet und kann dem Cluster als normaler Knoten beitreten, und die verteilte Wiederherstellung ist abgeschlossen.
ps: Die Statusübertragung aus dem Binärprotokoll ist der grundlegende Mechanismus für die verteilte Wiederherstellung mit Gruppenreplikation, und wenn der Startknoten und der beitretende Knoten in der Replikationsgruppe dies nicht tun auf „Unterstützt das Klonen“ eingestellt. Da die Statusübertragung aus dem Binärprotokoll auf der klassischen asynchronen Replikation basiert, kann die Wiederherstellung lange dauern, wenn der dem Cluster beitretende MySQL-Server überhaupt keine Daten für den Cluster hat oder die Daten aus einer sehr alten Sicherung stammen . Neueste Daten. Daher wird in diesem Fall empfohlen, dass Sie den MySQL-Server vor dem Hinzufügen zum Cluster mit den Daten des Clusters einrichten, indem Sie einen relativ aktuellen Snapshot der bereits im Cluster vorhandenen Knoten übertragen. Dies minimiert die für die verteilte Wiederherstellung erforderliche Zeit und reduziert die Auswirkungen auf den Startknoten, der weniger binäre Protokolldateien aufbewahren und übertragen muss.
Wenn der beitretende Knoten während der verteilten Wiederherstellung eine Verbindung zum Bootstrap-Knoten im vorhandenen Knoten zur Statusübertragung herstellt, fungiert der beitretende Knoten als Client und der Bootstrap-Knoten als Server. Wenn die Statusübertragung vom Binärprotokoll des Startknotens über diese Verbindung erfolgt (unter Verwendung des asynchronen Replikationskanals GroupReplicationRecovery), fungiert der beitretende Knoten als Replikat und der Startknoten als Quelle. Wenn über diese Verbindung ein Remote-Klonvorgang durchgeführt wird, fungiert der neu hinzugefügte Knoten als vollständiger Datenempfänger und der Boot-Knoten als vollständiger Datenanbieter. Konfigurationseinstellungen, die für Rollen außerhalb des Kontexts der Gruppenreplikation gelten, gelten auch für die Gruppenreplikation, sofern sie nicht durch gruppenreplikationsspezifische Konfigurationseinstellungen oder Verhaltensweisen überschrieben werden.
Die Verbindungen, die von vorhandenen Knoten zu neu beigetretenen Knoten für die verteilte Wiederherstellung bereitgestellt werden, unterscheiden sich von den Verbindungen, die die Gruppenreplikation für die Kommunikation zwischen Knoten innerhalb des Clusters verwendet.
Die Gruppenkommunikations-Engine wird für die Gruppenreplikation verwendet (XCom, Paxos-Variante), die für die TCP-Kommunikation zwischen Remote-XCom-Instanzen verwendete Verbindung wird durch die Systemvariable groupreplicationlocal_address angegeben. Diese Verbindung wird für TCP/IP-Nachrichten zwischen Online-Knoten innerhalb des Clusters verwendet. Die Kommunikation mit der lokalen Instanz erfolgt über einen gemeinsam genutzten In-Memory-Transportkanal.
Für die verteilte Wiederherstellung stellten Knoten innerhalb des Clusters bis MySQL8.0.20 ihre Standard-SQL-Client-Verbindungen zum beitretenden Knoten bereit, der durch den Hostnamen und die Portsystemvariablen des MySQL-Servers angegeben wurde. Wenn die Systemvariable „report_port“ eine alternative Portnummer angibt, wird stattdessen diese Portnummer verwendet.
Ab MySQL 8.0.21 können Gruppenmitglieder eine alternative Liste verteilter Wiederherstellungsendpunkte als private Client-Verbindung des beitretenden Mitglieds verwenden, sodass von den regulären Client-Benutzern des Mitglieds unabhängige Verbindungen zur Steuerung der verteilten Wiederherstellung verwendet werden können. Diese Liste kann mithilfe der Systemvariablen „groupReplicationAdvertiseRecoveryEndpoints“ angegeben werden, und Mitglieder übertragen ihre Liste der verteilten Wiederherstellungsendpunkte an die Gruppe, wenn sie der Gruppe beitreten. Standardmäßig stellen Mitglieder weiterhin dieselben Standard-SQL-Clientverbindungen wie in früheren Versionen bereit.
PS:
Die verteilte Wiederherstellung kann fehlschlagen, wenn der beitretende Knoten die anderen Knoten anhand des durch die Systemvariablen von MySQLServer definierten Hostnamens nicht korrekt identifizieren kann. Es wird empfohlen, dass das Betriebssystem, auf dem MySQL ausgeführt wird, über DNS oder lokale Einstellungen einen korrekt konfigurierten eindeutigen Hostnamen hat. Der vom Server für SQL-Clientverbindungen verwendete Hostname kann in der Spalte „Memberhost“ der Tabelle „ReplicationgroupMembers“ in der Bibliothek „performanceschema“ überprüft werden. Wenn mehrere Gruppenmitglieder den vom Betriebssystem festgelegten Standard-Hostnamen externalisieren, besteht die Möglichkeit, dass der beitretende Knoten ihn nicht in die richtige Adresse auflöst und keine Verbindung zur verteilten Wiederherstellung herstellen kann. In diesem Fall kann die Systemvariable „report_host“ von MySQL Server verwendet werden, um einen eindeutigen Hostnamen zu konfigurieren, der von jedem Server externalisiert wird.
Die Schritte zum Beitreten eines Knotens zum Herstellen einer Verbindung für die verteilte Wiederherstellung sind wie folgt:
Wenn ein Knoten dem Cluster beitritt, stellt er eine Verbindung her, indem er zunächst einen der in der Liste in der Systemvariablen „groupreplicationgroupseeds“ enthaltenen Startknoten verwendet Verwenden der in dieser Liste angegebenen lokalen Gruppenreplikationsadresse. Der Startknoten kann eine Teilmenge der Clusterdaten sein.
Über diese Verbindung nutzt der Seed-Knoten den Mitgliedschaftsdienst der Gruppenreplikation, um dem beitretenden Knoten eine Liste aller Online-Knoten im Cluster in Form einer Ansicht bereitzustellen. Zu den Mitgliedschaftsinformationen gehören Details zum verteilten Wiederherstellungsendpunkt oder zur Standard-SQL-Clientverbindung, die von jedem Mitglied für die verteilte Wiederherstellung bereitgestellt werden.
Join-Knoten wählt aus dieser Liste einen geeigneten Online-Knoten als Startknoten für die verteilte Wiederherstellung aus.
Join-Knoten versucht, über den verteilten Wiederherstellungsendpunkt des Startknotens eine Verbindung zum Startknoten herzustellen, und versucht, nacheinander in der angegebenen Reihenfolge eine Verbindung zu jedem Knoten herzustellen im Listenendpunkt. Wenn der Boot-Knoten keinen Endpunkt bereitstellt, versucht der beitretende Knoten, eine Verbindung über die Standard-SQL-Client-Verbindung des Boot-Knotens herzustellen. Die SSL-Anforderungen für die Verbindung werden durch die Optionen „groupreplicationrecoveryssl*“ angegeben.
Wenn der beitretende Knoten keine Verbindung zum angegebenen Bootstrap-Knoten herstellen kann, wird er die Verbindung mit anderen geeigneten Bootstrap-Knoten erneut versuchen. Wenn der beitretende Knoten die Broadcast-Liste des Endpunkts erschöpft, ohne eine Verbindung herzustellen, greift er nicht auf die Standard-SQL-Client-Verbindung des Boot-Knotens zurück, sondern wechselt stattdessen zu einem anderen Boot-Knoten, um zu versuchen, die Verbindung wiederherzustellen.
Wenn der beitretende Knoten eine verteilte Wiederherstellungsverbindung mit dem Boot-Knoten herstellt, verwendet er die Verbindung für die Statusübertragung. Das Protokoll des beitretenden Knotens zeigt den Host und den Port der verwendeten Verbindung. Wenn ein Remote-Klonvorgang verwendet wird und der beitretende Knoten am Ende des Vorgangs neu gestartet wird, stellt er eine Verbindung mit dem neuen Startknoten her und führt eine Statusübertragung aus dem Binärprotokoll des Startknotens durch. Dies kann eine andere Verbindung sein als der Boot-Knoten, der für den Remote-Klonvorgang verwendet wird, oder es kann sich um dieselbe Verbindung wie der Boot-Knoten handeln. Unabhängig davon stellt die verteilte Wiederherstellung auf die gleiche Weise eine Verbindung zum Startknoten her.
Die Systemvariable „groupreplicationadvertiserecoveryendpoints“ dient als IP-Adresse, die vom verteilten Wiederherstellungsendpunkt bereitgestellt wird, und muss nicht für MySQL Server konfiguriert werden (d. h. sie muss nicht vom Admin-Adresssystem angegeben werden). Variable oder in der Liste der Systemvariablen bindaddress) .
Konfigurieren Sie den vom Ende der verteilten Wiederherstellung bereitgestellten Port für MySQL Server, der durch die Systemvariablen port, reportport oder adminport angegeben werden muss. Auf diesen Ports müssen TCP/IP-Verbindungen überwacht werden. Wenn adminport angegeben ist, benötigt der für die verteilte Wiederherstellung verwendete Replikationsbenutzer die Berechtigung SERVICECONNECTIONADMIN, um eine Verbindung herzustellen. Wählen Sie Adminport aus, um verteilte Wiederherstellungsverbindungen von regulären MySQL-Clientverbindungen getrennt zu halten.
Join-Knoten versuchen nacheinander jeden Endpunkt in der in der Liste angegebenen Reihenfolge. Wenn „groupreplicationadvertiserecoveryendpoints“ auf „DEFAULT“ und nicht auf eine Liste von Endpunkten festgelegt ist, wird eine Standard-SQL-Clientverbindung bereitgestellt. Standard-SQL-Clientverbindungen werden nicht automatisch in die Liste der verteilten Wiederherstellungsendpunkte aufgenommen und nicht als Backup verwendet, wenn die Endpunktliste des Startknotens ohne Verbindungen erschöpft ist. Wenn Sie eine Standard-SQL-Clientverbindung als einen von mehreren Endpunkten für die verteilte Wiederherstellung bereitstellen möchten, müssen Sie diese explizit in die durch „groupreplicationadvertiseadvertiserecovery_endpoints“ angegebene Liste aufnehmen. Sie können dies als letzten Ausweg ans Ende der Verbindung setzen.
Es ist nicht erforderlich, den verteilten Wiederherstellungsendpunkt des Gruppenmitglieds (oder die Standard-SQL-Clientverbindung, wenn kein Endpunkt bereitgestellt wird) zur Gruppenreplikations-Zulassungsliste hinzuzufügen, die durch die Systemvariable „groupreplicationipallowlist“ (ab MySQL 8.0.22) oder die Systemvariable „groupreplicationipwhitelist“ angegeben wird. Die Berechtigungsliste gilt nur für die Adressen, die durch groupreplicationlocal_address für jeden Knoten angegeben werden. Der beitretende Knoten muss über eine anfängliche Verbindung zum Cluster verfügen, die von der Zulassungsliste zugelassen wird, um eine oder mehrere Adressen für die verteilte Wiederherstellung abzurufen.
Nach dem Festlegen der Systemvariablen und dem Ausführen der STARTGROUP_REPLICATION-Anweisung werden die aufgelisteten verteilten Wiederherstellungsendpunkte überprüft. Wenn die Liste nicht korrekt analysiert werden kann oder Endpunkte auf dem Host nicht erreicht werden können, weil der Dienst die Liste nicht überwacht, protokolliert die Gruppenreplikation einen Fehler und startet nicht.
In MySQL 8.0.18 gibt es eine Option zum Konfigurieren der Komprimierung für die verteilte Wiederherstellung mithilfe der Statusübertragungsmethode im Binärprotokoll des Boot-Knotens. Die Komprimierung kann der verteilten Wiederherstellung in Situationen zugute kommen, in denen die Netzwerkbandbreite begrenzt ist und der Führungsknoten viele Transaktionen an die beitretenden Knoten übertragen muss. Die Systemvariablen „groupreplicationrecoverycompressionalgorithm“ und „groupreplicationrecoveryzstdcompression_level“ konfigurieren die zulässigen Komprimierungsalgorithmen und ZSTD-Komprimierungsstufen, die bei der Statusübertragung aus dem Binärprotokoll des Startknotens verwendet werden.
Diese Komprimierungseinstellungen gelten nicht für Remote-Klonvorgänge. Wenn ein Remote-Klonvorgang für die verteilte Wiederherstellung verwendet wird, wird die cloneenablecompression-Einstellung des Klon-Plugins angewendet.
Die verteilte Wiederherstellung erfordert einen Replikationsbenutzer mit den richtigen Berechtigungen, damit die Gruppenreplikation direkte Replikationskanäle von Knoten zu Knoten einrichten kann. Der Replikationsbenutzer muss auch über die richtigen Berechtigungen verfügen. Wenn der Replikationsbenutzer auch als Klonbenutzer in einem Remote-Klonvorgang fungiert, muss der Replikationsbenutzer auch über Remote-Klon-bezogene Berechtigungen (BACKUP_ADMIN-Berechtigungen) im Boot-Knoten verfügen, um als Klon zu fungieren Benutzer auf dem Startknoten klonen. Darüber hinaus muss für die verteilte Wiederherstellung auf jedem Knoten innerhalb des Clusters derselbe Replikationsbenutzer verwendet werden.
SSL, das für die verteilte Wiederherstellung verwendet wird, wird getrennt von SSL konfiguriert, das für die normale Gruppenkommunikation verwendet wird, was durch die SSL-Einstellungen des Servers und die Systemvariable groupreplicationssl_mode bestimmt wird. Für verteilte Wiederherstellungsverbindungen können Sie die dedizierte SSL-Systemvariable „Group Replication Distributed Recovery“ verwenden, um die Verwendung von Zertifikaten und Schlüsseln speziell für die verteilte Wiederherstellung zu konfigurieren.
Standardmäßig wird SSL nicht für verteilte Wiederherstellungsverbindungen verwendet. Setzen Sie groupreplicationrecoveryusessl= ON, um es zu aktivieren, konfigurieren Sie dann die SSL-Systemvariable für die verteilte Gruppenreplikationswiederherstellung und legen Sie den Replikationsbenutzer für die Verwendung von SSL fest.
Wenn Sie die verteilte Wiederherstellung für die Verwendung von SSL konfigurieren, wendet die Gruppenreplikation diese Einstellung auf Remote-Klonvorgänge und Statusübertragungen aus dem Binärprotokoll des Startknotens an. Die Gruppenreplikation konfiguriert die Klon-SSL-Optionen (clonesslca, clonesslcert und clonesslkey) automatisch so, dass sie mit den Einstellungen der entsprechenden verteilten Wiederherstellungsoptionen der Gruppenreplikation (groupreplicationrecoverysslca, groupreplicationrecoverysslcert und groupreplicationrecoverysslkey) übereinstimmen.
Wenn SSL nicht für die verteilte Wiederherstellung verwendet wird (groupreplicationrecoveryusessl ist auf OFF gesetzt) und das Replikationsbenutzerkonto für die Gruppenreplikation mit dem Plugin cachingsha2password (Standard in MySQL 8.0) oder dem Plugin sha256password authentifiziert wird, wird das RSA-Schlüsselpaar Passwort verwendet Austausch. Verwenden Sie in diesem Fall die Systemvariable „groupreplicationrecoverypublickeypath“, um die öffentliche RSA-Schlüsseldatei anzugeben, oder verwenden Sie die Systemvariable „groupreplicationrecoverygetpublic_key“, um den öffentlichen Schlüssel anzufordern. Andernfalls schlägt die gesamte verteilte Antwort aufgrund der Fehlerberichterstattung fehl.
Das Klon-Plug-in für MySQLServer ist ab MySQL8.0.17 verfügbar. Wenn Sie Remote-Klonvorgänge für die verteilte Wiederherstellung in einem Cluster verwenden möchten, müssen vorhandene und beitretende Knoten vorab bereitgestellt werden, um diese Funktion zu unterstützen. Richten Sie dies nicht ein, wenn Sie diese Funktion nicht in Ihrem Cluster verwenden möchten. In diesem Fall verwendet die Gruppenreplikation nur die Statusübertragung im Binärprotokoll.
Um das Klon-Plugin verwenden zu können, müssen mindestens ein vorhandener Clusterknoten und ein Beitrittsknoten voreingestellt sein, um Remote-Klonvorgänge zu unterstützen. Zumindest muss das Klon-Plug-in auf den Start- und Beitrittsknoten installiert sein, dem Replikationsbenutzer müssen BACKUPADMIN-Berechtigungen für die verteilte Wiederherstellung erteilt werden und die Systemvariable „groupreplicationclonethreshold“ muss auf die entsprechende Ebene gesetzt sein. (Standardmäßig ist dies der von der GTID-Sequenz maximal zulässige Wert. Dies bedeutet, dass unter normalen Umständen die Statusübertragung basierend auf dem Binärprotokoll immer bevorzugt wird, es sei denn, die vom Joiner-Knoten angeforderte Transaktion ist in keinem Mitglied der Gruppe vorhanden Wenn die Klonfunktion zu diesem Zeitpunkt deaktiviert ist, wird die verteilte Wiederherstellung durch Klonen ausgelöst, unabhängig davon, auf welchen Wert die Systemvariable eingestellt ist. Wenn beispielsweise ein neu initialisierter Server den Beitritt zur Gruppe beantragt, tun Sie dies Installieren Sie es nicht, wenn Sie die Klonfunktion und -konfiguration nicht verwenden möchten. Um eine maximale Verfügbarkeit des Boot-Knotens sicherzustellen, wird empfohlen, alle aktuellen und zukünftigen Cluster-Knoten so einzurichten, dass sie Remote-Klonvorgänge unterstützen. Wenn also später ein Server dem Cluster beitritt, kann der Remote-Klonvorgang verwendet werden, um schnell auf die neuesten Daten im Cluster zuzugreifen.
Der Remote-Klonvorgang löscht vom Benutzer erstellte Tablespaces und Daten im Beitrittsknoten, bevor Daten vom Boot-Knoten an den Beitrittsknoten übertragen werden. Wenn der Vorgang mittendrin unerwartet beendet wird, sind auf dem verbindenden Knoten möglicherweise nur noch teilweise oder gar keine Daten mehr vorhanden. Dieses Problem kann behoben werden, indem der Remote-Klonvorgang, den die Gruppenreplikation automatisch ausführt, erneut ausgeführt wird.
Dies gilt hauptsächlich für den Fall, dass beim Remote-Klonen ein Datenspeicherpfad mithilfe der Unteroption DATADIRECTORY angegeben wird. Wenn der Pfad angegeben wird, werden die Daten im angegebenen Verzeichnis gespeichert, d. h. die Daten nach dem Klonen nicht Bezieht sich auf die Instanz, in der der Klon ausgeführt wird, und muss manuell gestartet werden. Geben Sie datadir an, um das Verzeichnis zu speichern, in dem die Klondaten gespeichert werden. Natürlich kann das MGR-Plug-in den Wiederholungsvorgang des Remote-Klons automatisch durchführen (Sie müssen sicherstellen, dass der Klonvorgang nicht die Unteroption DATA DIRECTORY angibt. In diesem Fall werden die Remote-Klondaten überschrieben. Bearbeiten Sie die Daten des Remote-Klonservers. Nachdem der Remote-Klonvorgang abgeschlossen ist, wird der Remote-Klonserver gelöscht wird basierend auf den geklonten Daten automatisch neu gestartet. Obwohl das Klon-Plug-in in Verbindung mit der Gruppenreplikation verwendet wird, um die Verwaltung und Wartung der Gruppenreplikation stärker zu automatisieren, erfordert das Klon-Plug-in nicht die Ausführung im Cluster (sondern das MGR-Plug-in). muss installiert sein).
Für die Gruppenreplikation müssen Sie bei der Verwendung des Klon-Plug-Ins für die verteilte Wiederherstellung die folgenden Punkte und Unterschiede beachten:
Der vorhandene Clusterknoten und der beitretende Knoten müssen über die folgenden Punkte und Unterschiede verfügen Klon-Plugin installiert und aktiviert.
Der Boot-Knoten und der beitretende Knoten müssen auf demselben Betriebssystem ausgeführt werden und über dieselbe MySQL-Server-Version verfügen (Muss MySQL 8.0.17 oder höher sein, um das Klon-Plugin zu unterstützen). Daher funktioniert das Klonen nicht für Cluster, deren Mitglieder unterschiedliche Versionen von MySQL ausführen.
Auf dem Boot-Knoten und dem Beitrittsknoten muss das Plugin „Gruppenreplikation“ installiert und aktiviert sein, und alle anderen auf dem Boot-Knoten aktivierten Plugins (z. B. Schlüsselring-Plugins) müssen auch auf dem Beitrittsknoten aktiv sein.
Wenn die verteilte Wiederherstellung für die Verwendung von SSL konfiguriert ist (groupreplicationrecoveryusessl=ON), wendet die Gruppenreplikation diese Einstellung auf Remote-Klonvorgänge an. Die Gruppenreplikation konfiguriert die Einstellungen der Klon-SSL-Optionen (clonesslca, clonesslcert und clonesslkey) automatisch so, dass sie mit den Einstellungen der entsprechenden verteilten Gruppenreplikationswiederherstellungsoptionen (groupreplicationrecoverysslca, groupreplicationrecoverysslcert und groupreplicationrecoverysslkey) übereinstimmen.
Es ist nicht erforderlich, die Liste der gültigen Boot-Knoten in der Systemvariablen clonevaliddonor_list auf dem beitretenden Knoten festzulegen, um dem Cluster beizutreten. Die Gruppenreplikation konfiguriert diese Einstellung automatisch, nachdem MGR automatisch den Startknoten aus den vorhandenen Clusterknoten auswählt. Beachten Sie, dass der Remote-Klonvorgang den Hostnamen und Port des SQL-Protokolls des Servers verwendet, nicht die Adresse und den Port für die interne Kommunikation zwischen Clustermitgliedern.
Das Klon-Plugin verfügt über eine Reihe von Systemvariablen, um die Netzwerklast und die Leistungsauswirkungen von Remote-Klonvorgängen zu verwalten. Diese Einstellungen werden nicht mit der Gruppenreplikation konfiguriert, sodass Sie sie anzeigen und bei Bedarf festlegen können, oder Sie können sie als Standardeinstellungen festlegen. Wenn Sie einen Remote-Klonvorgang für die verteilte Wiederherstellung verwenden, wird die cloneenablecompression-Einstellung des Klon-Plug-Ins auf die angewendet Der Vorgang wirkt sich stattdessen auf die vorhandenen konfigurierten Komprimierungseinstellungen für die Gruppenreplikation aus.
Um Remote-Klonvorgänge auf beitretenden Knoten aufzurufen, verwendet die Gruppenreplikation den internen Benutzer mysql.session, der bereits über CLONE_ADMIN-Berechtigungen verfügt, sodass keine spezielle Einrichtung erforderlich ist.
Als Klonbenutzer auf dem Startknoten für einen Remote-Klonvorgang verwendet die Gruppenreplikation den für die verteilte Wiederherstellung eingerichteten Replikationsbenutzer. Daher müssen diesem Replikationsbenutzer BACKUP_ADMIN-Berechtigungen für alle klonfähigen Clusterknoten erteilt werden. Wenn Sie einen Knoten für die Gruppenreplikation konfigurieren und ein Beitrittsknoten vorhanden ist, sollten Sie diese Berechtigung auch dem Replikationsbenutzer auf diesem Knoten erteilen, da der Beitrittsknoten nach dem Beitritt zum Cluster als Startknoten für andere Beitrittsknoten fungieren kann. Für die verteilte Wiederherstellung wird auf jedem Clusterknoten derselbe Replikationsbenutzer verwendet. Um einem Replikationsbenutzer auf einem vorhandenen Knoten diese Berechtigung zu erteilen, führen Sie diese Anweisung einzeln auf jedem Clusterknoten mit deaktivierter Binärprotokollierung oder auf dem Primärknoten eines Clusters mit aktivierter Binärprotokollierung aus. Die folgenden Sätze:
GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';
Wenn Sie CHANGE MASTER TO verwendet haben, um Replikationsbenutzeranmeldeinformationen auf dem Server anzugeben, der die Benutzeranmeldeinformationen bereitgestellt hat, bevor Sie STARTGROUPREPLICATION verwendet haben, stellen Sie sicher, dass Sie die Benutzeranmeldeinformationen aus dem Replikationsmetadaten-Repository löschen, bevor Sie Remote-Klonvorgänge durchführen. Stellen Sie außerdem sicher, dass „groupreplicationstartonboot=OFF“ für das beitretende Mitglied festgelegt ist. Wenn die Benutzeranmeldeinformationen nicht deaktiviert sind, werden sie während des Remote-Klonvorgangs an das beitretende Mitglied übertragen. Ein GroupReplicationRecovery-Kanal kann dann versehentlich mit den gespeicherten Anmeldeinformationen des ursprünglichen Mitglieds oder eines davon geklonten Mitglieds gestartet werden. Beim automatischen Starten der Gruppenreplikation beim Serverstart (auch nach einem Remote-Klonvorgang) werden die gespeicherten Benutzeranmeldeinformationen sowie Anmeldeinformationen für die verteilte Wiederherstellung verwendet, wenn diese nicht im Befehl START GROUPREPLICATION angegeben sind.
Nachdem die Gruppenmitglieder so eingestellt wurden, dass sie das Klonen unterstützen, gibt die Systemvariable „groupreplicationclonethreshold“ einen Schwellenwert an, der angibt, wie viele Transaktionen Remote-Klonvorgänge bei der verteilten Wiederherstellung verwenden sollen. Wenn die Anzahl der Transaktionen zwischen dem Bootstrap-Knoten und dem beitretenden Knoten größer ist als diese Zahl, wird ein Remote-Klonvorgang verwendet, um den Status auf den beitretenden Knoten zu übertragen, sofern dies technisch möglich ist. Die Gruppenreplikation berechnet anhand der gtiexecuted-Gruppe vorhandener Gruppenmitglieder, ob der Schwellenwert überschritten wurde. Mithilfe von Remote-Klonvorgängen können bei großen Transaktionslücken neue Mitglieder zum Cluster hinzugefügt werden, ohne dass die Daten des Clusters zuvor manuell auf den Server übertragen werden müssen, und es kann auch nacheilenden Knoten ermöglichen, die Daten effizienter aufzuholen.
Die Standardeinstellung der Gruppenreplikationssystemvariablen groupreplicationclone_threshold ist sehr hoch (maximal zulässige Sequenznummer von Transaktionen in GTID), sodass das Klonen effektiv deaktiviert wird, wenn es möglich ist, den Status aus dem Binärprotokoll zu übertragen. Damit die Gruppenreplikation einen Remote-Klonvorgang auswählen kann, der besser für die Statusübertragung geeignet ist, legen Sie eine Systemvariable fest, die angibt, wie viele Transaktionen als Transaktionsintervall für das Klonen verwendet werden sollen.
PS:
Verwenden Sie keine niedrigeren Einstellungen für groupreplicationclone_threshold in einem aktiven Cluster. Wenn im Cluster mehr als ein Schwellenwert an Transaktionen auftritt, während ein Remote-Klonvorgang ausgeführt wird, löst das beitretende Mitglied den Remote-Klonvorgang nach einem Neustart erneut aus und kann auf unbestimmte Zeit fortgesetzt werden. Um dies zu vermeiden, stellen Sie sicher, dass Sie den Schwellenwert auf eine zuverlässige Zahl festlegen, die größer ist als die erwartete Anzahl von Transaktionen im Cluster während des Zeitraums, den der Remote-Klonvorgang dauert.
Wenn eine Statusübertragung aus dem Binärprotokoll des Boot-Knotens nicht möglich ist, versucht die Gruppenreplikation, unabhängig vom aktuellen Schwellenwert einen Remote-Klonvorgang durchzuführen, z. B. weil sich die für den Beitritt zu einem Mitglied erforderlichen Transaktionen im Binärprotokoll eines beliebigen Mitglieds befinden bestehendes Gruppenmitglied Es sind keine verfügbar. Die Gruppenreplikation identifiziert dies basierend auf dem gtidpurged-Satz vorhandener Gruppenmitglieder. Die Systemvariable „groupreplicationclonethreshold“ kann nicht zum Deaktivieren des Klonens verwendet werden, wenn die erforderlichen Transaktionen nicht in der binären Protokolldatei eines Mitglieds verfügbar sind, da in diesem Fall das Klonen die einzige Möglichkeit ist, Daten manuell an den beitretenden Knoten zu übertragen
Nach dem Einrichten von Clusterknoten und dem Verbinden von Knoten zum Klonen verwaltet die Gruppenreplikation Remote-Klonvorgänge. Abhängig von der Größe der Daten dauert der Remote-Klonvorgang einige Zeit.
Die Tabelle performanceschema.cloneprogress zeichnet jede Phase des gesamten Klonvorgangs und die entsprechenden Phaseninformationen auf. Jede Phase generiert eine Zeile mit Datensätzen (beachten Sie, dass diese Tabelle nur die Prozessinformationen eines Klonvorgangs aufzeichnet. Beim nächsten Klonvorgang ausgeführt wird, werden die letzten Informationen überschrieben. Wenn „groupreplicationstartonboot=OFF“ auf dem beitretenden Knoten festgelegt ist, beispielsweise weil Anmeldeinformationen des Replikationsbenutzers in der START GROUPREPLICATION-Anweisung angegeben wurden, muss START GROUPREPLICATION nach einem Neustart erneut manuell veröffentlicht werden. Wenn „groupreplicationstartonboot=ON“ und andere zum Starten der Gruppenreplikation erforderliche Einstellungen in der Konfigurationsdatei oder mithilfe der SET PERSIST-Anweisung festgelegt sind, ist kein Eingriff erforderlich und der Prozess wird automatisch fortgesetzt, wobei der beitretende Knoten in den Online-Status versetzt wird.
Der Remote-Klonvorgang klont verschiedene Datendateien im Datenverzeichnis des Boot-Knotens auf den beitretenden Knoten (die Tabelle kann einige Konfigurationsinformationen und Benutzerdaten usw. enthalten). Allerdings werden die in Konfigurationsdateien gespeicherten Gruppenreplikations-Mitgliedschaftseinstellungen (z. B. die lokale Adresskonfiguration der Gruppenreplikation usw.) nicht geklont und es werden auch keine Änderungen am beitretenden Knoten vorgenommen. Das heißt, die Konfiguration im Zusammenhang mit der Gruppenreplikation muss von Ihnen selbst konfiguriert werden und darf nicht mit vorhandenen Mitgliedern im Cluster in Konflikt geraten. Der Remote-Klonvorgang ist nur für das Klonen von Datendateien verantwortlich und klont keine Konfigurationsinformationen (natürlich, wenn einige Konfigurationsinformationen vorhanden sind). wird in der Tabelle gespeichert, für Klonvorgänge wird es auch als Daten geklont). 如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集： 引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。 如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。 ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。） 组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。 在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件： 在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。 Das obige ist der detaillierte Inhalt vonAnalyse der verteilten MySQL-Wiederherstellungsinstanz. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!RESET SLAVE FORCHANNEL group_replication_recovery;
RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）
3.4克隆的其他用处
INSTALL PLUGIN group_replication SONAME'group_replication.so';
MySQL ändert den Namen der Datentabelle
MySQL erstellt eine gespeicherte Prozedur
Der Unterschied zwischen Mongodb und MySQL
So überprüfen Sie, ob das MySQL-Passwort vergessen wurde
MySQL-Datenbank erstellen
MySQL-Standard-Transaktionsisolationsstufe
Der Unterschied zwischen SQL Server und MySQL
mysqlPasswort vergessen
