Mysqlスレーブが「システムロック」でスタック


8

MySQLスレーブはで多くの時間を費やしていSlave_SQL_Running_State: System lockます。システムは現在I / O書き込みバウンドであり、ゆっくりではありますがログを処理していることがわかります。Show processlistこの状態の場合、「マスターがイベントを送信するのを待っています」と「システムロック」以外は表示されません。

すべての私のテーブル(システムテーブルを除く)はInnoDBであり、外部ロックは無効になっています。この状態でスレーブは何をしていますか?

リクエストされた情報は次のとおりです。

まず、これはAmazon EC2インスタンス上のMySQL 5.6コミュニティであり、すべてのストレージが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
ストレージで何か起こっていますか?ローカルディスクの場合、SMART警告が表示されますか、それとも劣化したRAIDアレイにあるのでしょうか?
nedm 2013年

いくつかの関連するエントリを提供してくださいmysqld.log、レプリケーションが初めてで破ったとき、次のポスト出力:MySQLの> SHOW SLAVEのステータス\ Gを、mysql> SHOW FULL PROCESSLIST;
alexus 2013年

EC2 EBSボリュームです。dmesgにエラーはありません。
グレッグ

1
これは単に5.6のバグである可能性があることに注意してください。別のバージョン(例:5.5)でチェックすることを検討してください:forums.mysql.com/read.php?22,598354,598354
the-wabbit

1
システムロック状態の定義は次のとおりです。システムがI / O書き込みにバインドされていることに関連している可能性があります。システムロック-スレッドは、テーブルの内部または外部システムロックを要求するか、または待機しています。SHOW PROFILEの場合、この状態は、スレッドがロックを要求している(ロックを待機していない)ことを意味します。差出人
jbrahy

回答:


2

分散ストレージfacepalmで実行されるデータベース。EC2 EBSストレージシステム上で実行されているファイルシステムをベンチマークします。おそらく最も簡単な方法はのようなものを使用することですs=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc。これは、512 MBの空き容量があることを前提としています。さて、このベンチマークの問題は、(1)キャッシュ効果を考慮していないこと、(2)解像度があまり良くないことです。しかし、このテストが遅い場合、問題は間違いなくEC2 EBSにあります。テストが高速または公称である場合、さらに掘り下げて、より洗練された手法を使用する必要があります。

bonnie ++プログラムはやや適切ですが、書き込みと読み取りの間でOSバッファーをフラッシュしません(AFAIK)。それでも、のようなものでアイデアを得る必要がありますbonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>。ローカルストレージで実行されているVMでこれを行うと、次のようになります。

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

NFS経由のVMで実行すると、次のようになります。

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

この場合、スレーブEC2インスタンスはマスターと同じサイズですか?

お金を節約するために小さなインスタンスで実行している場合は、そこでボトルネックに陥っている可能性があります。数秒遅れます。レプリケーションは長い間オフラインでしたか、それとも、ある種のデータ入力スパイクの間に時間とともに増加しましたか?


奴隷は明らかに遅いです。マスターの「show processlist」がどのクエリが実行されているかを表示するのと同じように、スレーブがどのクエリに取り組んでいるかを知る方法があるかどうか疑問に思っています。
グレッグ、

1
ログの再生です。以前に提供された出力で、スレーブとマスターの位置を確認できます。Read_Master_Log_Pos:505452667 Relay_Log_Pos:345413863
zaznet
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.