Gedanken zur Architekturoptimierung aufgrund des Master-Slave-Replikationsproblems

Es liegt ein Problem vor

Die Master-Slave-Replikationsarchitektur weist viele Replikationsstagnationsprobleme wie 1032-Fehler und 1062-Fehler auf. Darunter tritt der 1032-Fehler auf, nachdem die Master-Datenbank erfolgreich war Beim Löschen wurde festgestellt, dass dieser Datensatz nicht in der Slave-Bibliothek gefunden werden konnte. Der Fehler 1062 wurde durch einen Primärschlüsselkonflikt verursacht, der auftrat, als die Slave-Bibliothek nach der Hauptbibliothek ausgeführt wurde Die Einfügung wurde abgeschlossen und die Einfügung konnte nicht erfolgreich sein. Diese Probleme können durch Überspringen des Fehlers und der Überprüfung der vorherigen Kopierdaten behoben werden. Die direkte Ursache dieser Probleme ist jedoch die Inkonsistenz der Master-Slave-Datenbankdaten. Zusätzlich zu möglichen Dateninkonsistenzen in der logischen Replikation selbst wird diese Inkonsistenz auch dadurch verursacht, dass die Geschäftsseite oder Entwickler unter Verstoß gegen die Vorschriften direkt Hinzufügungs-, Lösch- und Änderungsvorgänge an der Standby-Datenbank durchführen.

In der Master-Slave-Replikationsarchitektur implementiert die Master-Slave-Bibliothek die VIP-Bindung, um die Bibliothek als Master-Bibliothek festzulegen und Lese- und Schreibvorgänge bereitzustellen, und die Slave-Bibliothek übernimmt die Rolle des Backups, wenn ein Problem auftritt In der Master-Bibliothek wechselt der VIP zur Slave-Bibliothek. Die Slave-Bibliothek ermöglicht das Lesen und Schreiben, andernfalls dient die Slave-Bibliothek nur der Sicherung. Unter normalen Umständen erlauben wir Entwicklern nicht, sich über eine feste IP direkt bei der Slave-Datenbank anzumelden, aber in der Praxis ist es oft schwierig, dies zu vermeiden. Wie kann man also aus technischer Sicht verhindern, dass Entwickler in der Slave-Datenbank arbeiten? Wie kann dies vermieden werden, ohne den normalen Betrieb und das Failover der Hochverfügbarkeitsarchitektur zu beeinträchtigen?

2. Architekturkonfigurationsoptimierung

(1) Direkte Lösung

Der direkte Weg zur Lösung der oben genannten Probleme ist Erwägen Sie die Optimierung der Architekturkonfiguration, dh konfigurieren Sie den Lese-/Schreibstatus der Slave-Bibliothek in den schreibgeschützten Status.

Die offizielle MySQL-Website enthält die folgende Beschreibung zum schreibgeschützten Zugriff:

1.Whenthe read_only system variable is enabled, the server permits no client updatesexcept from users who have the SUPER privilege. 
只读情况下，super权限可读写。
2.Updates performed by slave threads, if theserver is a replication slave. In replication setups, 
it can be useful toenable read_only on slave servers to ensure that slaves accept updates only from themaster server and not from clients.
不影响主从复制线程的读写。

Nach dem Aktivieren des schreibgeschützten Zugriffs, mit Ausnahme von Konten mit Superprivilegien und Replikationsthreads usw., für geschäftliche Entwickler und anderes Personal sind nicht betroffen. Auch wenn Sie sich bei der Standby-Datenbank anmelden, können Sie die Standby-Datenbankdaten nicht bedienen.

MySQL [db1]> show global variables like'read_only%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| read_only     | ON   |
+---------------+-------+
1 row in set (0.00 sec)
 
MySQL [test]> insert child values('1','12');
ERROR 1290 (HY000): The MySQL server is running withthe --read-only option so it cannot execute thisstatement

(2) Wie führe ich ein perfektes Failover durch, nachdem ich es als schreibgeschützt konfiguriert habe?

Durch das Nur-Lesen aus der Slave-Bibliothek können illegale Vorgänge vermieden werden. Das Problem besteht jedoch darin, dass der VIP bei Problemen mit der Hauptbibliothek zur Slave-Bibliothek wechseln muss Zu diesem Zeitpunkt führt der schreibgeschützte Zugriff aus der Slave-Bibliothek dazu, dass die Datenbank keine externen Dienste hat. Daher ist es beim Umschalten erforderlich, die schreibgeschützte Funktion der Slave-Bibliothek abzubrechen und die schreibgeschützte Funktion der Hauptbibliothek festzulegen .

Am Beispiel der Keepalived + MySQL-Dual-Master-Architektur (Master-Slave) befindet sich der VIP im Normalbetrieb auf Master1, Master1 befindet sich im Lese-/Schreibstatus und Master2 befindet sich im schreibgeschützten Status. Sobald ein Problem mit Master1 auftritt, wechselt der VIP automatisch zu Master2. Vor dem Wechsel müssen zwei Schritte ausgeführt werden: 1. Master1 auf „schreibgeschützt“ setzen. 2. „Schreibgeschützt“ von Master2 aufheben.

3. Automatisierte Implementierungsideen

Für eine Master-Slave-Architektur muss das Failover manuell durchgeführt werden, daher können die beiden oben genannten Schritte auch manuell durchgeführt werden, jedoch mit Keepalived +MySQL Dual Master ( In der Master-Slave-Architektur wurden eine automatische Fehlerüberwachung und eine automatische VIP-Umschaltung implementiert. Die beiden oben genannten Schritte sollten auch in Skripte eingebettet werden, um eine Automatisierung zu erreichen.

Wir müssen hauptsächlich Funktionen zum Aktivieren und Deaktivieren von Readonly in der Datenbank in die automatischen Überwachungs- und Umschaltskripte einbetten. Wir schreiben hauptsächlich die Anweisungen „set global read_only=ON“ und „set globalread_only=OFF“. Beachten Sie gleichzeitig, dass vor dem Festlegen des Status zunächst die Anweisung „Variablen wie ‚read_only‘ anzeigen“ aufgerufen wird. Stellen Sie den schreibgeschützten Parameter auf den erforderlichen Status ein. Beachten Sie, dass die Triggeranpassung dieser Statuseinstellungen erfolgt, bevor ein Fehler erkannt und eine Umschaltung durchgeführt wird.

Die oben genannten Ideen wurden nun automatisch konvertiert und der persönliche Test war erfolgreich, was zeigt, dass die Ideen richtig sind.

Das Obige ist der Inhalt der Überlegungen zur Architekturoptimierung, die durch das Master-Slave-Replikationsproblem verursacht werden. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!