Gängige Master-Slave-Replikationsarchitekturen in MySQL 4

Replikationsarchitektur mit einem Master und mehreren Slaves

In einem Szenario, in dem der Druck der Leseanforderungen auf die Masterdatenbank sehr hoch ist, können Sie eine Lese- und Schreibtrennung erreichen, indem Sie eine Replikationsarchitektur mit einem Master und mehreren Slaves konfigurieren. Eine große Anzahl von Leseanforderungen, die keine hohe Echtzeitleistung erfordern, kann durch Lastausgleich auf mehrere Slave-Datenbanken verteilt werden (Leseanforderungen mit hohen Anforderungen an die Echtzeitleistung können aus der Masterdatenbank gelesen werden), wodurch der Lesedruck auf die Masterdatenbank verringert wird, wie in der folgenden Abbildung dargestellt.

Im Falle einer anormalen Ausfallzeit der Hauptdatenbank kann eine Slave-Datenbank auf die Hauptdatenbank umgeschaltet werden, um weiterhin Dienste bereitzustellen.

Im Master-Slave-Replikationsszenario kommt es zu einer Master-Slave-Verzögerung. Überlegen Sie, wie Sie das Problem lösen können.

Mehrstufige Replikationsarchitektur

Die Architektur mit einem Master, mehreren Slaves kann die Anforderungen der meisten Szenarien mit besonders hohem Druck bei Leseanfragen erfüllen. Wenn man bedenkt, dass die MySQL-Replikation erfordert, dass die Masterdatenbank BINLOG-Protokolle an den E/A-Thread der Slave-Datenbank sendet, steigen der E/A-Druck und der Netzwerkdruck der Masterdatenbank mit der Zunahme der Slave-Datenbanken (jede Slave-Datenbank verfügt über einen unabhängigen BINLOG-Dump-Thread in der Masterdatenbank, um Ereignisse zu senden). Die mehrstufige Replikationsarchitektur löst den zusätzlichen E/A- und Netzwerkdruck der Masterdatenbank im Szenario mit einem Master, mehreren Slaves. Die mehrstufige Replikationsarchitektur von MySQL ist in der folgenden Abbildung dargestellt.

Im Vergleich zur Architektur mit einem Master und mehreren Slaves fügt die mehrstufige Replikation nur eine sekundäre Masterdatenbank Master2 in der Mitte der Replikation der Masterdatenbank Master1 zu den Slavedatenbanken Slave1, Slave2 und Slave3 hinzu. Auf diese Weise muss die Masterdatenbank Master1 nur BINLOG-Protokolle an eine Slavedatenbank Master2 senden, was den Druck auf die Masterdatenbank Master1 verringert. Die sekundäre Masterbibliothek Master2 sendet dann das BINLOG-Protokoll an die I/O-Threads aller Slavebibliotheken Slave1, Slave2 und Slave3.

Die mehrstufige Replikation löst die E/A-Last und den Netzwerkdruck der Master-Datenbank im Szenario mit einem Master und mehreren Slaves. Natürlich hat sie auch Nachteile: Die herkömmliche Replikation von MySQL ist asynchron. Im Szenario der mehrstufigen Replikation werden die Daten der Master-Datenbank zweimal repliziert, bevor sie die Slave-Datenbanken Slave1, Slave2 und Slave3 erreichen. Die Verzögerung während dieses Zeitraums ist größer als bei nur einer Replikation im Szenario mit einem Master und mehreren Slaves.

Sie können die Latenz der mehrstufigen Replikation reduzieren, indem Sie BLACKHOLE als Tabellen-Engine auf der sekundären Masterdatenbank Master2 auswählen. Wie der Name schon sagt, ist die BLACKHOLE-Engine eine „Black Hole“-Engine. Daten, die in die BLACKHOLE-Tabelle geschrieben werden, werden nicht auf die Festplatte geschrieben. Die BLACKHOLE-Tabelle ist immer eine leere Tabelle. INSERT-, UPDATE- und DELETE-Operationen zeichnen nur Ereignisse in BINLOG auf.

CREATE TABLE `Benutzer` (
	`id` int NICHT NULL AUTO_INCREMENT PRIMARY KEY,
	`name` varchar(255) NICHT NULL STANDARD '',
	`Alter` tinyint unsigned NICHT NULL STANDARD 0
)ENGINE=BLACKHOLE Zeichensatz=utf8mb4;
INSERT INTO `Benutzer` (`Name`,`Alter`) Werte("itbsl", "26");
SELECT * FROM `Benutzer`;

Wie Sie sehen, gibt es in der Benutzertabelle keine Daten, deren Speicher-Engine BLACKHOLE ist.

