Inställning av master/slav-replikeringskluster är ett vanligt användningsfall i de flesta organisationer. Genom att använda MySQL-replikering kan din data replikeras i olika miljöer och garanterar att informationen kopieras. Den är asynkron och enkeltrådad (som standard), men replikering låter dig också konfigurera den att vara synkron (eller faktiskt "halvsynkron") och kan köra slavtråd till flera trådar eller parallellt.
Denna idé är mycket vanlig och kommer vanligtvis med en enkel installation, vilket gör att dess slav fungerar som dess återställning eller för säkerhetskopieringslösningar. Men detta kommer alltid till ett pris, särskilt när dåliga frågor (som brist på primära eller unika nycklar) replikeras eller några problem med hårdvaran (som nätverks- eller disk-IO-problem). När dessa problem uppstår är det vanligaste problemet replikeringsfördröjningen.
En replikeringsfördröjning är kostnaden för fördröjning för transaktion(er) eller operation(er) beräknad av dess tidsskillnad för exekvering mellan primär/master mot standby/slavnod. De mest säkra fallen i MySQL förlitar sig på att dåliga frågor replikeras såsom brist på primärnycklar eller dåliga index, dålig nätverkshårdvara eller felaktigt nätverkskort, en avlägsen plats mellan olika regioner eller zoner, eller vissa processer som körs fysiska säkerhetskopior kan orsaka din MySQL-databas för att fördröja tillämpningen av den aktuella replikerade transaktionen. Detta är ett mycket vanligt fall när man diagnostiserar dessa problem. I den här bloggen kommer vi att kontrollera hur man hanterar dessa fall och vad man ska titta på om du upplever MySQL-replikeringsfördröjning.
"VISA SLAVSTATUS":MySQL DBA:s mantra
I vissa fall är detta silverkulan när man hanterar replikeringsfördröjning och det avslöjar mestadels allt som är orsaken till ett problem i din MySQL-databas. Kör helt enkelt den här SQL-satsen i din slavnod som misstänks ha en replikeringsfördröjning.
De initiala fälten som är vanliga att spåra för problem är,
- Slav_IO_State – Den berättar vad tråden gör. Det här fältet ger dig goda insikter om replikeringshälsan körs normalt, möter nätverksproblem som att återansluta till en master eller om det tar för lång tid att överföra data som kan indikera diskproblem vid synkronisering av data till disk. Du kan också bestämma detta tillståndsvärde när du kör SHOW PROCESSLIST.
- Master_Log_File - Masters binlogfilnamn där I/O-tråden för närvarande hämtas.
- Read_Master_Log_Pos - binlog-filposition från mastern där replikerings-I/O-tråden redan har läst.
- Relay_Log_File - reläloggfilnamnet för vilket SQL-tråden för närvarande exekverar händelserna
- Relay_Log_Pos - binlog-position från filen som anges i Relay_Log_File för vilken SQL-tråden redan har körts.
- Relay_Master_Log_File - Masters binlog-fil som SQL-tråden redan har kört och är kongruent med Read_Master_Log_Pos-värdet.
- Seconds_Behind_Master - det här fältet visar en uppskattning av skillnaden mellan den aktuella tidsstämpeln på slaven mot tidsstämpeln på mastern för händelsen som för närvarande bearbetas på slaven. Det här fältet kanske dock inte kan berätta den exakta fördröjningen om nätverket är långsamt eftersom skillnaden i sekunder tas mellan slav-SQL-tråden och slav-I/O-tråden. Så det kan finnas fall att det kan fångas upp med långsam läsande slav-I/O-tråd, men jag behärskar det är redan annorlunda.
- Slav_SQL_Running_State - SQL-trådens tillstånd och värdet är identiskt med tillståndsvärdet som visas i VISA PROCESSLISTA.
- Retrieved_Gtid_Set - Tillgängligt när du använder GTID-replikering. Detta är uppsättningen GTID:er som motsvarar alla transaktioner som tas emot av denna slav.
- Executed_Gtid_Set - Tillgängligt när du använder GTID-replikering. Det är uppsättningen GTID:er skrivna i den binära loggen.
Låt oss till exempel ta exemplet nedan som använder en GTID-replikering och upplever en replikeringsfördröjning:
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)För att diagnostisera problem som detta kan mysqlbinlog också vara ditt verktyg för att identifiera vilken fråga som har körts på en specifik binlog x &y-position. För att bestämma detta, låt oss ta Retrieved_Gtid_Set, Relay_Log_Pos och Relay_Log_File. Se kommandot nedan:
[[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*/;Den berättar för oss att den försökte replikera och köra en DML-sats som försöker vara källan till fördröjningen. Den här tabellen är en enorm tabell som innehåller 13 miljoner rader.
Kontrollera VISA PROCESSLISTA, VISA MOTORS INNODB-STATUS, med ps, topp, iostat-kommandokombination
I vissa fall räcker det inte med VISA SLAVSTATUS för att tala om för oss den skyldige. Det är möjligt att de replikerade satserna påverkas av interna processer som körs i MySQL-databasslaven. Att köra satserna SHOW [FULL] PROCESSLIST och SHOW ENGINE INNODB STATUS ger också informativa data som ger dig insikter om källan till problemet.
Till exempel, låt oss säga att ett benchmarkingverktyg körs som gör att diskens IO och CPU mättas. Du kan kontrollera genom att köra båda SQL-satserna. Kombinera det med ps och toppkommandon.
Du kan också fastställa flaskhalsar med din disklagring genom att köra iostat som ger statistik över den aktuella volymen du försöker diagnostisera. Körande iostat kan visa hur upptagen eller laddad din server är. Till exempel, taget av en slav som släpar efter men samtidigt upplever högt IO-användning,
[[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.00Resultatet ovan visar den höga IO-användningen och en hög skrivning. Det avslöjar också att den genomsnittliga köstorleken och den genomsnittliga storleken på begäran rör sig, vilket betyder att det är en indikation på hög arbetsbelastning. I dessa fall måste du avgöra om det finns externa processer som gör att MySQL stryper replikeringstrådarna.
Hur kan ClusterControl hjälpa?
Med ClusterControl är det mycket enkelt och effektivt att hantera slavfördröjning och fastställa den skyldige. Det berättar direkt i webbgränssnittet, se nedan:
Den avslöjar för dig vilken slavfördröjning dina slavnoder upplever. Inte bara det, med SCUMM-instrumentpaneler, om de är aktiverade, ger dig fler insikter om vad din slavnods hälsa eller till och med hela klustret gör:
Inte bara att dessa saker är tillgängliga i ClusterControl, det ger dig också förmågan att undvika att dåliga frågor uppstår med dessa funktioner enligt nedan,
De redundanta indexen låter dig avgöra att dessa index kan orsaka prestandaproblem för inkommande frågor som refererar till de dubbla indexen. Den berättar också om tabeller som inte har några primärnycklar, vilket vanligtvis är ett vanligt problem med slavfördröjning när en viss SQL-fråga eller transaktioner som refererar till stora tabeller utan primära eller unika nycklar när den replikeras till slavarna.
Slutsats
Att hantera MySQL-replikeringsfördröjning är ett vanligt problem i en master-slav-replikeringsinstallation. Det kan vara lätt att diagnostisera, men svårt att lösa. Se till att du har dina tabeller med primärnyckel eller unik nyckel, och bestäm stegen och verktygen för hur du felsöker och diagnostiserar orsaken till slavfördröjning. Effektivitet är dock alltid nyckeln när man löser problem.