So ändern Sie den Replikationsfilter in MySQL dynamisch

MySQL Replikationsfilter dynamisch ändern

Lassen Sie mich über das Problem sprechen, auf das ich heute gestoßen bin. Heute hatte ich es mit einer Geschäftsanforderung zu tun, die ziemlich ungewöhnlich war. Lassen Sie es mich kurz beschreiben:

1. Auf dem Online-Alibaba-Cloud-RDS gibt es eine Spielprotokollbibliothek. Die darin enthaltenen Tabellen haben die Form von Tagestabellen. Die Datenmenge ist relativ groß. Jedes Mal, wenn eine Sicherung durchgeführt wird, löst das Online-RDS einen Alarm aus. Der Alarminhalt besteht darin, dass die IO-Ressourcen zu stark belegt sind.

2. Auf diesem RDS befindet sich eine lokale ECS-Slave-Datenbank mit Lesezugriff. Diese Slave-Datenbank mit Lesezugriff synchronisiert die Daten in Echtzeit mit der Online-RDS-Datenbank. Diese Slave-Datenbank mit Lesezugriff wird von der Geschäftsseite für Abfragen verwendet.

3. Die Geschäftsseite sagte, dass alle diese Daten immer noch nützlich seien. Die Daten in der schreibgeschützten Slave-Datenbank müssen verfügbar sein, und die Daten im Online-RDS können gelöscht werden und müssen nur zwei Wochen lang aufbewahrt werden.

Das Szenario sieht folgendermaßen aus: Der DBA möchte das Alarmproblem lösen und die Geschäftsseite möchte sicherstellen, dass sie über vollständige Daten verfügt. Wie kann dieses Problem gelöst werden?

Als ich diese Frage sah, wollte ich fluchen. Diese Forderung ist unvernünftig. Wie kann man eine Datenbank löschen und in einer anderen behalten? Außerdem sind das alles Protokolldaten. Warum nicht einfach ein Cold Backup machen und dann die Online-Daten löschen? Da es jedoch keine Möglichkeit gab, die Situation zu entspannen, begann ich darüber nachzudenken, wie ich dieses Problem lösen könnte. Die Lösungen, die mir eingefallen sind:

1. Kapazität erweitern und Leistung verbessern. Die Datenmenge ist groß, also erweitern Sie die Festplatte. Die IO-Auslastungsrate ist hoch, also verbessern Sie die Leistung. Dies ist die direkteste Lösung, aber auch die teuerste Lösung und wird als erstes abgeschnitten.

2. Erst sichern, dann löschen und dann wiederherstellen. Sichern Sie die täglichen Tabellendaten im Voraus in der RDS-Masterdatenbank und löschen Sie die Daten anschließend. Zu diesem Zeitpunkt löscht die Slave-Datenbank die Daten synchron und stellt dann die im ersten Schritt gesicherten Daten in der Slave-Datenbank wieder her. Dieses Vorgehen ist sinnvoll, da hierdurch sichergestellt ist, dass keine Daten verloren gehen. Allerdings ist die Operation ziemlich kompliziert, umfasst zu viele Schritte und ist nicht bequem genug.

3. Verwenden Sie den Parameter „replicate-ignore-table“, um die angegebene Tabelle zu filtern. Durch Festlegen dieses Parameters können Sie alle Vorgänge der angegebenen Datentabelle filtern. Werfen wir einen Blick auf die offizielle Dokumentation zur Beschreibung dieses Parameters. Hier ist ein Link: https://dev.mysql.com/doc/refman/5.7/en/replication-options-slave.html#option_mysqld_replicate-wild-ignore-table

Die Beschreibung lautet wie folgt:

Erstellt einen Replikationsfilter, der den Slave-Thread daran hindert, eine Anweisung zu replizieren, in der eine beliebige Tabelle dem angegebenen Platzhaltermuster entspricht. Um mehr als eine zu ignorierende Tabelle anzugeben, verwenden Sie diese Option mehrmals.

Das Obige bedeutet, dass Sie diesen Parameter verwenden können, um einen Filter zu erstellen, um Vorgänge an bestimmten Tabellen herauszufiltern, die den von Ihnen festgelegten Regeln entsprechen (klingt verwirrend). Das heißt, Sie können eine Filterregel festlegen und Tabelle a zur Regel hinzufügen. Dann werden die Vorgänge an Tabelle a nicht mit der Slave-Datenbank synchronisiert.

Dies entspricht unseren Anforderungen. Das heißt, wenn wir die Tabelle so einstellen, dass sie gefiltert wird, wird sie beim Löschen der Tabelle nicht aus der Datenbank gelöscht und das gewünschte Ergebnis wird erzielt. Lassen Sie uns diese Funktionalität testen:

