MySQL-Datenbank-Master-Slave-Replikation und Lese-/Schreibtrennung

1. Master-Slave-Replikation

Master-Slave-Replikation: In der tatsächlichen Produktion wird im Allgemeinen die Master-Slave-Replikation verwendet, um den Einzelpunktausfall von MySQL zu beheben und die Gesamtdienstleistung von MySQL zu verbessern. Das heißt: Sichern Sie die Daten und Anweisungen in der Datenbank.

Master-Slave-Replikation mit drei Threads

Es gibt drei Hauptthreads in der Master-Slave-Replikation von MySQL: Master (Binlog-Dump-Thread), Slave (E/A-Thread, SQL-Thread), ein Thread im Master und zwei Threads im Slave.

Master-Slave-Replikationsprozess

Der Prozess der Master-Slave-Replikation:

Der Master ist hauptsächlich dafür verantwortlich, den aktualisierten Ereignistyp im Binlog-Format in die Binlog-Datei der Master-Bibliothek zu schreiben, wenn in der Master-Bibliothek Daten aktualisiert werden. Der Master erstellt einen Log-Dump-Thread, um den Slave darüber zu benachrichtigen, dass in der Hauptdatenbank eine Datenaktualisierung vorliegt.

Der I/O-Thread wird im Slave erstellt und dient zum Anfordern des Masters. Der Master gibt den Namen des Binlogs, den Speicherort der aktuellen Datenaktualisierung und eine Kopie des Speicherorts der Binlog-Datei zurück. Anschließend wird das Binlog im Relay-Log gespeichert, welches auch Informationen zu Datenaktualisierungen aufzeichnet.

Der SQL-Thread wird auch im Slave erstellt. Wenn der Slave erkennt, dass das Relay-Protokoll aktualisiert wurde, synchronisiert er den aktualisierten Inhalt mit der Slave-Datenbank und stellt so die Synchronisierung der Master- und Slave-Daten sicher.

Master-Slave-Replikationsstrategie

Master-Slave-Replikationsstrategie:

Synchronisierungsstrategie: Der Master wartet vor dem Commit auf die Antwort aller Slaves. Dies beeinträchtigt die Leistung der Master-Slave-Synchronisierung erheblich.

Halbsynchrone Strategie: Der Master wartet auf die Antwort von mindestens einem Slave, bevor er einen Commit ausführt.

Asynchrone Strategie: Der Master kann übermitteln, ohne auf die Antwort des Slaves zu warten.

Verzögerungsstrategie: Der Slave muss hinter der vom Master vorgegebenen Zeit zurückbleiben.
Es gibt verschiedene Strategien für verschiedene Geschäftsanforderungen, aber im Allgemeinen wird die letztendliche Konsistenz gewählt und eine starke Konsistenz ist nicht erforderlich, da eine starke Konsistenz die Leistung erheblich beeinträchtigen würde.

Hohe Latenz bei der Master-Slave-Replikation

Gründe für hohe Latenz bei der Master-Slave-Replikation

Der Master-Server weist eine hohe Parallelität auf, was zu einer großen Anzahl von Transaktionen führt

Netzwerklatenz

Verursacht durch Master- und Slave-Hardwaregeräte (CPU-Hauptfrequenz, Speicher-E/A, Festplatten-E/A)

Es handelt sich nicht um eine synchrone Replikation, sondern um eine asynchrone Replikation.

Lösung für hohe Latenzzeiten bei der Master-Slave-Replikation

Optimieren Sie Mysql-Parameter aus der Datenbank. Erhöhen Sie beispielsweise innodb_buffer_pool_size, um mehr Vorgänge im MySQL-Speicher ausführen zu können und die Anzahl der Festplattenvorgänge zu verringern.

Verwenden Sie Hochleistungshosts (Hochleistungs-CPU, großer Speicher) aus der Datenbank, vermeiden Sie die Verwendung virtueller Cloud-Hosts und verwenden Sie physische Hosts, um den E/A-Durchsatz zu verbessern

SSD-Festplatten aus der Bibliothek verwenden

Netzwerkoptimierung zur Vermeidung der Synchronisierung über mehrere Rechnerräume hinweg

2. Lese- und Schreibtrennung

Konzept der Lese-/Schreibtrennung

Trennung von Lesen und Schreiben: Durch die Trennung von Lesen und Schreiben kann die primäre Datenbank transaktionale Hinzufügungs-, Lösch- und Änderungsvorgänge (INSERT, UPDATE, DELETE) verarbeiten, während die sekundäre Datenbank Abfragevorgänge (SELECT) verarbeitet. Mithilfe der Datenbankreplikation werden durch Transaktionsvorgänge verursachte Änderungen an Slave-Datenbanken im Cluster synchronisiert.

Gründe und Szenarien für die Trennung von Lesen und Schreiben

Gründe für die Trennung von Lesen und Schreiben: Die Anzahl der Lese- und Schreibvorgänge ist groß. Um die Lese- und Schreibleistung der Datenbank zu verbessern, werden Lese- und Schreibvorgänge getrennt. Wenn in mehreren Computerräumen mehr Lese- als Schreibvorgänge stattfinden und aus Gründen der Datenkonsistenz nur eine Master-Datenbank alle Datenschreibvorgänge speichert, und die lokale Slave-Datenbank übernimmt die Lesevorgänge, um die durch direkte Lesevorgänge zwischen mehreren Computerräumen verursachte Latenz zu verringern.

Nutzungsszenario für die Trennung von Lesen und Schreiben: Dies kommt in Betracht, wenn das Programm die Datenbank häufiger verwendet, es jedoch weniger Aktualisierungen und mehr Abfragen gibt. Durch die Verwendung der Master-Slave-Synchronisierung und der Lese-/Schreibtrennung der Datenbank kann der Datenbankdruck verteilt und die Leistung verbessert werden.

Zusammenfassen

Damit ist dieser Artikel über die Master-Slave-Replikation und Lese-/Schreibtrennung von MySQL-Datenbanken abgeschlossen. Weitere Informationen zur Master-Slave-Replikation und Lese-/Schreibtrennung von MySQL finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!