Ein Master/Slave-Replikationscluster-Setup ist ein häufiger Anwendungsfall in den meisten Organisationen. Die Verwendung von MySQL Replication ermöglicht die Replikation Ihrer Daten über verschiedene Umgebungen hinweg und garantiert, dass die Informationen kopiert werden. Es ist asynchron und Single-Threaded (standardmäßig), aber die Replikation ermöglicht es Ihnen auch, es so zu konfigurieren, dass es synchron (oder tatsächlich „halbsynchron“) ist und Slave-Threads in mehreren Threads oder parallel ausführen kann.
Diese Idee ist weit verbreitet und kommt normalerweise mit einer einfachen Einrichtung an, bei der sein Slave als Wiederherstellungs- oder Backup-Lösung dient. Dies hat jedoch immer seinen Preis, insbesondere wenn fehlerhafte Abfragen (z. B. fehlende Primär- oder eindeutige Schlüssel) repliziert werden oder Probleme mit der Hardware (z. B. Netzwerk- oder Festplatten-IO-Probleme) auftreten. Wenn diese Probleme auftreten, ist das häufigste Problem die Replikationsverzögerung.
Eine Replikationsverzögerung sind die Verzögerungskosten für Transaktionen oder Operationen, die anhand der Zeitdifferenz der Ausführung zwischen dem Primär-/Master- und dem Standby-/Slave-Knoten berechnet werden. Die meisten bestimmten Fälle in MySQL beruhen darauf, dass fehlerhafte Abfragen repliziert werden, wie z. B. fehlende Primärschlüssel oder fehlerhafte Indizes, eine schlechte Netzwerkhardware oder eine fehlerhafte Netzwerkkarte, ein entfernter Standort zwischen verschiedenen Regionen oder Zonen oder einige Prozesse, wie z. B. laufende physische Sicherungen Ihre MySQL-Datenbank, um die Anwendung der aktuellen replizierten Transaktion zu verzögern. Dies ist ein sehr häufiger Fall bei der Diagnose dieser Probleme. In diesem Blog werden wir prüfen, wie Sie mit diesen Fällen umgehen und worauf Sie achten müssen, wenn Sie eine Verzögerung bei der MySQL-Replikation feststellen.
Der "SHOW SLAVE STATUS":Das Mantra des MySQL DBA
In einigen Fällen ist dies die Wunderwaffe im Umgang mit Replikationsverzögerungen und deckt fast alles auf, was die Ursache eines Problems in Ihrer MySQL-Datenbank ist. Führen Sie einfach diese SQL-Anweisung in Ihrem Slave-Knoten aus, von dem vermutet wird, dass er eine Replikationsverzögerung aufweist.
Die anfänglichen Felder, die üblicherweise auf Probleme verfolgt werden, sind,
- Slave_IO_State - Es sagt Ihnen, was der Thread tut. Dieses Feld bietet Ihnen gute Einblicke, wenn der Replikationszustand normal läuft, Netzwerkprobleme auftreten, wie z. B. das erneute Verbinden mit einem Master, oder zu viel Zeit zum Festschreiben von Daten benötigt wird, was auf Festplattenprobleme beim Synchronisieren von Daten mit der Festplatte hinweisen kann. Sie können diesen Statuswert auch ermitteln, wenn Sie SHOW PROCESSLIST ausführen.
- Master_Log_File - Binlog-Dateiname des Masters, wo der I/O-Thread gerade abgerufen wird.
- Read_Master_Log_Pos - Binlog-Dateiposition vom Master, wo der Replikations-I/O-Thread bereits gelesen hat.
- Relay_Log_File - der Name der Relay-Protokolldatei, für die der SQL-Thread derzeit die Ereignisse ausführt
- Relay_Log_Pos - Binlog-Position aus der in Relay_Log_File angegebenen Datei, für die der SQL-Thread bereits ausgeführt wurde.
- Relay_Master_Log_File – Die Binlog-Datei des Masters, die der SQL-Thread bereits ausgeführt hat und die mit dem Wert „Read_Master_Log_Pos“ übereinstimmt.
- Seconds_Behind_Master - Dieses Feld zeigt eine Näherung für die Differenz zwischen dem aktuellen Zeitstempel auf dem Slave und dem Zeitstempel auf dem Master für das Ereignis, das derzeit auf dem Slave verarbeitet wird. Dieses Feld kann Ihnen jedoch möglicherweise nicht die genaue Verzögerung mitteilen, wenn das Netzwerk langsam ist, da die Differenz in Sekunden zwischen dem Slave-SQL-Thread und dem Slave-E/A-Thread gemessen wird. Es kann also Fälle geben, in denen es mit langsam lesenden Slave-E/A-Threads aufgeholt werden kann, aber ich beherrsche es schon anders.
- Slave_SQL_Running_State - Status des SQL-Threads und der Wert ist identisch mit dem Statuswert, der in SHOW PROCESSLIST angezeigt wird.
- Retrieved_Gtid_Set - Verfügbar bei Verwendung der GTID-Replikation. Dies ist der Satz von GTIDs, der allen von diesem Slave empfangenen Transaktionen entspricht.
- Executed_Gtid_Set - Verfügbar bei Verwendung der GTID-Replikation. Es ist der Satz von GTIDs, die in das Binärlog geschrieben sind.
Nehmen wir zum Beispiel das folgende Beispiel, das eine GTID-Replikation verwendet und eine Replikationsverzögerung erfährt:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.10.70
Master_User: cmon_replication
Master_Port: 3306
Connect_Retry: 10
Master_Log_File: binlog.000038
Read_Master_Log_Pos: 826608419
Relay_Log_File: relay-bin.000004
Relay_Log_Pos: 468413927
Relay_Master_Log_File: binlog.000038
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 826608206
Relay_Log_Space: 826607743
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 251
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 45003
Master_UUID: 36272880-a7b0-11e9-9ca6-525400cae48b
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: copy to tmp table
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:7631-9192
Executed_Gtid_Set: 36272880-a7b0-11e9-9ca6-525400cae48b:1-9191,
864dd532-a7af-11e9-85f2-525400cae48b:1-173,
df68c807-a7af-11e9-9b56-525400cae48b:1-4
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)Bei der Diagnose von Problemen wie diesem kann mysqlbinlog auch Ihr Werkzeug sein, um festzustellen, welche Abfrage an einer bestimmten x- und y-Position des Binlogs ausgeführt wurde. Um dies festzustellen, nehmen wir Retrieved_Gtid_Set, Relay_Log_Pos und Relay_Log_File. Siehe folgenden Befehl:
[[email protected] mysql]# mysqlbinlog --base64-output=DECODE-ROWS --include-gtids="36272880-a7b0-11e9-9ca6-525400cae48b:9192" --start-position=468413927 -vvv relay-bin.000004
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @[email protected]@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 468413927
#200206 4:36:14 server id 45003 end_log_pos 826608271 CRC32 0xc702eb4c GTID last_committed=1562 sequence_number=1563 rbr_only=no
SET @@SESSION.GTID_NEXT= '36272880-a7b0-11e9-9ca6-525400cae48b:9192'/*!*/;
# at 468413992
#200206 4:36:14 server id 45003 end_log_pos 826608419 CRC32 0xe041ec2c Query thread_id=24 exec_time=31 error_code=0
use `jbmrcd_date`/*!*/;
SET TIMESTAMP=1580963774/*!*/;
SET @@session.pseudo_thread_id=24/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1436549152/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=8/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
ALTER TABLE NewAddressCode ADD INDEX PostalCode(PostalCode)
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;Es teilt uns mit, dass versucht wurde, eine DML-Anweisung zu replizieren und auszuführen, die versucht, die Ursache der Verzögerung zu sein. Diese Tabelle ist eine riesige Tabelle mit 13 Millionen Zeilen.
Prüfen Sie SHOW PROCESSLIST, SHOW ENGINE INNODB STATUS, mit ps, top, iostat Befehlskombination
In einigen Fällen reicht SHOW SLAVE STATUS nicht aus, um uns den Übeltäter zu sagen. Es ist möglich, dass die replizierten Anweisungen von internen Prozessen beeinflusst werden, die im MySQL-Datenbank-Slave ausgeführt werden. Das Ausführen der Anweisungen SHOW [FULL] PROCESSLIST und SHOW ENGINE INNODB STATUS liefert auch informative Daten, die Ihnen Einblicke in die Ursache des Problems geben.
Nehmen wir zum Beispiel an, dass ein Benchmarking-Tool ausgeführt wird, wodurch die Festplatten-E/A und -CPU ausgelastet werden. Sie können dies überprüfen, indem Sie beide SQL-Anweisungen ausführen. Kombinieren Sie es mit ps- und Top-Befehlen.
Sie können Engpässe bei Ihrem Festplattenspeicher auch feststellen, indem Sie iostat ausführen, das Statistiken über das aktuelle Volume bereitstellt, das Sie zu diagnostizieren versuchen. Durch Ausführen von iostat kann angezeigt werden, wie ausgelastet oder ausgelastet Ihr Server ist. Beispielsweise von einem Slave aufgenommen, der verzögert ist, aber gleichzeitig eine hohe E/A-Auslastung aufweist,
[[email protected] ~]# iostat -d -x 10 10
Linux 3.10.0-693.5.2.el7.x86_64 (testnode5) 02/06/2020 _x86_64_ (2 CPU)
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.42 3.71 60.65 218.92 568.39 24.47 0.15 2.31 13.79 1.61 0.12 0.76
dm-0 0.00 0.00 3.70 60.48 218.73 568.33 24.53 0.15 2.36 13.85 1.66 0.12 0.76
dm-1 0.00 0.00 0.00 0.00 0.04 0.01 21.92 0.00 63.29 2.37 96.59 22.64 0.01
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.20 392.30 7983.60 2135.60 49801.55 12.40 36.70 3.84 13.01 3.39 0.08 69.02
dm-0 0.00 0.00 392.30 7950.20 2135.60 50655.15 12.66 36.93 3.87 13.05 3.42 0.08 69.34
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.06 183.67 0.00 183.67 61.67 1.85
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.40 370.93 6775.42 2557.04 46184.22 13.64 43.43 6.12 11.60 5.82 0.10 73.25
dm-0 0.00 0.00 370.93 6738.76 2557.04 47029.62 13.95 43.77 6.20 11.64 5.90 0.10 73.41
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.03 107.00 0.00 107.00 35.67 1.07
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 299.80 7253.35 1916.88 52766.38 14.48 30.44 4.59 15.62 4.14 0.10 72.09
dm-0 0.00 0.00 299.80 7198.60 1916.88 51064.24 14.13 30.68 4.66 15.70 4.20 0.10 72.57
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.10 215.50 8939.60 1027.60 67497.10 14.97 59.65 6.52 27.98 6.00 0.08 72.50
dm-0 0.00 0.00 215.50 8889.20 1027.60 67495.90 15.05 60.07 6.60 28.09 6.08 0.08 72.75
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 32.33 0.00 32.33 30.33 0.91
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.90 140.40 8922.10 625.20 54709.80 12.21 11.29 1.25 9.88 1.11 0.08 68.60
dm-0 0.00 0.00 140.40 8871.50 625.20 54708.60 12.28 11.39 1.26 9.92 1.13 0.08 68.83
dm-1 0.00 0.00 0.00 0.30 0.00 1.20 8.00 0.01 27.33 0.00 27.33 9.33 0.28
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.70 284.50 8621.30 24228.40 51535.75 17.01 34.14 3.27 8.19 3.11 0.08 72.78
dm-0 0.00 0.00 290.90 8587.10 25047.60 53434.95 17.68 34.28 3.29 8.02 3.13 0.08 73.47
dm-1 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.83 416.45 0.00 416.45 63.60 12.72
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.30 851.60 11018.80 17723.60 85165.90 17.34 142.59 12.44 7.61 12.81 0.08 99.75
dm-0 0.00 0.00 845.20 10938.90 16904.40 83258.70 17.00 143.44 12.61 7.67 12.99 0.08 99.75
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 1.10 24.60 12965.40 420.80 51114.45 7.93 39.44 3.04 0.33 3.04 0.07 93.39
dm-0 0.00 0.00 24.60 12890.20 420.80 51114.45 7.98 40.23 3.12 0.33 3.12 0.07 93.35
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 3.60 13420.70 57.60 51942.00 7.75 0.95 0.07 0.33 0.07 0.07 92.11
dm-0 0.00 0.00 3.60 13341.10 57.60 51942.00 7.79 0.95 0.07 0.33 0.07 0.07 92.08
dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00Das obige Ergebnis zeigt die hohe IO-Auslastung und eine hohe Anzahl an Schreibvorgängen. Es zeigt auch, dass sich die durchschnittliche Warteschlangengröße und die durchschnittliche Anforderungsgröße bewegen, was bedeutet, dass dies ein Hinweis auf eine hohe Arbeitslast ist. In diesen Fällen müssen Sie feststellen, ob es externe Prozesse gibt, die MySQL veranlassen, die Replikations-Threads zu blockieren.
Wie kann ClusterControl helfen?
Mit ClusterControl ist der Umgang mit Slave-Lags und die Bestimmung des Schuldigen sehr einfach und effizient. Es teilt es Ihnen direkt in der Web-Benutzeroberfläche mit, siehe unten:
Es zeigt Ihnen die aktuelle Slave-Verzögerung, die Ihre Slave-Knoten erfahren. Darüber hinaus erhalten Sie mit SCUMM-Dashboards, sofern aktiviert, mehr Einblicke in den Zustand Ihres Slave-Knotens oder sogar des gesamten Clusters:
Nicht nur, dass diese Dinge in ClusterControl verfügbar sind, es bietet Ihnen auch die Möglichkeit, fehlerhafte Abfragen mit diesen Funktionen zu vermeiden, wie unten gezeigt,
Anhand der redundanten Indizes können Sie feststellen, dass diese Indizes Leistungsprobleme für verursachen können eingehende Abfragen, die auf die doppelten Indizes verweisen. Es teilt Ihnen auch Tabellen mit, die keine Primärschlüssel haben, was normalerweise ein häufiges Problem der Slave-Verzögerung ist, wenn eine bestimmte SQL-Abfrage oder -Transaktion auf große Tabellen ohne Primär- oder eindeutige Schlüssel verweist, wenn sie auf die Slaves repliziert wird.
Fazit
Der Umgang mit Verzögerungen bei der MySQL-Replikation ist ein häufiges Problem in einem Master-Slave-Replikations-Setup. Es kann leicht zu diagnostizieren, aber schwer zu lösen sein. Stellen Sie sicher, dass Ihre Tabellen mit Primärschlüssel oder eindeutigem Schlüssel vorhanden sind, und bestimmen Sie die Schritte und Tools zur Fehlerbehebung und Diagnose der Ursache der Slave-Verzögerung. Effizienz ist jedoch immer der Schlüssel zum Lösen von Problemen.