Zuerst erstellen wir die Datenbank test_ignore und legen dann darin eine Tabelle an:

Operation auf der Hauptdatenbank:

mysql:test_ignore >>Tabellen anzeigen;
Leerer Satz (0,00 Sek.)

mysql:test_ignore >>Tabelle aaa erstellen (ID int ungleich null);
Abfrage OK, 0 Zeilen betroffen (0,19 Sek.)

mysql:test_ignore >>Tabelle aab erstellen (ID int ungleich null);
 Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

mysql:test_ignore >>Tabelle aac erstellen (ID int ungleich null);
 Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql:test_ignore >>Tabelle aad erstellen (ID int ungleich null);
 Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

mysql:test_ignore >>Tabelle aae erstellen (ID int ungleich null);
 Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

Blick aus der Bibliothek:

mysql:test_ignore >>Tabellen anzeigen;
+--------------------------+
| Tabellen_im_Test_ignorieren |
+--------------------------+
|aaa|
| aab |
|
| naja |
| naja |
+--------------------------+
5 Zeilen im Satz (0,00 Sek.)

Habe festgestellt, dass es synchronisiert wurde. Zu diesem Zeitpunkt ist der Master-Slave-Synchronisierungsstatus vorhanden. Wenn wir jetzt die Tabelle in der Master-Datenbank löschen, wird die Tabelle in der Slave-Datenbank definitiv gelöscht, was nicht das gewünschte Ergebnis ist.

Der nächste Schritt besteht natürlich darin, den Parameter replicate-wild-ignore-table zu konfigurieren. Im Allgemeinen müssen wir die Datei my.cnf konfigurieren, indem wir den Slave-Dienst stoppen. Wenn wir mehrere Tabellen konfigurieren möchten, müssen wir mehrere Platzhalterdatensätze in die Datei my.cnf schreiben. In diesem Beispiel muss der Wert des Parameters beispielsweise als test_ignore.aa% konfiguriert werden, wobei % ein Platzhalterzeichen darstellt. Das heißt, Tabellenoperationen in der Datenbank test_ignore im Format aa% werden herausgefiltert. Die von uns erstellten Tabellen aaa, aab, aac, aad und aae haben alle diese Form, sodass Operationen an diesen Tabellen definitiv nicht mit der Slave-Datenbank synchronisiert werden. Lassen Sie es uns testen:

Überprüfen Sie zunächst den aktuellen Replikationsstatus:

Der doppelte Ja-Status bedeutet, dass kein Problem mit der Replikationsbeziehung besteht

Die Hauptbibliothek betreibt:

mysql: test_ignore >> Tabelle aaa löschen;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

mysql: test_ignore >> Tabelle aab löschen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

Blick aus der Bibliothek:

mysql:test_ignore >>Tabellen anzeigen;
+--------------------------+
| Tabellen_im_Test_ignorieren |
+--------------------------+
|aaa|
| aab |
|
| naja |
| naja |
+--------------------------+
5 Zeilen im Satz (0,00 Sek.)

Die Tabelle in der Slave-Datenbank ist immer noch vorhanden, was darauf hinweist, dass die Vorgänge in der Master-Datenbank nicht mit der Slave-Datenbank synchronisiert wurden. Die von uns konfigurierten Parameter

replicate-wild-ignore-table=test_ignore.aa%

Es hat funktioniert. Wenn wir an diesem Punkt eine Tabelle in der Masterdatenbank erstellen:

`Hauptbibliothek`
mysql:test_ignore >>Tabelle erstellen aaf(id int);
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

`Aus der Bibliothek`
mysql:test_ignore >>Tabellen anzeigen;
+--------------------------+
| Tabellen_im_Test_ignorieren |
+--------------------------+
|aaa|
| aab |
|
| naja |
| naja |
+--------------------------+
5 Zeilen im Satz (0,00 Sek.)

Es wurde festgestellt, dass die Slave-Datenbank die Tabelle aaf der Master-Datenbank nicht synchronisiert, da aaf auch der Regel test_ignore.aa% entspricht.

Durch die Verwendung dieser Funktion können wir dieses Geschäftsszenario sehr gut lösen, d. h. die Hauptdatenbank wird gelöscht und die Slave-Datenbank behält die Daten. Diese Methode hat jedoch ein schwerwiegendes Problem, nämlich dass die Slave-Datenbank jedes Mal neu gestartet werden muss. Wenn wir die zweite und die dritte Regel konfigurieren müssen, müssen wir die Slave-Datenbank zwei- oder dreimal neu starten. Während dieses Vorgangs ist die Slave-Datenbank für den Geschäftspartner unsichtbar. Wenn nicht darauf zugegriffen werden kann, führt dies wahrscheinlich zu einem Programmfehler, der unerträglich ist.

