Erfahrungsaustausch zur MySQL-Slave-Wartung

Vorwort:

Die MySQL-Master-Slave-Architektur dürfte der am häufigsten verwendete Architektursatz sein. Die Slave-Datenbank synchronisiert die von der Master-Datenbank übertragenen Daten in Echtzeit. Im Allgemeinen kann die Slave-Datenbank als Backup-Knoten oder für Abfragen verwendet werden. Tatsächlich benötigt nicht nur die Master-Datenbank mehr Aufmerksamkeit, sondern auch die Slave-Datenbank muss regelmäßig gewartet werden. In diesem Artikel werden einige Erfahrungen mit der Wartung von Slave-Datenbanken geteilt. Lassen Sie uns gemeinsam lernen.

1. Es wird empfohlen, den GTID-Modus für die Master-Slave-Replikation zu verwenden

GTID ist die globale Transaktions-ID. GTID besteht eigentlich aus server_uuid:transaction_id. Unter ihnen ist server_uuid die eindeutige Kennung einer MySQL-Instanz, und transaction_id stellt die Anzahl der Transaktionen dar, die an die Instanz übermittelt wurden, und steigt monoton mit der Übermittlung der Transaktionen an. Daher kann GTID die Ausführung jeder Transaktion einer MySQL-Instanz sicherstellen (dieselbe Transaktion wird nicht wiederholt ausgeführt, und nicht ausgeführte Transaktionen werden abgeschlossen).

Die GTID-basierte Master-Slave-Replikation kann die herkömmliche Methode zum Lokalisieren der Replikationsposition über den Binlog-Datei-Offset ersetzen. Insbesondere bei der Architektur mit einem Master und mehreren Slaves können mithilfe von GTID bei einem Master-Slave-Wechsel andere MySQL-Slaves automatisch den richtigen Replikationsstandort auf dem neuen Master finden. Dies vereinfacht die Wartung des Clusters unter einer komplexen Replikationstopologie erheblich und verringert das Fehlerrisiko beim manuellen Festlegen des Replikationsstandorts. Darüber hinaus kann die GTID-basierte Replikation bereits ausgeführte Transaktionen ignorieren, wodurch das Risiko von Dateninkonsistenzen verringert wird.

2. Es wird empfohlen, die Parameter der Slave-Datenbank mit denen der Master-Datenbank konsistent zu halten

Um die Datenkonsistenz zwischen der Master- und der Slave-Bibliothek sicherzustellen, wird empfohlen, dass die Version der Slave-Bibliothek mit der Master-Bibliothek übereinstimmt und die zugehörigen Parameter so weit wie möglich mit der Master-Bibliothek übereinstimmen. Beispielsweise sollten Parameter wie Zeichensatz, Standardspeicher-Engine und SQL-Modus gleich eingestellt sein. Insbesondere für einige Parameter, die nicht dynamisch geändert werden können, wird empfohlen, sie vorab in die Konfigurationsdatei zu schreiben und sie mit der Hauptdatenbank konsistent zu machen.

3. Backup kann aus der Datenbank durchgeführt werden

Eine vollständige MySQL-Sicherung belastet den Server und führt manchmal für kurze Zeit zu einer globalen Sperre. Insbesondere bei Datenbanken mit großen Datenmengen und hohem Geschäftsaufkommen kann eine vollständige Sicherung Auswirkungen auf den Geschäftsbetrieb haben. Es wird empfohlen, das Sicherungsskript auf dem Slave-Server bereitzustellen. Die vollständige Sicherung kann auf dem Slave-Server durchgeführt werden, um die Auswirkungen des Sicherungsvorgangs auf den Master-Server zu verringern.

4. Es wird empfohlen, die Slave-Bibliothek auf schreibgeschützt zu setzen

