Een master/slave-replicatieclusterconfiguratie is een veelvoorkomend gebruik in de meeste organisaties. Door MySQL-replicatie te gebruiken, kunnen uw gegevens worden gerepliceerd in verschillende omgevingen en wordt gegarandeerd dat de informatie wordt gekopieerd. Het is asynchroon en single-threaded (standaard), maar replicatie stelt je ook in staat om het synchroon (of eigenlijk "semi-synchroon") te configureren en slave-threads naar meerdere threads of parallel te laten lopen.
Dit idee is heel gebruikelijk en komt meestal met een eenvoudige installatie, waarbij de slaaf dient als herstel of voor back-upoplossingen. Dit heeft echter altijd een prijs, vooral wanneer slechte queries (zoals het ontbreken van primaire of unieke sleutels) worden gerepliceerd of als er problemen zijn met de hardware (zoals netwerk- of schijf-IO-problemen). Wanneer deze problemen optreden, is het meest voorkomende probleem de replicatievertraging.
Een replicatievertraging is de vertragingskosten voor transactie(s) of bewerking(en), berekend op basis van het tijdsverschil van uitvoering tussen de primaire/master en de stand-by/slave-node. De meest bepaalde gevallen in MySQL zijn afhankelijk van het repliceren van slechte query's, zoals het ontbreken van primaire sleutels of slechte indexen, een slechte netwerkhardware of een defecte netwerkkaart, een verre locatie tussen verschillende regio's of zones, of sommige processen, zoals het uitvoeren van fysieke back-ups, kunnen leiden tot uw MySQL-database om het toepassen van de huidige gerepliceerde transactie uit te stellen. Dit is een veel voorkomend geval bij het diagnosticeren van deze problemen. In deze blog bekijken we hoe u met deze gevallen om moet gaan en waar u op moet letten als u MySQL-replicatievertraging ervaart.
De "SHOW SLAVE STATUS":de mantra van de MySQL DBA
In sommige gevallen is dit het wondermiddel als het gaat om replicatievertraging en het onthult meestal alles wat de oorzaak is van een probleem in uw MySQL-database. Voer eenvoudig deze SQL-instructie uit in uw slave-knooppunt waarvan wordt vermoed dat het een replicatievertraging heeft.
De eerste velden die vaak gebruikt worden om problemen op te sporen zijn,
- Slave_IO_State - Het vertelt je wat de draad doet. Dit veld geeft u goede inzichten als de replicatiestatus normaal verloopt, netwerkproblemen ondervindt, zoals opnieuw verbinding maken met een master, of te veel tijd kost om gegevens vast te leggen, wat kan wijzen op schijfproblemen bij het synchroniseren van gegevens naar schijf. U kunt deze statuswaarde ook bepalen bij het uitvoeren van SHOW PROCESSLIST.
- Master_Log_File - Master's binlog-bestandsnaam waar de I/O-thread momenteel wordt opgehaald.
- Read_Master_Log_Pos - binlog-bestandspositie van de master waar de replicatie I/O-thread al heeft gelezen.
- Relay_Log_File - de bestandsnaam van het relaislog waarvoor de SQL-thread momenteel de gebeurtenissen uitvoert
- Relay_Log_Pos - binlog-positie van het bestand gespecificeerd in Relay_Log_File waarvoor SQL-thread al is uitgevoerd.
- Relay_Master_Log_File - Het binlogbestand van de master dat de SQL-thread al heeft uitgevoerd en overeenkomt met de Read_Master_Log_Pos-waarde.
- Seconds_Behind_Master - dit veld toont een benadering voor het verschil tussen de huidige tijdstempel op de slave en de tijdstempel op de master voor de gebeurtenis die momenteel wordt verwerkt op de slave. Dit veld kan u echter mogelijk niet de exacte vertraging vertellen als het netwerk traag is, omdat het verschil in seconden wordt genomen tussen de slave-SQL-thread en de slave-I/O-thread. Er kunnen dus gevallen zijn dat het kan worden ingehaald door langzaam lezende slave I/O-thread, maar ik beheers het al anders.
- Slave_SQL_Running_State - status van de SQL-thread en de waarde is identiek aan de statuswaarde die wordt weergegeven in SHOW PROCESSLIST.
- Retrieved_Gtid_Set - Beschikbaar bij gebruik van GTID-replicatie. Dit is de set GTID's die overeenkomt met alle transacties die door deze slave zijn ontvangen.
- Executed_Gtid_Set - Beschikbaar bij gebruik van GTID-replicatie. Het is de set GTID's die in het binaire logboek zijn geschreven.
Laten we bijvoorbeeld het onderstaande voorbeeld nemen dat een GTID-replicatie gebruikt en een replicatievertraging ondervindt:
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)Door problemen als deze te diagnosticeren, kan mysqlbinlog ook uw hulpmiddel zijn om te identificeren welke query is uitgevoerd op een specifieke binlog x &y-positie. Om dit te bepalen, nemen we de Retrieved_Gtid_Set, Relay_Log_Pos en de Relay_Log_File. Zie de opdracht hieronder:
[[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*/;Het vertelt ons dat het een DML-instructie probeerde te repliceren en uit te voeren die de oorzaak van de vertraging probeert te zijn. Deze tabel is een enorme tafel met 13M rijen.
Controleer SHOW PROCESSLIST, SHOW ENGINE INNODB STATUS, met ps, top, iostat-commandocombinatie
In sommige gevallen is SHOW SLAVE STATUS niet voldoende om ons de boosdoener te vertellen. Het is mogelijk dat de gerepliceerde instructies worden beïnvloed door interne processen die worden uitgevoerd in de MySQL-databaseslave. Het uitvoeren van de instructies SHOW [FULL] PROCESSLIST en SHOW ENGINE INNODB STATUS levert ook informatieve gegevens op die u inzicht geven in de oorzaak van het probleem.
Stel bijvoorbeeld dat er een benchmarking-tool actief is, waardoor de schijf-IO en CPU verzadigd raken. U kunt dit controleren door beide SQL-instructies uit te voeren. Combineer het met ps en top commando's.
Je kunt ook knelpunten met je schijfopslag bepalen door iostat uit te voeren, dat statistieken biedt van het huidige volume dat je probeert te diagnosticeren. Het uitvoeren van iostat kan laten zien hoe druk of belast uw server is. Bijvoorbeeld genomen door een slaaf die achterblijft maar tegelijkertijd een hoog IO-gebruik ervaart,
[[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.00Het bovenstaande resultaat geeft het hoge IO-gebruik en hoge schrijfbewerkingen weer. Het laat ook zien dat de gemiddelde wachtrijgrootte en de gemiddelde verzoekgrootte in beweging zijn, wat betekent dat dit een indicatie is van een hoge werklast. In deze gevallen moet u bepalen of er externe processen zijn die ervoor zorgen dat MySQL de replicatiethreads verstikt.
Hoe kan ClusterControl helpen?
Met ClusterControl is het omgaan met slave-lag en het bepalen van de boosdoener heel eenvoudig en efficiënt. Het vertelt u direct in de web-UI, zie hieronder:
Het onthult u de huidige slave-lag die uw slave-knooppunten ervaren. Niet alleen dat, met SCUMM-dashboards, indien ingeschakeld, krijgt u meer inzicht in wat de gezondheid van uw slave-knooppunt of zelfs het hele cluster aan het doen is:
Niet alleen dat deze dingen beschikbaar zijn in ClusterControl, het biedt u ook de mogelijkheid om slechte zoekopdrachten te voorkomen met deze functies, zoals hieronder te zien is,
Met de redundante indexen kunt u bepalen of deze indexen prestatieproblemen kunnen veroorzaken voor inkomende query's die verwijzen naar de dubbele indexen. Het vertelt je ook tabellen die geen primaire sleutels hebben, wat meestal een veelvoorkomend probleem is van slave-lag wanneer een bepaalde SQL-query of transacties die verwijzen naar grote tabellen zonder primaire of unieke sleutels wanneer het wordt gerepliceerd naar de slaves.
Conclusie
Omgaan met MySQL-replicatievertraging is een veelvoorkomend probleem bij een master-slave-replicatie-installatie. Het kan gemakkelijk zijn om te diagnosticeren, maar moeilijk op te lossen. Zorg ervoor dat u tabellen met een primaire sleutel of een unieke sleutel hebt en bepaal de stappen en hulpmiddelen voor het oplossen van problemen en het diagnosticeren van de oorzaak van slaafvertraging. Efficiëntie is echter altijd de sleutel bij het oplossen van problemen.