Ein kurzer Vortrag über die halbsynchrone MySQL-Replikation

Einführung

MySQL erreicht eine hohe Verfügbarkeit des Speichersystems durch Replikation. Derzeit unterstützt MySQL die folgenden Replikationsmethoden:

1. Asynchrone Replikation: Das Prinzip ist am einfachsten und die Leistung am besten. Allerdings besteht eine hohe Wahrscheinlichkeit, dass die Daten zwischen dem Primär- und dem Backup-Server inkonsistent sind.
2. Halbsynchrone Replikation: Im Vergleich zur asynchronen Replikation geht bei der halbsynchronen Replikation eine gewisse Leistung verloren und die Datenkonsistenz zwischen dem Primär- und dem Standby-Server wird verbessert (in einigen Fällen sind die Primär- und Standby-Daten immer noch inkonsistent).
3. Gruppenreplikation: Erreichen Sie eine starke Konsistenz der verteilten Datenreplikation basierend auf dem Paxos-Algorithmus. Solange die Mehrheit der Maschinen aktiv ist, ist die Verfügbarkeit des Systems gewährleistet. Im Vergleich zur halbsynchronen Replikation weist die Gruppenreplikation eine höhere Datenkonsistenz und Systemverfügbarkeit auf.
   

In diesem Artikel wird hauptsächlich die halbsynchrone MySQL-Replikation behandelt.

Der grundlegende Prozess der semisynchronen Replikation

Die Implementierung der halbsynchronen MySQL-Replikation basiert auf der asynchronen MySQL-Replikation. MySQL unterstützt zwei leicht unterschiedliche Arten der halbsynchronen Replikation: AFTER_SYNC und AFTER_COMMIT (gesteuert durch rpl_semi_sync_master_wait_wait_point).

Wenn die halbsynchrone Replikation aktiviert ist, wartet der Master vor der Rückkehr auf die Antwort oder ein Timeout des Slaves. Wenn beim Slave ein Timeout auftritt, degeneriert die semisynchrone Replikation zu einer asynchronen Replikation. Dies ist auch ein Problem bei der halbsynchronen MySQL-Replikation. In diesem Artikel wird nicht auf die Situation eingegangen, in der bei Salve eine Zeitüberschreitung auftritt (es wird nicht auf die asynchrone Replikation eingegangen).

Grundlegender Prozess der halbsynchronen Replikation im AFTER_SYNC-Modus

Der AFTER_SYNC-Modus ist ein halbsynchroner Replikationsmodus, der von MySQL 5.7 unterstützt wird und auch der standardmäßige halbsynchrone Replikationsmodus von MySQL 5.7 ist:

• Bereiten Sie die Transaktion in der/den Speicher-Engine(s) vor.
  
• Schreiben Sie die Transaktion in das Binärprotokoll und leeren Sie das Binärprotokoll auf die Festplatte.
  
• Warten Sie, bis mindestens ein Slave den Empfang der Binlog-Ereignisse für die Transaktion bestätigt.
  
• Übernehmen Sie die Transaktion in die Speicher-Engine(s).
  

Grundlegender Prozess der halbsynchronen Replikation im AFTER_COMMIT-Modus

Die halbsynchrone Replikation von MySQL 5.5 und 5.6 unterstützt nur AFTER_COMMIT:

• Bereiten Sie die Transaktion in der/den Speicher-Engine(s) vor.
  
• Schreiben Sie die Transaktion in das Binärprotokoll und leeren Sie das Binärprotokoll auf die Festplatte.
  
• Übernehmen Sie die Transaktion in die Speicher-Engine(s).
  
• Warten Sie, bis mindestens ein Slave den Empfang der Binlog-Ereignisse für die Transaktion bestätigt.
  

Zusammenfassung von AFTER_SYNC und AFTER_COMMIT

AFTER_SYNC: Nachdem das Protokoll auf den Slave kopiert wurde, führt der Master erneut ein Commit durch.
Alle auf dem Master ausgeführten Transaktionen wurden auf den Slave kopiert.
Alle Transaktionen, die auf den Slave kopiert wurden, können möglicherweise nicht vom Master festgeschrieben werden (beispielsweise stürzt der Master ab, nachdem das Protokoll auf den Slave kopiert wurde, aber bevor das Festschreiben erfolgt ist).

AFTER_COMMIT: Nachdem der Master das Commit ausgeführt hat, wird das Protokoll auf den Slave kopiert.
Nicht alle auf dem Master ausgeführten Transaktionen werden notwendigerweise auf den Slave kopiert. (Beispielsweise stürzt der Master nach dem Commit ab, bevor er Zeit hat, das Protokoll auf den Slave zu kopieren.)
Alle Transaktionen, die auf den Slave kopiert wurden, müssen auf dem Master festgeschrieben werden.
Offensichtlich kann AFTER_COMMIT keine Datenkonsistenz garantieren, wenn der Master abstürzt (nachdem der Master das Commit ausgeführt hat, stürzt er ab, bevor er Zeit hat, das Protokoll auf den Slave zu kopieren). In diesem Artikel wird nur der AFTER_SYNC-Modus erläutert.
MySQL 5.7.3 unterstützt die Konfiguration der Anzahl von Slave-Antworten, auf die die halbsynchrone Replikation wartet: rpl_semi_sync_master_wait_slave_count.

