MySQL-Slave steckt in "Systemsperre"


8

Mein MySQL-Slave verbringt viel Zeit in Slave_SQL_Running_State: System lock. Ich kann sehen, dass das System derzeit an E / A-Schreibvorgänge gebunden ist und das Protokoll verarbeitet, wenn auch langsam. Show processlistzeigt nichts anderes als "Warten auf das Senden des Ereignisses durch den Master" und "Systemsperre" an, wenn es sich in diesem Zustand befindet.

Alle meine Tabellen (außer den Systemtabellen) sind InnoDB und die externe Sperre ist deaktiviert. Was macht der Sklave in diesem Zustand?

Hier sind einige Informationen, die angefordert wurden:

Erstens ist dies die MySQL 5.6-Community auf einer Amazon EC2-Instanz mit sämtlichem Speicher auf 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
Ist mit Ihrem Speicher etwas los? Wenn es sich um eine lokale Festplatte handelt, erhalten Sie SMART-Warnungen oder befindet sich diese möglicherweise in einem verschlechterten RAID-Array?
Nedm

Bitte geben Sie einige relevante Einträge aus mysqld.logdem Zeitpunkt an, als die Replikation beim ersten Mal unterbrochen wurde, UND senden Sie die Ausgabe von folgenden Stellen: mysql> SHOW SLAVE STATUS \ G; mysql> SHOW FULL PROCESSLIST;
Alexus

Es ist ein EC2-EBS-Volume. Es gibt keine Fehler in dmesg.
Greg

1
Beachten Sie, dass dies einfach ein Fehler von 5.6 sein kann. Prüfen Sie dies anhand einer anderen Version (z. B. 5.5): forums.mysql.com/read.php?22,598354,598354
the-wabbit

1
Hier ist die Definition des Systemsperrstatus. Sieht so aus, als könnte es damit zusammenhängen, dass Ihr System an E / A-Schreibvorgänge gebunden ist. Systemsperre - Der Thread fordert eine interne oder externe Systemsperre für die Tabelle an oder wartet auf diese. Für SHOW PROFILE bedeutet dieser Status, dass der Thread die Sperre anfordert (nicht darauf wartet). von: dev.mysql.com/doc/refman/5.6/en/general-thread-states.html
jbrahy

Antworten:


2

Datenbanken, die auf verteiltem Speicher facepalm ausgeführt werden . Ich würde das Dateisystem vergleichen, das auf dem EC2 EBS-Speichersystem ausgeführt wird. Die wahrscheinlich einfachste Methode ist es, so etwas zu verwenden s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc. Das setzt voraus, dass Sie 512 MB übrig haben. Das Problem bei diesem Benchmarking ist nun, dass (1) Caching-Effekte nicht berücksichtigt werden und (2) die Auflösung nicht sehr gut ist. Aber wenn dieser Test langsam ist, dann ist das Problem auf jeden Fall mit EC2 EBS. Wenn der Test schnell oder nominal ist, müssen wir weiter graben und ausgefeiltere Techniken anwenden.

Das Programm bonnie ++ ist etwas ausreichend, aber es (AFAIK) leert die Betriebssystempuffer nicht zwischen Schreiben und Lesen. Trotzdem sollten Sie sich mit so etwas ein Bild machen bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. Wenn ich dies auf einer VM mache, die auf lokalem Speicher ausgeführt wird, erhalte ich:

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

Folgendes bekomme ich, wenn ich auf einer VM über NFS ausgeführt werde:

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

Hat Ihre Slave-EC2-Instanz in diesem Fall eine ähnliche Größe wie der Master?

Wenn Sie auf einer kleineren Instanz arbeiten, um Geld zu sparen, stoßen Sie dort möglicherweise auf einen Flaschenhals. Die Sekunden dahinter sind mehrere Tage. War die Replikation lange Zeit offline oder wuchs sie im Laufe der Zeit während einer Art Dateneingabespitze?


Der Sklave ist definitiv langsamer. Ich frage mich, ob es eine Möglichkeit gibt, herauszufinden, an welcher Abfrage der Slave arbeitet, genau wie "Prozessliste anzeigen" auf dem Master anzeigt, welche Abfragen ausgeführt werden.
Greg

1
Es ist eine Protokollwiedergabe. In der zuvor bereitgestellten Ausgabe können Sie sehen, wo sich Slave und Master befinden. Read_Master_Log_Pos: 505452667 Relay_Log_Pos: 345413863
zaznet
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.