Allgemeine Lösungen für das Ablaufen der Lese-/Schreibtrennung in MySQL

Die Fallstricke der Lese- und Schreibtrennung in MySQL

Das Hauptziel der Lese- und Schreibtrennung besteht darin, den Druck der Hauptdatenbank zu teilen und dem Client die Back-End-Datenbank für die Abfrage auszuwählen. Eine andere Architektur besteht darin, dass sich zwischen MySQL und dem Client eine Zwischenproxyschicht befindet. Der Client stellt eine Verbindung zum Proxy her und der Proxy bestimmt die Verteilungsroute der Anforderung basierend auf dem Anforderungstyp und dem Kontext.

• Lösung für die direkte Clientverbindung: Da eine Ebene der Proxy-Weiterleitung weniger vorhanden ist, ist die Abfrageleistung etwas besser und die Gesamtarchitektur einfacher, was die Fehlerbehebung erleichtert. Diese Lösung erfordert jedoch ein Verständnis der Bereitstellungsdetails des Back-Ends, sodass der Client bei Vorgängen wie Master-Slave-Umschaltung und Datenbankmigration davon Kenntnis hat und die Datenbankverbindungsinformationen anpassen muss.
• Mit Proxy-Architektur: benutzerfreundlicher für Clients. Der Client muss sich nicht um die Backend-Details kümmern. Die Verbindungswartung, die Wartung der Backend-Informationen und andere Aufgaben werden alle vom Proxy ausgeführt. Allerdings sind in diesem Fall die Anforderungen an das Back-End-Wartungsteam höher.
  

Unabhängig von der verwendeten Architektur ist es aufgrund möglicher Verzögerungen zwischen Master und Slave möglich, den Status vor der Transaktionsaktualisierung zu lesen, wenn der Client unmittelbar nach der Ausführung einer Aktualisierungstransaktion eine Abfrage initiiert und die Abfrage den Slave auswählt. Dieses Phänomen des „Lesens eines abgelaufenen Zustands des Systems in der Slave-Bibliothek“ nennen wir vorerst „abgelaufenes Lesen“.

Lösung 1: Erzwingen der Hauptdatenbanklösung

Abfrageanforderungen werden in zwei Kategorien unterteilt:

• Bei Anfragen, die die aktuellsten Ergebnisse abrufen müssen, müssen diese zwangsweise an die Hauptdatenbank gesendet werden. Wenn ein Verkäufer beispielsweise auf einer Handelsplattform ein Produkt veröffentlicht hat, muss er sofort zur Hauptseite zurückkehren, um zu sehen, ob das Produkt erfolgreich veröffentlicht wurde. Wenn diese Anfrage dann das neueste Ergebnis liefern soll, muss sie über die Hauptdatenbank laufen.
• Es werden nur Anfragen an die Slave-Datenbank gesendet, die alte Daten lesen können. Beim Durchsuchen der Shop-Seite ist es für Käufer dieser Handelsplattform akzeptabel, dass ihnen die neuesten Produkte mit ein paar Sekunden Verspätung angezeigt werden. Solche Anfragen können dann über die Bibliothek abgewickelt werden. Das größte Problem bei dieser Lösung besteht darin, dass möglicherweise die Anforderung auftritt, dass nicht alle Abfragen „abgelaufene Lesevorgänge“ sind, wie z. B. bei Finanzdienstleistungen. In diesem Fall muss die Lese-/Schreibtrennung aufgegeben werden, und der gesamte Druck liegt auf der Hauptdatenbank. Das folgende Schema wurde übernommen.

Lösung 2: Schlaflösung

Nachdem die Master-Datenbank aktualisiert wurde, wird ein Sleep-Vorgang ausgeführt, bevor die Slave-Datenbank gelesen wird, ähnlich wie bei der Ausführung des Befehls select sleep (1). Die Annahme dieser Lösung ist, dass die Master-Slave-Verzögerung in den meisten Fällen innerhalb einer Sekunde liegt und ein Sleep-Vorgang höchstwahrscheinlich die neuesten Daten abrufen kann.

Am Beispiel eines Verkäufers, der ein Produkt veröffentlicht: Nach der Veröffentlichung des Produkts wird Ajax verwendet, um den vom Kunden eingegebenen Inhalt direkt als „neues Produkt“ auf der Seite anzuzeigen, ohne die Datenbank tatsächlich abzufragen. Somit kann der Verkäufer mit dieser Anzeige die erfolgreiche Freigabe des Produktes bestätigen. Bis der Verkäufer die Seite aktualisiert und das Produkt prüft, ist tatsächlich einige Zeit vergangen, wodurch der Zweck des Ruhezustands erreicht und das Problem des abgelaufenen Lesens gelöst wird.

Lösung 3: Stellen Sie fest, ob Master und Backup keine Verzögerung aufweisen:

Die erste Methode: Verwenden Sie zuerst den Wert des Parameters seconds_behind_master im Ergebnis „Slave-Status anzeigen“, um die Länge der Master-Slave-Verzögerung zu messen. Bestimmen Sie zunächst, ob der Parameterwert 0 ist. Wenn er nicht 0 ist, müssen Sie warten, bis der Parameter 0 wird, bevor Sie die Anforderung ausführen.

Methode 2: Vergleichsportale stellen sicher, dass es bei Primär- und Backup-Vorgängen zu keiner Verzögerung kommt.

