Detaillierte Erläuterung der MySQL-Hochverfügbarkeitsarchitektur

Einführung

„Hohe Verfügbarkeit“ ist ein ewiges Thema im Internet. Lassen wir jetzt einmal beiseite, über MySQL zu sprechen. Es gibt mehrere häufig verwendete Lösungen, um die hohe Verfügbarkeit verschiedener Dienste sicherzustellen.

Dienstredundanz: Stellen Sie mehrere Kopien des Dienstes bereit und wechseln Sie zu anderen Knoten, wenn ein Knoten nicht verfügbar ist. Bei zustandslosen Diensten ist Dienstredundanz relativ einfach.

Dienstsicherung: Einige Dienste können nicht gleichzeitig in mehreren Laufzeiten vorhanden sein, z. B. der Nginx-Reverse-Proxy und die Leader-Knoten einiger Cluster. Zu diesem Zeitpunkt kann ein Backup-Dienst vorhanden sein und jederzeit in Bereitschaft sein.

Automatisches Umschalten: Wenn nach einer Dienstredundanz ein Knoten nicht verfügbar ist, ist ein schnelles Umschalten erforderlich.

Zusammengefasst handelt es sich um Redundanz + Failover.

MySQL-Hochverfügbarkeit

Die hohe Verfügbarkeit von MySQL basiert auf derselben Idee. Erstens müssen mehrere MySQL-Instanzen vorhanden sein, um Dienste bereitzustellen. Zweitens kann der Datenverkehr automatisch umgeschaltet werden, wenn eine Instanz ausfällt. Gleichzeitig stellt bei der Verwendung von MySQL als Speicher auch die Datensynchronisierung zwischen Knoten ein Problem dar (mit anderen Worten, alle zustandsbehafteten Dienste sind mit diesem Problem konfrontiert).

Ein Master und ein Backup:

Verschiedene Hochverfügbarkeitsarchitekturen von MySQL sind untrennbar mit der Datensynchronisierung zwischen MySQL-Instanzen verbunden. Daher stellen wir zunächst den Datensynchronisierungsprozess von MySQL in der einfachsten One-Active-One-Standby-Architektur vor.

Die obige Abbildung ist ein schematisches Diagramm der Master-Slave-Datensynchronisierung.

Der Masterknoten verfügt über einen Dump-Prozess, der die Daten im Binärprotokoll an den Slaveknoten sendet.

Der Slave-Knoten verfügt über einen IO-Prozess, der Daten empfängt und in das Relay-Protokoll schreibt.

Der SQL-Prozess des Slave-Knotens schreibt Daten gemäß dem Relay-Protokoll.

Hier müssen wir ein wenig erweitern. Binlog gibt es in drei Formen: Anweisung, Zeile und Gemischt.

Anweisung: zeichnet jede SQL-Anweisung im Binärprotokoll auf.

Zeile: zeichnet die spezifischen Daten jeder Zeilenänderung im Binärprotokoll auf.

Gemischt: MySQL unterscheidet flexibel, ob SQL oder bestimmte geänderte Datensätze aufgezeichnet werden müssen.

Wenn nur SQL aufgezeichnet wird, ist das Binärprotokoll kleiner. Beim Synchronisieren von Daten zwischen Master und Slave können jedoch einige SQL-Anweisungen aufgrund der Auswahl unterschiedlicher Indizes während des Datensynchronisierungsprozesses zu Dateninkonsistenzen führen. Durch das Aufzeichnen von Zeilen kann sichergestellt werden, dass bei der Master-Slave-Synchronisierung keine SQL-Semantikabweichung auftritt. Gleichzeitig können Daten aus Zeilenprotokollen leichter wiederhergestellt werden, aber Zeilen führen dazu, dass das Binärprotokoll zu groß wird.

Mehrere Modi der MySQL Master-Slave-Synchronisierung:

Asynchroner Modus:
Bei dieser Synchronisierungsstrategie gibt die Masterdatenbank die Ergebnisse direkt zurück, nachdem sie die Daten gemäß ihrem eigenen Prozess verarbeitet hat, ohne auf die Datensynchronisierung zwischen der Masterdatenbank und der Slavedatenbank warten zu müssen. Vorteile: Hohe Effizienz. Nachteil: Wenn der Masterknoten auflegt, verliert der Slaveknoten Daten. Vollständiger Synchronisierungsmodus: Die Masterdatenbank wartet, bis alle Slavedatenbanken die Ausführung der SQL-Anweisung und den ACK-Abschluss abgeschlossen haben, bevor sie eine Erfolgsmeldung zurückgibt. Vorteile: Gute Datenkonsistenzgarantie. Nachteile: Es führt zu Verzögerungen bei Datenvorgängen und reduziert den MySQL-Durchsatz. Halbsynchroner Modus: Die Masterdatenbank wartet, bis mindestens eine Slavedatenbank Daten in das Relay-Protokoll geschrieben hat und die ACK-Abschlüsse vorliegen, bevor sie das Ergebnis erfolgreich zurückgibt. Der halbsynchrone Modus liegt zwischen dem asynchronen und dem vollsynchronen Modus.

