Ideen zur Abstimmung der Master-Slave-Verzögerung
1. Was ist eine Master-Slave-Verzögerung?
Das Wesentliche ist, dass die Wiedergabe der Slave-Bibliothek nicht mit der Master-Bibliothek mithalten kann und die Wiedergabephase verzögert ist.
2. Was sind die häufigsten Ursachen für Master-Slave-Verzögerungen?
1. Bei großen Transaktionen ist die Wiedergabezeit der Slave-Bibliothek lang, was zu einer Master-Slave-Verzögerung führt.
2. Die Hauptbibliothek schreibt zu häufig und die Slave-Bibliothek kann mit der Wiedergabe nicht mithalten.
3. Unangemessene Parameterkonfiguration
4. Unterschiede in der Master-Slave-Hardware
5. Netzwerkverzögerung
6. Die Tabelle hat keinen Primärschlüssel oder der Index wird häufig und häufig aktualisiert.
7. Einige Architekturen, die Lesen und Schreiben trennen, üben einen größeren Druck auf die Slave-Bibliothek aus.
3. Welche Methoden gibt es, um die Master-Slave-Verzögerung zu lösen?
1. Teilen Sie große Transaktionen in kleine Transaktionen auf
2. Aktivieren Sie die parallele Replikation
3. Aktualisieren Sie die Slave-Hardware
4. Versuchen Sie, Primärschlüssel zu haben
4. Was ist parallele Replikation und welche Parameter hat sie?
Sehen Sie sich den Weg der parallelen MySQL-Replikation an
MySQL5.6 basiert auf der parallelen Replikation auf Datenbankebene
Slave-Parallel-Type=DATABASE (Transaktionen in verschiedenen Bibliotheken, keine Sperrkonflikte)
MySQL5.7 Parallele Replikation basierend auf Gruppen-Commit
slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一组的事务[last-commit相同]Es darf kein Sperrkonflikt in derselben Gruppe vorliegen, da es sonst keine Möglichkeit gibt, dieselbe Gruppe zu werden.
Das Obige ist die Konfiguration der Slave-Bibliothek. Die parallele Replikation hängt von der Gruppenübermittlung der Master-Bibliothek ab (beachten Sie den Unterschied zwischen Gruppenreplikation).
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
-
binlog_group_commit_sync_delay: Wie lange muss gewartet werden, bevor die Gruppe eingereicht wird? -
binlog_group_commit_sync_no_delay_count: Wie viele Transaktionen müssen gewartet werden, bevor die Gruppe festgeschrieben wird
Die oben genannten Parameter hängen alle von der Auslastung der Hauptdatenbank ab. Wenn das Geschäft nicht häufig ist, wird es sehr peinlich.
binlog_group_commit_sync_no_delay_count: Dieser Parameter ist auf 2 gesetzt
Wenn beispielsweise nur ein Thread eine Transaktion ausführt und die zweite Transaktion 24 Stunden später ausgeführt wird, muss diese Transaktion 24 Stunden warten, bevor sie übermittelt wird, was sehr frustrierend ist.
binlog_group_commit_sync_delay
Wenn es auf 200 ms eingestellt ist und nur ein Thread eine Transaktion ausführt, kann sie in 10 ms übermittelt werden, muss jedoch 200 ms warten.
Im Allgemeinen werden beide online aufgebaut. Beispielsweise ist es wie ein kleines Boot, das Menschen über einen Fluss transportiert.
Angenommen, unsere Parameter sind wie folgt eingestellt:
binlog_group_commit_sync_delay=200;
binlog_group_commit_sync_no_delay_count=2
Entweder können Sie direkt gehen, wenn Sie 200 ms benötigen, oder Sie können direkt gehen, wenn Sie 2 Personen benötigen. Das ist viel benutzerfreundlicher, aber es ist immer noch peinlich, wenn das Unternehmen nicht beschäftigt ist.
Parallele MySQL8.0-Replikation basierend auf Schreibsätzen
Konflikterkennung basierend auf dem Primärschlüssel (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, wenn kein Konflikt im Primärschlüssel oder nicht leeren eindeutigen Schlüssel der geänderten Zeile vorliegt, kann er parallelisiert werden)
Algorithmus zur Transaktionserkennung:transaction_write_set_extraction = XXHASH64
MySQL verfügt über eine Variable zum Speichern des HASH-Werts der übermittelten Transaktion. Nach dem Hashing werden die Werte des von allen übermittelten Transaktionen geänderten Primärschlüssels (oder eindeutigen Schlüssels) mit dem Satz dieser Variablen verglichen, um festzustellen, ob die Änderung vorliegt von Zeilenkonflikten damit und zur Ermittlung von Abhängigkeiten
Die hier genannten Variablen können dadurch in der Größe eingestellt werden:binlog_transaction_dependency_history_size
Diese Art der Granularität hat die Zeilenebene erreicht, das heißt, die parallele Granularität ist zu diesem Zeitpunkt verfeinert und die Parallelität wird schneller sein. In einigen Fällen ist es keine Übertreibung zu sagen, dass die Parallelität des Slaves größer ist Master ( der Master ist ein Single-Threaded-Schreibgerät, der Slave kann auch parallel wiedergeben )
Einfach ausgedrückt handelt es sich um eine parallele Wiedergabe basierend auf Zeilen auf RC-Ebene, bei der es keine Sperrkonflikte gibt.
Leistung der Gruppeneinreichung:
Überprüfen Sie, ob der last_committed-Wert des Binlogs der Hauptbibliothek konsistent ist. Wenn er konsistent ist, kann er nur seriell abgespielt werden.
5. Praktische Analyse
5.1 Überprüfen Sie die Online-Master-Slave-Verzögerung
Seconds_Behind_Master: 48828
Es ist ersichtlich, dass die Verzögerung sehr hoch ist und fast 14 Stunden beträgt. Zu diesem Zeitpunkt schreibt die Hauptbibliothek auch ständig Daten, etwa 6 Minuten für ein Binlog und eines für 500 Millionen
5.2 Aktuelle Replikationskonfiguration anzeigen
Sehen Sie sich die Konfiguration der Slave-Bibliothek an:
greatsql> show variables like '%slave%para%';
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 128 |
+------------------------+---------------+
2 rows in set (0.02 sec)
Verzögerungsphänomen:
Die Slave-Bibliothek hat nachgejagt, was darauf hindeutet, dass es sich nicht um eine große Transaktion handelt, aber Seconds_Behind_Masterdie Verzögerung hat zugenommen.
Retrieved_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:242966351-253068975,
00000000-0000-0040-0095-5fff003b4b99:91056629-110569633,
00000000-0000-005c-0ced-7bae003b4b99:150292055-160253193,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Executed_Gtid_Set: 00000000-0000-0024-0046-41a8003b4b99:1-252250235,
00000000-0000-0040-0095-5fff003b4b99:1-109120315,
00000000-0000-005c-0ced-7bae003b4b99:1-159504296,
31f4399f-ade5-11ed-a544-00163ebdeb51:1-12,
Auto_Position: 1
Derzeit wird vermutet, dass es keine parallele Replikation gibt und die Hauptbibliothek möglicherweise keine Gruppenübermittlung eingerichtet hat (nur eine Vermutung).
5.3 Überprüfen Sie zur weiteren Überprüfung das Binlog der Hauptbibliothek
Überprüfen Sie die Parameterkonfiguration der Hauptbibliothek: weiterhin die für die Gruppe übermittelten Regeln
greatsql> show variables like '%binlog_transac%';
+--------------------------------------------+----------+
| Variable_name | Value |
+--------------------------------------------+----------+
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
+--------------------------------------------+----------+
4 rows in set (0.02 sec)
Schauen Sie sich die Konfiguration der Gruppenübermittlung an: Dies bedeutet, dass keine Gruppenübermittlung erfolgt.
greatsql> show variables like '%group%delay%';
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+
2 rows in set (0.01 sec)
Nach einer weiteren Überprüfung und einem Blick auf das Binlog stellten wir fest, dass last_committed tatsächlich anders ist, was darauf hindeutet, dass Parallelität nicht möglich ist.
5.4 Legen Sie Parameter für die Hauptbibliothek fest und analysieren Sie deren Binlog erneut
wird in den Modus binlog_transaction_dependency_trackinggeändertWRITESET
greatsql> show variables like '%transaction%';
+----------------------------------------------------------+-----------------+
| Variable_name | Value |
+----------------------------------------------------------+-----------------+
| binlog_direct_non_transactional_updates | OFF |
| binlog_transaction_compression | OFF |
| binlog_transaction_compression_level_zstd | 3 |
| binlog_transaction_dependency_history_size | 25000 |
| binlog_transaction_dependency_tracking | WRITESET |
| kill_idle_transaction | 300 |
| performance_schema_events_transactions_history_long_size | 10000 |
| performance_schema_events_transactions_history_size | 10 |
| replica_transaction_retries | 10 |
| session_track_transaction_info | OFF |
| slave_transaction_retries | 10 |
| transaction_alloc_block_size | 8192 |
| transaction_allow_batching | OFF |
| transaction_isolation | REPEATABLE-READ |
| transaction_prealloc_size | 4096 |
| transaction_read_only | OFF |
| transaction_write_set_extraction | XXHASH64 |
+----------------------------------------------------------+-----------------+
17 rows in set (0.00 sec)
Überprüfen Sie noch einmal das Binlog und stellen Sie fest, dass viele davon parallel abgespielt werden können.
5.5 Optimierung abgeschlossen
Obwohl die Hauptbibliothek in großen Mengen schreibt, ist es nur eine Frage der Zeit, bis sie aufholt
Viel Spaß mit GreatSQL :)
Über GreatSQL
GreatSQL ist eine inländische unabhängige Open-Source-Datenbank, die für Anwendungen auf Finanzebene geeignet ist. Sie verfügt über viele Kernfunktionen wie hohe Leistung, hohe Zuverlässigkeit, hohe Benutzerfreundlichkeit und hohe Sicherheit. Sie kann als optionaler Ersatz für MySQL oder Percona Server verwendet werden und wird in Online-Produktionsumgebungen verwendet, völlig kostenlos und kompatibel mit MySQL oder Percona Server.
Verwandte Links: GreatSQL Community Gitee GitHub Bilibili
GreatSQL-Community:
Vorschläge und Feedback zu Community-Belohnungen: https://greatsql.cn/thread-54-1-1.html
Details zur preisgekrönten Einreichung des Community-Blogs: https://greatsql.cn/thread-100-1-1.html
(Wenn Sie Fragen zu dem Artikel haben oder einzigartige Erkenntnisse gewinnen möchten, können Sie diese auf der offiziellen Community-Website stellen oder teilen~)
Technische Austauschgruppe:
WeChat- und QQ-Gruppe:
QQ-Gruppe: 533341697
WeChat-Gruppe: Fügen Sie GreatSQL Community Assistant (WeChat-ID:) wanlidbcals Freund hinzu und warten Sie, bis der Community-Assistent Sie der Gruppe hinzufügt.