Analyse abnormaler Situationen im AFTER_SYNC-Modus

Abnormale Situation 1: Nachdem der Master ausfällt, erfolgt der Master-Slave-Schalter.

Der Master führt die Transaktion T aus. Bevor das Binärprotokoll der Transaktion T auf die Festplatte geschrieben werden kann, stürzt der Master ab. Der Slave wird zum Master aufgewertet. Nach dem Neustart des Masters wird die Absturzwiederherstellung die Transaktion T zurücksetzen. Die Primär- und Sicherungsdaten sind konsistent.

Der Master führt die Transaktion T aus. Nachdem das Binärprotokoll der Transaktion T auf die Festplatte geschrieben wurde und bevor die ACK vom Slave empfangen wurde, stürzt der Master ab (es liegt ein ausstehendes Protokoll vor). Der Slave wird zum Master aufgewertet.

2.1 Der Slave hat das Binärprotokoll der Transaktion T nicht erhalten. Nach dem Neustart des Masters übermittelt die Absturzwiederherstellung das ausstehende Protokoll direkt. Die Primär- und Sicherungsdaten sind inkonsistent.

2.2 Der Slave hat das Binlog der Transaktion T erhalten. Die Primär- und Sicherungsdaten sind konsistent.

Abnormale Situation 2: Nach dem Absturz des Masters wird der Host nicht umgeschaltet. Betrachten Sie einfach 2.1 im Ausnahmefall 1.

Nach dem Neustart des Masters wird das Pendinglog direkt übermittelt. Zu diesem Zeitpunkt sind die Master- und Slave-Daten inkonsistent:

Der Slave stellt eine Verbindung zum Master her und erhält das Binärprotokoll der Transaktion T durch asynchrone Replikation. Die Primär- und Sicherungsdaten sind konsistent.
Der Slave hatte keine Zeit, das Binärprotokoll der Transaktion T zu kopieren. Wenn der Master erneut abstürzt, wird die Festplatte beschädigt. Die Master- und Slave-Daten sind inkonsistent und die Daten der Transaktion T gehen verloren.
Umgang mit abnormalen Situationen

Aus der einfachen Analyse der oben genannten abnormalen Situation wissen wir, dass die halbsynchrone Replikation die besondere Situation bewältigen muss, dass der Master abstürzt und neu gestartet wird und ein ausstehendes Protokoll vorliegt (ein Binärprotokoll, auf das der Slave nicht geantwortet hat).

Für den Fall, dass der Master ausfällt und der Master-Slave-Wechsel nicht durchgeführt wird:

Nach der Wiederherstellung nach einem Absturz wartet der Master auf Slave-Verbindungen und repliziert, bis mindestens ein Slave das Binärprotokoll aller festgeschriebenen Transaktionen repliziert hat. (SHOW MASTER STATUS auf dem Master und SELECT master_pos_wait() auf dem Slave).

Für den Fall, dass der Master ausfällt und ein Master-Slave-Wechsel durchgeführt wird:

Nach dem Neustart des alten Masters wird das Pendinglog während der Wiederherstellung nach einem Absturz zurückgesetzt. (Den nicht kopierten Teil des Binärprotokolls des Masters manuell abschneiden?)

denken

Warum führt der Master nach dem Neustart während der Wiederherstellung nach einem Absturz ein Pendinglog-Commit direkt durch, anstatt erneut zu versuchen, die Antwort des Slaves anzufordern?

Sowohl die asynchrone Replikation als auch die halbsynchrone Replikation von MySQL werden vom Slave ausgelöst, und der Slave stellt eine aktive Verbindung zum Master her, um das Binlog zu synchronisieren.

Es erfolgt kein Master-Slave-Wechsel und nach dem Neustart der Maschine ist es unmöglich herauszufinden, welche Maschine der Slave ist.
Bei einem Master-Slave-Wechsel ist dieser nicht mehr der Master und es kann sich kein Slave mehr mit ihm verbinden. Wenn Sie weiter warten, funktioniert es nicht richtig.

Zusammenfassen

Bei der halbsynchronen MySQL-Replikation treten die folgenden Probleme auf:

1. Wenn beim Slave eine Zeitüberschreitung auftritt, kommt es zur asynchronen Replikation.
2. Bei einem Ausfall des Masters ist die Datenkonsistenz nicht gewährleistet und erfordert eine manuelle Verarbeitung.
3. Die Replikation erfolgt seriell.

Da MySQL diese Probleme mit der Konsistenz der Master- und Standby-Daten aufweist, die die rund um die Uhr verfügbaren Hochverfügbarkeitsdienste von Internetunternehmen beeinträchtigen, haben große Unternehmen ihre eigenen „Patches“ auf den Markt gebracht: TDSQL von Tencent, PhxSQL von WeChat, AliSQL von Alibaba und InnoSQL von NetEase.

MySQL hat in MySQL 5.7 offiziell einen neuen Replikationsmodus eingeführt – MySQL Group Replication.

Verweise

Diskussion zur Datenkonsistenz der halbsynchronen MySQL-Replikation

MySQL-Hochverfügbarkeitslösungen

Verlustfreie halbsynchrone Replikation auf MySQL 5.7.2

Verbesserte halbsynchrone Replikation