Nastavení klastru replikace master/slave je běžným případem použití ve většině organizací. Použití replikace MySQL umožňuje replikaci vašich dat v různých prostředích a zaručuje, že se informace zkopírují. Je asynchronní a jednovláknový (ve výchozím nastavení), ale replikace vám také umožňuje nakonfigurovat jej tak, aby byl synchronní (nebo vlastně „semisynchronní“) a může spouštět podřízené vlákno na více vláknech nebo paralelně.
Tento nápad je velmi častý a obvykle přichází s jednoduchým nastavením, takže jeho podřízený slouží jako jeho obnova nebo pro řešení zálohování. To se však vždy vyplatí, zejména když se replikují špatné dotazy (jako je nedostatek primárních nebo jedinečných klíčů) nebo nějaké problémy s hardwarem (jako jsou problémy se vstupem do sítě nebo disku). Když nastanou tyto problémy, nejběžnějším problémem je zpoždění replikace.
Prodleva replikace je cena zpoždění transakce (transakcí) nebo operace (operací) vypočítaná podle jejich časového rozdílu provádění mezi primárním/masterem a záložním/podřízeným uzlem. Nejjistější případy v MySQL spoléhají na replikaci špatných dotazů, jako je nedostatek primárních klíčů nebo špatné indexy, špatný síťový hardware nebo nefunkční síťová karta, vzdálené umístění mezi různými oblastmi nebo zónami nebo některé procesy, jako je běh fyzických záloh, které mohou způsobit vaší databázi MySQL, abyste zpozdili použití aktuální replikované transakce. Toto je velmi častý případ při diagnostice těchto problémů. V tomto blogu se podíváme na to, jak se s těmito případy vypořádat a na co se zaměřit, pokud zaznamenáte zpoždění replikace MySQL.
SHOW SLAVE STATUS:Mantra MySQL DBA
V některých případech je to nejlepší řešení při řešení zpoždění replikace a odhalí většinou vše, co je příčinou problému ve vaší databázi MySQL. Jednoduše spusťte tento příkaz SQL ve svém podřízeném uzlu, u kterého existuje podezření, že dochází ke zpoždění replikace.
Počáteční pole, která jsou společná pro trasování problémů, jsou,
- Slave_IO_State - Říká vám, co vlákno dělá. Toto pole vám poskytne dobrý přehled o tom, zda stav replikace běží normálně, čelí problémům se sítí, jako je opětovné připojení k hlavnímu serveru nebo trvá příliš mnoho času na potvrzení dat, což může znamenat problémy s diskem při synchronizaci dat na disk. Tuto hodnotu stavu můžete určit také při spuštění SHOW PROCESSLIST.
- Master_Log_File - Název hlavního souboru binlog, kde se aktuálně načítá I/O vlákno.
- Read_Master_Log_Pos - Pozice souboru binlog z hlavního serveru, kde již bylo načteno vlákno I/O replikace.
- Relay_Log_File - název souboru protokolu přenosu, pro který vlákno SQL aktuálně provádí události
- Relay_Log_Pos - pozice binlogu ze souboru zadaného v Relay_Log_File, pro který již bylo SQL vlákno spuštěno.
- Relay_Master_Log_File – Hlavní soubor binlog, který již vlákno SQL provedlo a je shodný s hodnotou Read_Master_Log_Pos.
- Seconds_Behind_Master - toto pole zobrazuje aproximaci rozdílu mezi aktuálním časovým razítkem na podřízeném zařízení a časovým razítkem na hlavním zařízení pro událost, která je aktuálně zpracovávána na podřízeném zařízení. Toto pole však nemusí být schopno sdělit přesné zpoždění, pokud je síť pomalá, protože rozdíl v sekundách se bere mezi podřízeným vláknem SQL a podřízeným I/O vláknem. Mohou se tedy vyskytnout případy, kdy to může dohnat podřízené I/O vlákno s pomalým čtením, ale já to ovládám už jinak.
- Slave_SQL_Running_State - stav vlákna SQL a hodnota je totožná s hodnotou stavu zobrazenou v SHOW PROCESSLIST.
- Retrieved_Gtid_Set - Dostupné při použití replikace GTID. Toto je sada GTID odpovídající všem transakcím přijatým tímto slave zařízením.
- Executed_Gtid_Set - Dostupné při použití replikace GTID. Je to sada GTID zapsaná v binárním protokolu.
Vezměme si například níže uvedený příklad, který používá replikaci GTID a dochází ke zpoždění replikace:
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)Pro diagnostiku problémů jako je tento, může být mysqlbinlog také vaším nástrojem k identifikaci toho, jaký dotaz byl spuštěn na konkrétní pozici binlog x &y. Abychom to určili, vezměme Retrieved_Gtid_Set, Relay_Log_Pos a Relay_Log_File. Viz příkaz níže:
[[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*/;Říká nám, že se pokoušel replikovat a provést příkaz DML, který se snaží být zdrojem zpoždění. Tato tabulka je obrovská tabulka obsahující 13 milionů řádků.
Zkontrolujte ZOBRAZIT SEZNAM PROCESŮ, ZOBRAZIT STAV MOTORU INNODB s kombinací příkazů ps, top, iostat
V některých případech nestačí ZOBRAZIT STAV SLAVE k tomu, abychom nám sdělili viníka. Je možné, že replikované příkazy jsou ovlivněny interními procesy běžícími v slave databázi MySQL. Spuštění příkazů SHOW [FULL] PROCESSLIST a SHOW ENGINE INNODB STATUS také poskytuje informativní data, která vám poskytnou přehled o zdroji problému.
Řekněme například, že běží srovnávací nástroj, který způsobuje zahlcení IO a CPU disku. Můžete to zkontrolovat spuštěním obou příkazů SQL. Zkombinujte to s příkazy ps a top.
Úzká místa s diskovým úložištěm můžete určit také spuštěním iostatu, který poskytuje statistiky aktuálního svazku, který se pokoušíte diagnostikovat. Spuštění iostatu může ukázat, jak je váš server zaneprázdněn nebo zatížen. Například pořízená podřízenou jednotkou, která se zpožďuje, ale zároveň má vysoké využití I/O,
[[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.00Výsledek výše ukazuje vysoké využití IO a vysoký počet zápisů. Odhaluje také, že průměrná velikost fronty a průměrná velikost požadavků se pohybují, což znamená, že je to známka vysoké pracovní zátěže. V těchto případech musíte určit, zda existují externí procesy, které způsobují, že MySQL dusí replikační vlákna.
Jak může ClusterControl pomoci?
S ClusterControl je řešení slave lag a určení viníka velmi snadné a efektivní. Řekne vám to přímo ve webovém uživatelském rozhraní, viz níže:
Odhalí vám aktuální zpoždění podřízených uzlů, se kterými se potýkají vaše podřízené uzly. A nejen to, s řídicími panely SCUMM, pokud jsou povoleny, získáte více informací o tom, co dělá zdraví vašeho podřízeného uzlu nebo dokonce celého clusteru:
Nejen, že tyto věci jsou v ClusterControl k dispozici, poskytuje vám také schopnost vyhnout se chybným dotazům s těmito funkcemi, jak je vidět níže,
Redundantní indexy umožňují určit, že tyto indexy mohou způsobit problémy s výkonem příchozí dotazy, které odkazují na duplicitní indexy. Také vám sdělí tabulky, které nemají žádné primární klíče, což je obvykle běžný problém zpoždění slave při určitém dotazu SQL nebo transakcích, které odkazují na velké tabulky bez primárních nebo jedinečných klíčů, když jsou replikovány na podřízené jednotky.
Závěr
Řešení zpoždění replikace MySQL je častým problémem v nastavení replikace master-slave. Může být snadno diagnostikovatelný, ale obtížně řešitelný. Ujistěte se, že máte své tabulky s primárním klíčem nebo jedinečným klíčem, a určete kroky a nástroje, jak odstranit a diagnostikovat příčinu zpoždění slave. Při řešení problémů je však vždy klíčem efektivita.