Die BLACKHOLE-Engine eignet sich sehr gut für das Szenario der sekundären Masterbibliothek Masger2: Master2 verarbeitet keine Lese- und Schreibanforderungen, sondern ist nur dafür verantwortlich, BINLOG-Protokolle so schnell wie möglich an die Slave-Bibliothek zu übertragen.

Dual-Master-Replikationsarchitektur

Die Dual-Master-Replikationsarchitektur eignet sich für Szenarien, in denen der DBA zur Wartung zwischen Master- und Slave-Datenbanken wechseln muss. Die Dual-Master-Replikationsarchitektur vermeidet den Aufwand, Slave-Datenbanken wiederholt erstellen zu müssen. Die Dual-Master-Replikationsarchitektur ist in der folgenden Abbildung dargestellt.

Die Masterdatenbanken Master1 und Master sind gegenseitig Master-Slave, und alle Schreibanfragen des Webclients greifen auf die Masterdatenbank Master1 oder Master2 zu. Hinzu kommt, dass der DBA tägliche Wartungsvorgänge durchführen muss. Um eine Beeinträchtigung des Dienstes zu vermeiden, müssen die folgenden Vorgänge ausgeführt werden.

• Stoppen Sie zunächst den Slave-Thread (STOP SLAVE) auf der Master1-Datenbank, um zu verhindern, dass nachfolgende Wartungsvorgänge auf der Master2-Datenbank in Echtzeit in die Master1-Datenbank kopiert werden und den Dienst beeinträchtigen.
• Zweitens stoppen Sie den Slave-Thread (STOP SLAVE) in der Master2-Datenbank und starten Sie routinemäßige Wartungsvorgänge, z. B. das Ändern der Länge des Varchar-Felds von 10 auf 200.
• Öffnen Sie dann nach Abschluss des Wartungsvorgangs an der Master2-Bibliothek den Slave-Thread (STRART SLAVE) an der Master2-Bibliothek, um die Daten von Master2 mit der Master1-Bibliothek zu synchronisieren. Nachdem die Synchronisierung abgeschlossen ist, wechseln Sie den Schreibvorgang der Anwendung zur Master2-Bibliothek.
• Nachdem Sie abschließend bestätigt haben, dass keine Anwendung auf die Master1-Bibliothek zugreift, öffnen Sie den Slave-Thread von Master1 (START SLAVE).
  

Durch die Dual-Master-Replikationsarchitektur kann der zusätzliche Aufwand für die Einrichtung von Slave-Bibliotheken, der für die Wartung der Master-Bibliothek in einer Ein-Master-Mehrere-Slave-Architektur erforderlich ist, erheblich reduziert werden.

Natürlich kann die Dual-Master-Architektur auch in Verbindung mit der Master-Slave-Replikation verwendet werden: Konfigurieren Sie die Slave-Bibliotheken Slave1, Slave2 usw. unter der Master2-Bibliothek. Dadurch kann der Lesedruck durch die Slave-Bibliotheken Slave1 usw. verteilt werden und die zusätzliche Arbeit zum Neuaufbau der Slave-Bibliothek während der Wartungsarbeiten des DBA entfällt. Sie müssen jedoch auf die Replikationsverzögerung der Slave-Bibliothek achten. Die MySQL Dual-Master-Mehrebenen-Replikationsarchitektur wird unten dargestellt.

Multi-Source-Replikationsarchitektur

Die Multi-Source-Replikationsarchitektur eignet sich für komplexe Geschäftsanforderungen und kann sowohl OLTP (Online Transaction Processing) als auch OLAP (Online Analytical Processing) unterstützen. Ich werde die Multi-Source-Replikationsarchitektur von MySQL vorerst nicht zeichnen. Ich werde sie zeichnen und hinzufügen, wenn ich Zeit habe (das Zeichnen ist auch eine physische Arbeit). Bei Interesse können Sie das Buch „MySQL-Datenbankentwicklung, -optimierung, -verwaltung und -wartung in einfachen Worten“ lesen.

Wie kann das Master-Slave-Verzögerungsproblem optimiert werden?

• Optimieren der Netzwerkumgebung
• Verwenden Sie in MySQL 5.5 bis MySQL 5.6 die halbsynchrone Replikation
• In MySQL 5.7 ist eine erweiterte halbsynchrone Replikation (auch als verlustfreie Replikation bekannt) verfügbar.
  

Weitere Informationen zu MySQL-Master-Slave-Verzögerungen finden Sie in meinem anderen Artikel zu verschiedenen Replikationsmethoden für die MySQL-Master-Slave-Replikation.

Zusammengestellt aus:

Das Buch „MySQL-Datenbankentwicklung, -Optimierung, -Verwaltung und -Wartung in einfachen Worten“.

Oben sind die Details der vier häufig verwendeten Master-Slave-Replikationsarchitekturen von MySQL aufgeführt. Weitere Informationen zur Master-Slave-Replikationsarchitektur von MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!