Budak Mysql terjebak di "Kunci sistem"

Budak MySQL saya menghabiskan banyak waktu di Slave_SQL_Running_State: System lock. Saya dapat melihat bahwa sistem saat ini I / O terikat tulisan, dan bahwa ia sedang memproses log, meskipun lambat. Show processlisttidak menampilkan apa pun selain "Menunggu master mengirim acara" dan "Kunci sistem" saat berada dalam keadaan ini.

Semua tabel saya (selain tabel sistem) adalah InnoDB, dan penguncian eksternal dinonaktifkan. Apa yang dilakukan budak di negara bagian ini?

Berikut beberapa info yang telah diminta:

Pertama, ini adalah komunitas MySQL 5.6 pada instance Amazon EC2, dengan semua penyimpanan di 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)

Database berjalan pada facepalm penyimpanan terdistribusi . Saya akan membandingkan sistem file yang berjalan di atas sistem penyimpanan EC2 EBS. Mungkin metode paling sederhana adalah menggunakan sesuatu seperti s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc. Itu mengasumsikan Anda memiliki 512 MB untuk cadangan. Sekarang, masalah dengan pembandingan ini adalah (1) tidak memperhitungkan efek caching akun, dan (2) resolusi tidak terlalu baik. Tetapi jika tes ini lambat, maka masalahnya pasti dengan EC2 EBS. Jika tes cepat atau nominal, kita harus menggali lebih jauh dan menggunakan teknik yang lebih canggih.

Program bonnie ++ agak memadai, tetapi tidak (AFAIK) menyiram buffer OS antara menulis dan membaca. Tetap saja, Anda harus mendapatkan ide dengan sesuatu seperti bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. Ketika saya melakukan ini pada VM yang berjalan pada penyimpanan lokal, saya mendapatkan:

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

Berikut adalah apa yang saya dapatkan ketika menjalankan VM lebih dari 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

Apakah instance EC2 slave Anda mirip dengan master dalam hal ini?

Jika Anda menggunakan contoh yang lebih kecil untuk menghemat uang, Anda mungkin akan menemukan botol leher di sana. Detik di belakang adalah beberapa hari. Apakah replikasi offline untuk waktu yang lama atau apakah ini tumbuh seiring waktu selama beberapa jenis lonjakan input data?