• Master_Log_File und Read_Master_Log_Pos geben die letzte Position des Lesevorgangs aus der Masterdatenbank an.
• Relay_Master_Log_File und Exec_Master_Log_Pos geben die letzte Ausführungsposition der Standby-Datenbank an.

Wenn die Werte von Master_Log_File, Relay_Master_Log_File, Read_Master_Log_Pos und Exec_Master_Log_Pos genau gleich sind, bedeutet dies, dass die empfangenen Protokolle synchronisiert wurden.

Die dritte Methode: Vergleichen Sie GTID (Global Transaction ID), um sicherzustellen, dass es zwischen Master und Slave keine Verzögerung gibt

• Auto_Position=1 bedeutet, dass für diese Master-Slave-Beziehung das GTID-Protokoll verwendet wird.
• „Retrieved_Gtid_Set“ ist der GTID-Satz aller von der Slave-Datenbank empfangenen Protokolle.
• Executed_Gtid_Set ist ein Satz aller GTIDs, die auf der Standby-Datenbank ausgeführt wurden.

Wenn die beiden Sätze identisch sind, bedeutet dies, dass die von der Standby-Datenbank empfangenen Protokolle synchronisiert wurden.

Schema 4: Gleiches Master-Bibliotheks-Site-Schema

select master_pos_wait(file, pos[, timeout]);

Dieser Befehl wird auf der Slave-Datenbank ausgeführt. Die Parameter file und pos beziehen sich auf den Dateinamen und die Position auf der Master-Datenbank. Timeout bedeutet, dass diese Funktion maximal N Sekunden wartet.

• Das normale Ergebnis, das dieser Befehl zurückgibt, ist eine positive Ganzzahl M, die angibt, wie viele Transaktionen vom Beginn der Befehlsausführung bis zum Abschluss der Anwendung der durch Datei und Pos angegebenen Binärprotokollpositionen ausgeführt wurden.
• Wenn im Synchronisierungsthread der Standbydatenbank eine Ausnahme auftritt, wird null zurückgegeben.
• Wenn die Wartezeit N Sekunden überschreitet, geben Sie -1 zurück
• Wenn festgestellt wird, dass es zu Beginn der Ausführung ausgeführt wurde, wird 0 zurückgegeben.

Wie in der Abbildung gezeigt: Führen Sie zuerst trx1 aus und führen Sie dann die Logik einer Abfrageanforderung aus. Um sicherzustellen, dass die richtigen Daten gefunden werden, können wir verwenden

Diese Logik

1. Führen Sie nach der Aktualisierung der TRX1-Transaktion sofort „Show Master Status“ aus, um die aktuell von der Masterdatenbank ausgeführte Datei und Position abzurufen.

2. Wählen Sie eine Slave-Datenbank aus, um die Abfrageanweisung auszuführen.

3. Führen Sie „select master_pos_wait(File, Position, 1)“ auf der Slave-Datenbank aus.

4. Wenn der Rückgabewert eine positive Ganzzahl >= 0 ist, führen Sie die Abfrageanweisung in dieser Slave-Datenbank aus.

5. Andernfalls gehen Sie zur Hauptdatenbank, um die Abfrageanweisung auszuführen.

Hier gehen wir davon aus, dass diese Select-Abfrage maximal 1 Sekunde auf der Slave-Datenbank wartet. Wenn master_pos_wait dann innerhalb von 1 Sekunde eine Ganzzahl größer oder gleich 0 zurückgibt, ist sichergestellt, dass das auf der Slave-Datenbank ausgeführte Abfrageergebnis die Daten von trx1 enthalten muss.

5 Das Ausführen von Abfrageanweisungen in der Hauptdatenbank ist ein gängiger Verschlechterungsmechanismus für diesen Lösungstyp. Da die Verzögerungszeit der Slave-Datenbank unkontrollierbar ist und nicht unbegrenzt gewartet werden kann, sollten Sie aufgeben und die Master-Datenbank überprüfen, wenn die Wartezeit abgelaufen ist. Gemäß unserer Anforderung, abgelaufene Lesevorgänge nicht zuzulassen, gibt es nur zwei Möglichkeiten: Eine besteht darin, nach Ablauf der Zeit aufzugeben, oder die andere darin, für die Abfrage zur Hauptdatenbank zu wechseln.

Gleichzeitige Verbindungen und gleichzeitige Abfragen

Der Parameter innodb_thread_concurrency steuert die Obergrenze gleichzeitiger Threads von Innodb. Sobald dieser Wert überschritten wird, werden neue Anfragen zurückgestellt.

• Bei den Tausenden von Verbindungen, die von „show processlist“ angezeigt werden, handelt es sich um gleichzeitige Verbindungen, während es sich bei den aktuell ausgeführten Anweisungen um gleichzeitige Abfragen handelt. Gleichzeitige Verbindungen haben kaum Auswirkungen, sie beanspruchen lediglich mehr Speicher, während gleichzeitige Abfragen die CPU-Leistung beeinträchtigen.
• Nachdem der Thread in den Sperrwartezustand eintritt, wird die Anzahl gleichzeitiger Threads reduziert, d. h. der Thread, der auf die Zeilensperre wartet, wird bei gleichzeitigen Abfragen nicht mitgezählt. Weil das Warten keine CPU mehr verbraucht

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.