Die meisten unserer MySQL-Onlineumgebungen verwenden Version 5.7.18. Diese Version hat viele Fehler behoben, aber es gibt immer noch viele Fehler bei der Master-Slave-Replikation, insbesondere einige Fehler bei der Gruppenreplikation und der parallelen Replikation. Entsprechende Verbesserungen und Korrekturen wurden in Version 5.7.19 vorgenommen. Daher wird empfohlen, mgr- und gleichzeitige Replikationsfunktionen in Versionen vor 5.7.19 nicht zu verwenden. Wenn Sie sie verwenden, wird empfohlen, auf Versionen nach 5.7.19 (einschließlich) zu aktualisieren.
Das Hauptproblem, auf das ich hier gestoßen bin, waren unerklärliche Datensynchronisierungsprobleme, die Unfähigkeit, Stop-Slave auszuführen, Dateninkonsistenz und andere Phänomene. Nach der Überprüfung stellte ich fest, dass dies durch einen Versionsfehler verursacht wurde. Daher schloss ich die gleichzeitige Replikation für die Online-Slave-Bibliothek und aktualisierte die Version des Systems, das nicht online war. Das Risiko ist sehr, sehr hoch, also nehmen Sie es bitte ernst.
Referenzhandbuch: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-19.html
Referenzen: Siehe auch: Fehler Nr. 84107.
Replikation: Im Falle einer verzögerten Initialisierung des Group Replication-Plugins, das im Single-Primary-Modus bereitgestellt wurde, konnten Sekundärserver Schreibvorgänge über einen asynchronen Replikationskanal durchführen, was bei der normalen Initialisierung des Group Replication-Plugins nicht zulässig ist. (Fehler Nr. 26314756)
Replikation: Mit für Vorfallprotokollereignisse generierten GTIDs konnte der MySQL-Fehlercode 1590 (ER_SLAVE_INCIDENT) mit der Startoption --slave-skip-errors=1590 auf einem Replikations-Slave nicht übersprungen werden. (Fehler Nr. 26266758)
Replikation: Eine USE-Anweisung, die auf eine SET GTID_NEXT-Anweisung folgte, hatte manchmal keine Wirkung. (Fehler Nr. 26128931)
Replikation: Gruppen können jetzt Mitglieder mit unterschiedlichen Serverversionen enthalten, damit Sie Online-Upgrades einer Replikationsgruppe durchführen können. Die Regeln für die Kombination von Mitgliedern in einer Gruppe mit unterschiedlichen Versionen lauten:
Wenn Sie eine Gruppe mit 8.0 Mitgliedern haben, können Sie kein 5.7-Mitglied hinzufügen
Wenn Sie eine Gruppe mit 5.7-Mitgliedern haben, können Sie ein 8.0-Mitglied hinzufügen, es bleibt jedoch im schreibgeschützten Modus. Das Schreiben in dieses Mitglied ist gefährlich, während die Gruppe mehrere Serverversionen enthält, und sollte vermieden werden.
Wenn in einer Gruppe mit nur einem Primärmitglied das aktuelle Primärmitglied die Gruppe verlässt und ein neues Primärmitglied gewählt werden muss, wird das Primärmitglied zunächst aus den Mitgliedern mit niedrigerer Version ausgewählt. Wenn kein Mitglied mit niedrigerer Version gefunden wird, wird das Primärmitglied aus den Mitgliedern mit neuerer Version ausgewählt. (Fehler Nr. 25876807)
Replikation: Wenn auf einem MySQL-Server nach dem Start binlog_checksum=NONE gesetzt war und dann die Gruppenreplikation gestartet wurde, blieb der Server bei Auftreten eines Fehlers im Status RECOVERING und konnte nicht heruntergefahren werden. (Fehler Nr. 25793366, Fehler Nr. 85667)
Replikation: In einer Gruppenreplikationskonfiguration, in der eine zirkuläre asynchrone Replikation zwischen Mitgliedern verschiedener Replikationsgruppen implementiert wurde, wurden Ansichtsänderungsprotokollereignisse wiederholt zwischen den Gruppen repliziert, wobei jedes Mal neue GTIDs generiert wurden. Der Fix stellt sicher, dass Ansichtsänderungsprotokollereignisse außerhalb der benannten Replikationsgruppe, in der sie auftreten, ignoriert werden und niemals neue GTIDs generieren. (Fehler Nr. 25674926)
Referenzen: Siehe auch: Fehler Nr. 26049695, Fehler Nr. 25928854, Fehler Nr. 25721175.
Replikation: Beim ersten Start des MySQL-Servers nach einer Installation von RPM ist das Plugin zur Passwortüberprüfung standardmäßig aktiviert (gilt nur für RPM-Installationen). Wenn zu diesem Zeitpunkt bereits die Binärprotokollierung aktiviert war, wurde die Aktivierung protokolliert, obwohl Plugin-Aktivierungen nicht im Binärprotokoll aufgezeichnet werden sollten. (Fehler Nr. 25672750)
Replikation: In einem Setup, in dem die Gruppenreplikation mit einem einzigen Primär mit der asynchronen Replikation kombiniert wurde, z. B. wenn S1 und S2 eine Gruppe bildeten und S2 und S3 als Master und Slave fungierten, akzeptierten Sekundäre wie S2 Transaktionen und diese konnten dann in die Gruppe gelangen. Der Fix verhindert, dass Sekundäre einen asynchronen Replikationskanal erstellen, wenn sie zu einer Gruppe mit einem einzigen Primär gehören, und die Gruppenreplikation kann nicht gestartet werden, wenn die asynchrone Replikation ausgeführt wird. (Fehler Nr. 25574200, Fehler Nr. 85047)
Referenzen: Siehe auch: Fehler Nr. 86325, Fehler Nr. 26078602.
Replikation: Falls ein Mitglied einer Gruppe nicht beitreten konnte, wurde es nicht gestoppt und akzeptierte weiterhin Transaktionen. Um dies zu vermeiden, legen Sie für Ihre Mitglieder in der Datei my.cfg super_read_only=1 fest. Die Gruppenreplikation prüft diese Einstellung jetzt bei erfolgreichem Start und setzt super_read_only=0. Dadurch wird sichergestellt, dass Mitglieder, die einer Gruppe nicht erfolgreich beitreten, keine Transaktionen akzeptieren können. (Fehler Nr. 25474736, Fehler Nr. 84728)
Replikation: Wenn das Binärprotokoll auf einem Masterserver rotiert wurde und auf der Partition, auf der die Binärprotokolldatei gespeichert war, ein Festplattenausfall auftrat, konnte der Server unerwartet angehalten werden. Der Fix fügt eine Prüfung auf das Vorhandensein des Binärprotokolls hinzu, wenn der Dump-Thread zur nächsten Binärprotokolldatei wechselt. Wenn das Binärprotokoll deaktiviert ist, werden alle Binärprotokolle bis zum aktuell aktiven Protokoll an den Slave übertragen und ein Fehler an den Empfänger-Thread zurückgegeben. (Fehler Nr. 25076007)
Replikation: Interleaved-Transaktionen konnten manchmal den Slave-Applikator blockieren, wenn die Transaktionsisolationsebene auf REPEATABLE-READ eingestellt war. (Fehler Nr. 25040331)
Replikation: Wenn eine Relay-Log-Indexdatei Relay-Log-Dateien benannte, die nicht existierten, führte RESET SLAVE ALL manchmal nicht zu einer vollständigen Bereinigung. (Fehler Nr. 24901077)
Replikation: Die Systemvariable „slave_skip_errors“ ließ keine Fehlernummern größer als 3000 zu. Danke an Tsubasa Tanaka für den Patch. (Fehler Nr. 24748639, Fehler Nr. 83184)
Replikation: Wenn mysqlbinlog mit der Option --raw aufgerufen wird, wird die Ausgabedatei erst gelöscht, wenn der Prozess beendet ist. Wenn es jedoch zusätzlich mit der Option --stop-never aufgerufen wird, wird der Prozess nie beendet, sodass nie etwas in die Ausgabedatei geschrieben wird. Jetzt wird die Ausgabe nach jedem Ereignis gelöscht. (Fehler #24609402)
Replikation: Ein Speicherleck in mysqlbinlog wurde behoben. Das Leck trat bei der Verarbeitung von falschen Rotationsereignissen auf oder bei der Verwendung von --raw, und die Zielprotokolldatei konnte nicht erstellt werden. Das Leck trat nur bei der Verarbeitung von Ereignissen von einem Remote-Server auf. Vielen Dank an Laurynas Biveinis für seinen Beitrag zur Behebung dieses Fehlers. (Fehler Nr. 24323288, Fehler Nr. 82283)
Replikation: Ein Slave-Server konnte noch nicht angewendete Ereignisse verlieren, wenn MASTER_AUTO_POSITION=0, beide Replikationsthreads gestoppt und die Anwendungsverzögerung mit CHANGE MASTER TO MASTER_DELAY=N geändert wurde. (Fehler #23203678, Fehler #81232)
Referenzen: Siehe auch: Fehler Nr. 25340185, Fehler Nr. 84375.
Replikation: Die Übertragung großer GCS-Nachrichten konnte so lange dauern, dass es so aussah, als sei der Absender abgeschaltet. (Fehler Nr. 22671846)
Replikation: Multithread-Slaves konnten nicht mit kleinen Warteschlangengrößen unter Verwendung von slave_pending_jobs_size_max konfiguriert werden, wenn sie jemals Transaktionen verarbeiten mussten, die größer als diese Größe waren. Jedes Paket, das größer als slave_pending_jobs_size_max war, wurde mit dem Fehler ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX abgelehnt, selbst wenn das Paket kleiner als das durch slave_max_allowed_packet festgelegte Limit war.
Mit diesem Fix wird „slave_pending_jobs_size_max“ zu einem weichen Limit statt einem harten Limit. Wenn die Größe eines Pakets „slave_pending_jobs_size_max“ überschreitet, aber kleiner als „slave_max_allowed_packet“ ist, wird die Transaktion zurückgehalten, bis alle Slave-Worker leere Warteschlangen haben, und dann verarbeitet. Alle nachfolgenden Transaktionen werden zurückgehalten, bis die große Transaktion abgeschlossen ist. Die Warteschlangengröße für Slave-Worker kann daher begrenzt werden, während gelegentlich noch größere Transaktionen möglich sind. (Fehler #21280753, Fehler #77406)
Replikation: Ein Vorfall, der die Replikation unterbrach, wurde nicht mit einer GTID in das Binärprotokoll geschrieben, sodass es nicht möglich war, das Ereignis mit SET gtid_next=value zu überspringen. Stattdessen war es notwendig, die Relay-Protokolldatei und die Relay-Protokollpositionen direkt festzulegen. Dies bedeutete, dass bei aktivierter Autopositionierung diese zuerst deaktiviert, dann die Relay-Protokolldatei und -position festgelegt und schließlich die Autopositionierung wieder aktiviert werden musste.
In solchen Fällen schreibt MySQL das Ereignis nun in den Anweisungscache, sodass vor dem Leeren eine GTID dafür generiert und geschrieben wird und der Slave-Applier mit der Änderung arbeitet. Anschließend können Benutzer das Ereignis mit der SQL-Anweisung SET gtid_next=value, gefolgt von BEGIN und COMMIT, überspringen. (Fehler #19594845)
Replikation: In bestimmten Fällen konnte der Master einen last_committed-Wert in das Binärprotokoll schreiben, der kleiner war als er hätte sein sollen. Dies konnte dazu führen, dass der Slave parallele Transaktionen ausführte, die nicht hätten ausgeführt werden sollen, was zu Inkonsistenzen oder anderen Fehlern führte. (Fehler Nr. 84471, Fehler Nr. 25379659)
Replikation: Bei Verwendung von group_replication_ip_whitelist=AUTOMATIC werden IPs im privaten Netzwerk automatisch zugelassen, einige IP-Adressen der Klasse C wurden jedoch nicht korrekt zugelassen. (Fehler Nr. 84329, Fehler Nr. 25503458)
Replikation: Wenn einer vorhandenen GTID_NEXT-Transaktion vom Server eine konfliktbehaftete GTID zugewiesen wurde, generierte die Gruppenreplikation eine Assert, wenn zwei Transaktionen mit derselben GTID erkannt wurden. Dies lag daran, dass die Gruppenreplikation die GTID nach der Konflikterkennung generiert, was später ist als bei der Master/Slave-Replikation. Der Fix lockert einige Bedingungen, sodass sie nur aufgerufen werden, wenn das Commit abgeschlossen ist, und es wurde eine Meldung hinzugefügt, die Sie benachrichtigt, wenn eine GTID bereits verwendet wurde. (Fehler Nr. 84153, Fehler Nr. 25232042)
Replikation: Der Replikationsanwendungsthread gibt den Fehler 3002 ER_INCONSISTENT_ERROR zurück, wenn zwischen der erwarteten Fehlernummer und der tatsächlichen Fehlernummer ein Unterschied besteht. Dieser Fehler kann nun ignoriert werden, indem 3002 mit slave_skip_errors verwendet wird. (Fehler Nr. 83186, Fehler Nr. 24753281)
Replikation: MySQL verlor seine GTID-Position nach einem Neustart, als zum Laden der Daten ein Dump von mysqldump verwendet wurde.
Um dieses Problem zu vermeiden, wird die Tabelle mysql.gtid_executed jetzt automatisch von den von mysqldump erstellten Dumps ausgeschlossen. (Fehler Nr. 82848, Fehler Nr. 24590891)
Referenzen: Siehe auch: Fehler Nr. 87455, Fehler Nr. 26643180.
Replikation: Die Beschädigung von Relay-Protokollen für einen Kanal bei der Multi-Source-Replikation führte dazu, dass gute Kanäle bei einem Serverneustart nicht initialisiert wurden. Darüber hinaus konnte der Server bei der Ausführung mit --skip-slave-start=false auch keine Slave-Threads für die Kanäle starten, die in gutem Zustand waren, obwohl er die Slave-Threads für alle guten Kanäle hätte starten sollen.
Jetzt versucht der Server ungeachtet etwaiger Fehler auf anderen Kanälen, Kanäle in gutem Zustand zu erstellen und zu initialisieren, und startet Slave-Threads für die guten Kanäle, wenn --skip-slave-start deaktiviert ist. Als Teil dieses Fixes werden START SLAVE und STOP SLAVE, die auf allen Kanälen funktionieren sollen, auch so geändert, dass sie auf allen guten Kanälen weiter ausgeführt werden, selbst wenn sie darunter schlechte Kanäle finden. (Fehler Nr. 82209, Fehler Nr. 24285104)
Replikation: Der SQL-Thread konnte eine Teiltransaktion nicht per GTID überspringen. (Fehler Nr. 81119, Fehler Nr. 25800025)
In Debian-Client-Paketen fehlten Informationen zu Konflikten mit akonadi-backend-mysql-Paketen. (Fehler Nr. 26002288)
Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.