Der Lese- und Schreibstatus der Datenbank wird hauptsächlich durch den globalen Parameter read_only festgelegt. Standardmäßig wird die Datenbank für Lese- und Schreibvorgänge verwendet, sodass der Parameter read_only 0 oder false ist. Unabhängig davon, ob es sich um einen lokalen Benutzer oder einen Benutzer handelt, der remote auf die Datenbank zugreift, können Benutzer, sofern sie über die entsprechende Berechtigung verfügen, Lese- und Schreibvorgänge ausführen.

Um manuelle Aktualisierungsvorgänge an der Slave-Bibliothek zu vermeiden, wird empfohlen, die Slave-Bibliothek auf schreibgeschützt zu setzen, d. h. den Parameter read_only auf 1 zu setzen. read_only = 1 Der Nur-Lese-Modus wirkt sich nicht auf die synchrone Replikationsfunktion der Slave-Datenbank aus. Die Slave-Datenbank liest weiterhin das Protokoll auf dem Master und wendet das Protokoll auf der Slave-Seite an, um die Synchronisierung und Konsistenz der Master- und Slave-Datenbanken sicherzustellen. Wenn Sie die Slave-Datenbank auf schreibgeschützt setzen, können Benutzer ohne Superberechtigung keine Datenänderungsvorgänge durchführen. Wenn normale Anwendungsbenutzer DML-Vorgänge wie Einfügen, Aktualisieren und Löschen durchführen, die zu Datenänderungen führen, werden sie benachrichtigt, dass sich die Datenbank im schreibgeschützten Modus befindet. Dadurch können Aktualisierungsvorgänge in der Slave-Bibliothek wirksam verhindert werden.

Darüber hinaus kann die Slave-Datenbank, sofern die Rahmenbedingungen es erlauben, einen Teil der Abfragearbeit übernehmen. Beispielsweise können einige Abfragen zur Berichtsaggregationsanalyse oder externe Dienstabfragen als Abfragen untergeordneter Datenbanken konfiguriert werden, um den Druck auf die Hauptdatenbank zu verringern.

5. Achten Sie auf die Überwachung der Slave-Datenbank und die Master-Slave-Verzögerung

Obwohl die Slave-Datenbank nicht so wichtig ist wie die Master-Datenbank, sollten Sie dem Überwachungsstatus der Slave-Datenbank im Normalfall mehr Aufmerksamkeit schenken. Warten Sie nicht, bis Sie die Slave-Datenbank verwenden müssen, um festzustellen, dass die Slave-Datenbank bereits nicht mehr mit der Master-Datenbank übereinstimmt. Zusätzlich zur grundlegenden Überwachung sollte die Slave-Datenbank dem Replikationsstatus und dem Verzögerungsstatus besondere Aufmerksamkeit schenken.

Wir können „show slave status“ ausführen; auf der Slave-Seite wird der Slave-Status abgefragt. Dabei sind drei Hauptwerte von Belang, nämlich „Slave SQL Running“, „Slave IO Running“ und „Seconds Behind Master“. Diese drei Werte stellen den Ausführungsstatus des SQL-Threads, den Ausführungsstatus des IO-Threads und die Verzögerung in Sekunden der Slave-Datenbank dar. Nur wenn „Slave SQL läuft“, „Slave IO läuft“ auf „Ja“ und „Sekunden hinter Master“ auf „0“ stehen, gehen wir davon aus, dass die Slave-Datenbank normal läuft.

Zusammenfassen:

In diesem Artikel werden hauptsächlich einige persönliche Erfahrungen zur Wartung von Slave-Datenbanken geteilt. Wenn Fehler auftreten, korrigieren Sie diese bitte. Wenn andere Studierende entsprechende Erfahrungen oder Anregungen haben, kannst Du diese ebenfalls per Nachricht teilen und diskutieren.

Oben finden Sie ausführliche Informationen zum Austausch von Erfahrungen mit der Wartung von MySQL-Slave-Datenbanken. Weitere Informationen zu Erfahrungen mit der Wartung von MySQL-Slave-Datenbanken finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!