Dieser Prozess muss gelöst werden. Wie kann er gelöst werden? Gibt es eine Möglichkeit, den Replikationsfilter ohne Ausfallzeiten zu ändern? Suchen Sie nach offizieller Dokumentation.

Natürlich ist es unmöglich, die Maschine abzuschalten, nicht einmal in diesem Leben. Im offiziellen Dokument findet sich folgender Satz:

Sie können einen solchen Filter auch erstellen, indem Sie die Anweisung CHANGE REPLICATION FILTER REPLICATE_WILD_IGNORE_TABLE ausgeben.

Was zum Teufel soll diese Aussage? Sie bedeutet, dass sie noch nie verwendet wurde. Sie können den Filter ändern, indem Sie den Kopierfilter online ändern. Siehe die Einführung im offiziellen Dokument:

Ich habe einen magischen Satz gesehen, lass es uns versuchen:

mysql:test_ignore >>Replikationsfilter ändern replicate_wild_ignore_table=('test_ig%.aa%');
FEHLER 3017 (HY000): Dieser Vorgang kann nicht mit einem laufenden Slave-SQL-Thread ausgeführt werden. Führen Sie zuerst STOP SLAVE SQL_THREAD aus.

mysql:test_ignore >>Slave stoppen;
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql:test_ignore >>Replikationsfilter ändern replicate_wild_ignore_table=('test_ig%.aa%');
Abfrage OK, 0 Zeilen betroffen (0,00 Sek.)

mysql:test_ignore >>Slave starten;
Abfrage OK, 0 Zeilen betroffen (0,01 Sek.)

Bei direkter Verwendung wird angezeigt, dass der Slave sql_thread gestoppt werden muss. Nachdem ich darüber nachgedacht habe, kann ich verstehen, dass es etwas unangemessen erscheint, die Replikationsregeln zu ändern, ohne die Replikation zu stoppen. Ich stoppe einfach die gesamte Replikation und ändere dann den Replikationsfilter erneut. Es funktioniert. Es wird erfolgreich ausgeführt und die Replikation ist aktiviert. Der Vorgang läuft reibungslos.

Werfen wir einen Blick auf den Status der Replikationsbeziehung:

Die ignorierte Tabellenregel wurde zu test_ig%.aa%, d. h. alle Vorgänge an Tabellen, die mit aa in der Datenbank beginnen, die mit test_ig beginnen, werden nicht mit der Slave-Datenbank synchronisiert, einschließlich Änderungs-, Löschungs- und Erstellungsvorgängen an der Tabelle.

Aber hier kommt die Lösung heraus. Wir wissen, dass die Tagestabelle im Allgemeinen das Format JJJJMMTT hat. Wir müssen nur die Tagestabelle im Format JJJJMM% filtern und sie dann in der Masterdatenbank löschen. Dieser Vorgang wird nicht mit der Slavedatenbank synchronisiert, sodass dieses Problem problemlos gelöst werden kann.

Natürlich gibt es neben dieser Lösung noch einige andere Lösungen, wie zum Beispiel:

Wenn das Unternehmen einen teilweisen Datenverlust toleriert, können wir auch die Methode „Binlog schließen – Tabelle löschen – Binlog öffnen“ verwenden, um zu verhindern, dass die Slave-Datenbank den Drop-Vorgang der Master-Datenbank synchronisiert.

Alle täglichen Onlinetabellenvorgänge werden auf Ignorieren konfiguriert. Anschließend werden Trigger verwendet, um Aktualisierungen in der täglichen Tabelle mit der Slave-Datenbank zu synchronisieren.

Diese Reihe von Vorgängen löst das Problem nicht wirklich grundlegend. Es handelt sich im Wesentlichen um ein Geschäftsdesignproblem. In der Tagestabelle gibt es zu viele Punktprotokolle. Diese Punktprotokolle können entsprechend reduziert werden. Für Punktprotokolle muss die Aufbewahrungsfrist bestimmt werden. Abgelaufene Protokolle müssen rechtzeitig bereinigt werden, um die Indikatoren und die Leistung des Servers sicherzustellen.

Oben finden Sie Einzelheiten zur dynamischen Änderung des Replikationsfilters in MySQL. Weitere Informationen zur dynamischen Änderung des Replikationsfilters in MySQL finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!