sql >> Database teknologi >  >> RDS >> MariaDB

Hvad skal du kigge efter, hvis din MySQL-replikering halter

En master/slave-replikeringsklyngeopsætning er en almindelig brugssag i de fleste organisationer. Brug af MySQL-replikering gør det muligt for dine data at blive replikeret på tværs af forskellige miljøer og garanterer, at oplysningerne bliver kopieret. Den er asynkron og enkelttrådet (som standard), men replikering giver dig også mulighed for at konfigurere den til at være synkron (eller faktisk "semi-synkron") og kan køre slavetråd til flere tråde eller parallelt.

Denne idé er meget almindelig og kommer normalt med en simpel opsætning, hvilket gør, at dens slave fungerer som dens gendannelse eller til backup-løsninger. Dette kommer dog altid til en pris, især når dårlige forespørgsler (såsom mangel på primære eller unikke nøgler) replikeres eller nogle problemer med hardwaren (såsom netværks- eller disk-IO-problemer). Når disse problemer opstår, er det mest almindelige problem replikationsforsinkelsen.

En replikeringsforsinkelse er omkostningerne ved forsinkelse for transaktion(er) eller operation(er) beregnet ved dens tidsforskel i udførelsen mellem primær/master mod standby/slaveknude. De mest sikre tilfælde i MySQL er afhængige af, at dårlige forespørgsler replikeres, såsom mangel på primære nøgler eller dårlige indekser, dårlig netværkshardware eller fejlfungerende netværkskort, en fjern placering mellem forskellige regioner eller zoner, eller nogle processer, såsom fysiske sikkerhedskopier, kan forårsage din MySQL-database for at forsinke anvendelsen af ​​den aktuelle replikerede transaktion. Dette er et meget almindeligt tilfælde, når man diagnosticerer disse problemer. I denne blog vil vi tjekke, hvordan man håndterer disse sager, og hvad man skal se, hvis du oplever MySQL-replikeringsforsinkelse.

"VIS SLAVESTATUS":MySQL DBA's Mantra

I nogle tilfælde er dette det fineste punkt, når det drejer sig om replikeringsforsinkelse, og det afslører stort set alt, hvad der er årsagen til et problem i din MySQL-database. Kør blot denne SQL-sætning i din slaveknude, der er mistænkt for at opleve en replikeringsforsinkelse.

De indledende felter, der er almindelige at spore for problemer, er,

  • Slave_IO_State - Det fortæller dig, hvad tråden laver. Dette felt giver dig god indsigt, hvis replikeringstilstanden kører normalt, står over for netværksproblemer, såsom genforbindelse til en master eller tager for lang tid at commitere data, hvilket kan indikere diskproblemer, når data synkroniseres til disk. Du kan også bestemme denne tilstandsværdi, når du kører SHOW PROCESSLIST.
  • Master_Log_File -  Masters binlog-filnavn, hvor I/O-tråden i øjeblikket hentes.
  • Read_Master_Log_Pos - Binlog-filposition fra masteren, hvor replikerings-I/O-tråden allerede har læst.
  • Relay_Log_File - det relælogfilnavn, som SQL-tråden i øjeblikket udfører hændelserne for
  • Relay_Log_Pos - binlog-position fra filen specificeret i Relay_Log_File, som SQL-tråden allerede er udført for.
  • Relay_Master_Log_File - Masterens binlog-fil, som SQL-tråden allerede har udført, og som er kongruent med Read_Master_Log_Pos-værdien.
  • Seconds_Behind_Master -  dette felt viser en tilnærmelse af forskellen mellem det aktuelle tidsstempel på slaven og tidsstemplet på masteren for den hændelse, der i øjeblikket behandles på slaven. Dette felt kan dog muligvis ikke fortælle dig den nøjagtige forsinkelse, hvis netværket er langsomt, fordi forskellen i sekunder tages mellem slave SQL-tråden og slave-I/O-tråden. Så der kan være tilfælde, hvor det kan blive fanget med langsomt læsende slave I/O-tråd, men jeg mestrer, at det allerede er anderledes.
  • Slave_SQL_Running_State - SQL-trådens tilstand og værdien er identisk med tilstandsværdien vist i VIS PROCESSLISTE.
  • Retrieved_Gtid_Set - Tilgængelig ved brug af GTID-replikering. Dette er det sæt af GTID'er, der svarer til alle transaktioner modtaget af denne slave.
  • Executed_Gtid_Set - Tilgængelig ved brug af GTID-replikering. Det er sættet af GTID'er skrevet i den binære log.