Die halbsynchrone Replikationslösung wurde in MySQL 5.5 eingeführt. Die Schritte der allgemeinen halbsynchronen Replikationslösung sind wie folgt:

Der Masterknoten schreibt Daten in Binlog und führt Synchronisierungsvorgänge durch. Der Master sendet Daten an den Slave-Knoten und führt die Transaktion der Master-Datenbank aus. Nach dem Erhalt der ACK gibt der Masterknoten die Daten an den Client zurück.

Dieser Datenübermittlungsmodus wird genannt: after_commit

Der after_commit-Modus weist ein Problem auf: Wenn die Master-Datenbank auf ACK wartet, wurde die Transaktion festgeschrieben und andere Transaktionen in der Master-Datenbank können die festgeschriebenen Daten lesen. Wenn zu diesem Zeitpunkt der Master abstürzt, gehen die Slave-Daten verloren und es kommt zu einem Master-Slave-Wechsel, sodass Phantom-Lesevorgänge auftreten. Um dieses Problem zu lösen, führt MySQL 5.7 einen neuen halbsynchronen Replikationsmodus ein: after_sync

Die oben genannten Probleme werden vermieden, indem die Transaktionsübermittlung der Hauptdatenbank nach ACK erfolgt. MySQL 5.7 führte auch den erweiterten Multithread-Slave-Modus (MTS) ein, wenn der Slave mit slave_parallel_workers > 0 konfiguriert ist und
global.slave_parallel_type = „LOGICAL_CLOCK“, wodurch Slave_parallel_workers-Arbeitsthreads dabei unterstützt werden können, vom Master im Relay-Protokoll übermittelte Transaktionen unter einem Schema gleichzeitig auszuführen, was die Effizienz der Master-Slave-Replikation erheblich verbessert. Die halbsynchrone Funktion von MySQL 5.7 kann erreicht werden durch
Der Parameter rpl_semi_sync_master_wait_slave_count konfiguriert die Anzahl der ACKs vom Slave-Knoten, die als Abschluss der Master-Slave-Synchronisierung gelten.

Da die MySQL-Master-Slave-Synchronisierungsdaten immer perfekter und effizienter werden, wird die erste MySQL-Hochverfügbarkeitsarchitektur eingeführt: Basierend auf MySQLs eigener Master-Slave-Synchronisierungslösung lautet eine häufig verwendete Bereitstellungsarchitektur: Benutzer greifen über VIP auf die Master- und Slave-Knoten zu, und jeder Knoten verwendet die Keepalved-Erkundung. Konfigurieren Sie die Master-Slave-Beziehung und synchronisieren Sie Daten.

Hochverfügbarkeitsarchitektur basierend auf MHA: Stellen Sie einen MHA-Manager-Knoten bereit und stellen Sie in jeder MySQL-Instanz MHA-Knotenknoten bereit. MHA kann innerhalb von Sekunden ein automatisches Failover durchführen. Natürlich hängt die Datensynchronisierung zwischen MySQL-Knoten auch von MySQLs eigener Datensynchronisierungsmethode ab.

MGR-Modus (MySQL Group Replication): Ich habe den Eindruck, dass MySQL-Verantwortliche optimistischer gegenüber der MGR-Clusterlösung sind, weiß aber nicht, welches Unternehmen in China sie bereits verwendet. Der MGR-Cluster besteht aus allen MySQL-Servern. Jeder Server verfügt über vollständige Replikatdaten. Die Replikate synchronisieren Daten basierend auf Protokollen im Zeilenformat und GTID und verwenden den Paxos-Algorithmus, um die Datenkonsistenz sicherzustellen. Die MGR-Architektur ist komplexer als die oben beschriebenen halbsynchronen und asynchronen Datensynchronisationsmethoden. Einzelheiten finden Sie auf der offiziellen Website

Zusammenfassen

Für die Hochverfügbarkeitsarchitektur von MySQL gibt es kein Patentrezept. Sie müssen lediglich die Prinzipien verstehen und eine Bereitstellungsarchitektur wählen, die zu Ihrem Geschäftsszenario passt.

Dies ist das Ende dieses Artikels mit der detaillierten Erklärung der MySQL-Hochverfügbarkeitsarchitektur. Weitere relevante Inhalte zur MySQL-Hochverfügbarkeitsarchitektur finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!