Mysql Slave bloccato in "Blocco sistema"


8

Il mio slave MySQL sta trascorrendo molto tempo Slave_SQL_Running_State: System lock. Riesco a vedere che il sistema è attualmente associato alla scrittura I / O e che sta elaborando il registro, sebbene lentamente. Show processlistnon mostra altro che "In attesa che il master invii l'evento" e "Blocco sistema" quando si trova in questo stato.

Tutte le mie tabelle (diverse dalle tabelle di sistema) sono InnoDB e il blocco esterno è disabilitato. Cosa sta facendo lo schiavo in questo stato?

Ecco alcune informazioni che sono state richieste:

Innanzitutto, questa è la community MySQL 5.6 su un'istanza Amazon EC2, con tutto l'archiviazione su EBS.

mysql> show processlist;
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
| Id | User        | Host      | db            | Command | Time   | State                            | Info             |
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
|  1 | system user |           | NULL          | Connect |  26115 | Waiting for master to send event | NULL             |
|  2 | system user |           | NULL          | Connect | 402264 | System lock                      | NULL             |
| 14 | readonly    | localhost | theshadestore | Query   |      0 | init                             | show processlist |
+----+-------------+-----------+---------------+---------+--------+----------------------------------+------------------+
3 rows in set (0.00 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 184.106.16.14
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: bin-log.000764
          Read_Master_Log_Pos: 505452667
               Relay_Log_File: relay-log.000197
                Relay_Log_Pos: 345413863
        Relay_Master_Log_File: bin-log.000746
             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: 345413702
              Relay_Log_Space: 19834085375
              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: 402263
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: 307009
                  Master_UUID: b1bf9a19-dac0-11e2-8ffa-b8ca3a5bce90
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)

1
Qualcosa sta succedendo con la tua memoria? Se si tratta di un disco locale, ricevi avvisi SMART o è forse in un array RAID degradato?
nedm,

Fornisci alcune voci pertinenti da mysqld.logquando la replica si è interrotta per la prima volta E pubblica l'output dal seguente: mysql> SHOW SLAVE STATUS \ G; mysql> MOSTRA ELENCO PROCESSI COMPLETO;
alexus

È un volume EBS EC2. Non ci sono errori in dmesg.
Greg,

1
nota che questo potrebbe semplicemente essere un bug di 5.6, considera di verificare con un'altra versione (es. 5.5): forums.mysql.com/read.php?22.598354.598354
the-wabbit

1
Ecco la definizione di System Lock State. Sembra che potrebbe essere correlato al fatto che il tuo sistema sia associato alla scrittura I / O. Blocco del sistema: il thread richiederà o è in attesa di un blocco del sistema interno o esterno per la tabella. Per SHOW PROFILE, questo stato indica che il thread richiede il blocco (non lo attende). da: dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
jbrahy

Risposte:


2

Database in esecuzione su facepalm di archiviazione distribuita . Vorrei confrontare il filesystem in esecuzione sul sistema di archiviazione EBS EC2. Probabilmente il metodo più semplice è usare qualcosa di simile s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc. Ciò presuppone che tu abbia 512 MB di riserva. Ora, il problema con questo benchmarking è che (1) non tiene conto degli effetti della cache e (2) la risoluzione non è molto buona. Ma se questo test è lento, allora il problema è sicuramente con EBS EC2. Se il test è veloce o nominale, dobbiamo scavare ulteriormente e utilizzare tecniche più sofisticate.

Il programma bonnie ++ è in qualche modo adeguato, ma non (AFAIK) scarica i buffer del sistema operativo tra la scrittura e la lettura. Tuttavia, dovresti avere un'idea con qualcosa del genere bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. Quando lo faccio su una VM in esecuzione su memoria locale, ottengo:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test        16M:512  1173  99 +++++ +++ +++++ +++  3187  99 +++++ +++ +++++ +++
Latency              1553us      23us     330us     750us     173us    6372us
Version  1.96       ------Sequential Create------ --------Random Create--------
test                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1  1850  20 +++++ +++ +++++ +++ +++++ +++ +++++ +++ +++++ +++
Latency             27428us      24us    1188us   30258us      36us    1107us

Ecco cosa ottengo quando eseguo una macchina virtuale su NFS:

Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
test        16M:512  1273  98 +++++ +++ +++++ +++  3053  99 +++++ +++ +++++ +++
Latency              1372us      28us     380us     832us      19us    9473us
Version  1.96       ------Sequential Create------ --------Random Create--------
test                -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1   754  11 +++++ +++   728   8   751  12 +++++ +++   791   8
Latency             12695us      47us    5306us    3710us      30us    3278us

0

In questo caso la tua istanza slave EC2 ha dimensioni simili a quelle del master?

Se stai eseguendo un'istanza più piccola per risparmiare denaro, potresti incorrere in un collo di bottiglia lì. I secondi dietro sono diversi giorni. La replica è stata offline per molto tempo o è cresciuta nel tempo durante un qualche picco di input di dati?


Lo schiavo è decisamente più lento. Mi chiedo se c'è un modo per sapere su quale query lo slave sta lavorando, proprio come il modo "show processlist" sul master mostra quali query sono in esecuzione.
Greg

1
È un replay del registro. È possibile vedere dove si trovano lo slave e il master nell'uscita precedentemente fornita. Read_Master_Log_Pos: 505452667 Relay_Log_Pos: 345413863
zaznet
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.