Lad os f.eks. tage eksemplet nedenfor, som bruger en GTID-replikering og oplever en replikeringsforsinkelse:

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)

I diagnosticering af problemer som dette kan mysqlbinlog også være dit værktøj til at identificere, hvilken forespørgsel der har kørt på en specifik binlog x &y-position. For at bestemme dette, lad os tage Retrieved_Gtid_Set, Relay_Log_Pos og Relay_Log_File. Se kommandoen nedenfor:

[[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*/;

Det fortæller os, at det forsøgte at replikere og udføre en DML-sætning, som forsøger at være kilden til forsinkelsen. Denne tabel er en enorm tabel, der indeholder 13M rækker.

Tjek VIS PROCESLISTE, VIS MOTORENS INNODB-STATUS, med ps, top, iostat-kommandokombination

I nogle tilfælde er VIS SLAVESTATUS ikke nok til at fortælle os synderen. Det er muligt, at de replikerede udsagn er påvirket af interne processer, der kører i MySQL-databaseslaven. Kørsel af udsagn SHOW [FULL] PROCESSLIST og SHOW ENGINE INNODB STATUS giver også informative data, der giver dig indsigt i kilden til problemet.

Lad os f.eks. sige, at der kører et benchmarking-værktøj, som gør, at diskens IO og CPU bliver mættet. Du kan tjekke ved at køre begge SQL-sætninger. Kombiner det med ps og topkommandoer.

Du kan også bestemme flaskehalse med dit disklager ved at køre iostat, som giver statistik over det aktuelle volumen, du forsøger at diagnosticere. Kørende iostat kan vise, hvor optaget eller indlæst din server er. For eksempel taget af en slave, som halter, men samtidig oplever høj IO-udnyttelse, 

[[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.00

Resultatet ovenfor viser den høje IO-udnyttelse og en høj skrivning. Det afslører også, at den gennemsnitlige køstørrelse og den gennemsnitlige anmodningsstørrelse bevæger sig, hvilket betyder, at det er en indikation af en høj arbejdsbyrde. I disse tilfælde skal du afgøre, om der er eksterne processer, der får MySQL til at kvæle replikeringstrådene.

Hvordan kan ClusterControl hjælpe?

Med ClusterControl er det meget nemt og effektivt at håndtere slavelag og afgøre synderen. Det fortæller dig det direkte i web-UI, se nedenfor:

Det afslører for dig den aktuelle slaveforsinkelse, som dine slaveknuder oplever. Ikke nok med det, med SCUMM-dashboards, hvis aktiveret, giver det dig mere indsigt i, hvad din slaveknudes helbred eller endda hele klyngen gør:

Ikke kun at disse ting er tilgængelige i ClusterControl, det giver dig også evnen til at undgå, at der opstår dårlige forespørgsler med disse funktioner som vist nedenfor,

De overflødige indekser giver dig mulighed for at bestemme, at disse indekser kan forårsage ydeevneproblemer for indgående forespørgsler, der refererer til de duplikerede indekser. Det fortæller dig også tabeller, der ikke har nogen primære nøgler, hvilket normalt er et almindeligt problem med slaveforsinkelse, når en bestemt SQL-forespørgsel eller transaktioner, der refererer til store tabeller uden primære eller unikke nøgler, når den replikeres til slaverne.

Konklusion

Håndtering af MySQL-replikeringsforsinkelse er et hyppigt problem i en master-slave-replikeringsopsætning. Det kan være nemt at diagnosticere, men svært at løse. Sørg for, at du har dine tabeller med primær nøgle eller unik nøgle eksisterende, og bestem trinene og værktøjerne til, hvordan du fejlfinder og diagnosticerer årsagen til slaveforsinkelse. Effektivitet er dog altid nøglen, når man løser problemer.


  1. Hvad er den tilsvarende PostgreSQL-syntaks til Oracles CONNECT BY ... START WITH?

  2. Søg i alle tabeller, alle kolonner for en bestemt værdi SQL Server

  3. Gør SQL Server-ydeevne let

  4. Matching af udbud og efterspørgsel — løsninger, del 2