Mysql Slave bị mắc kẹt trong hệ thống khóa Khóa

Nô lệ MySQL của tôi đang dành rất nhiều thời gian trong Slave_SQL_Running_State: System lock. Tôi có thể thấy rằng hệ thống hiện đang bị ràng buộc ghi I / O và nó đang xử lý nhật ký, mặc dù chậm. Show processlistkhông hiển thị bất cứ điều gì khác ngoài "Chờ chủ nhân gửi sự kiện" và "Khóa hệ thống" khi nó ở trạng thái này.

Tất cả các bảng của tôi (trừ các bảng hệ thống) là InnoDB và khóa ngoài bị vô hiệu hóa. Các nô lệ đang làm gì trong trạng thái này?

Đây là một số thông tin đã được yêu cầu:

Đầu tiên, đây là cộng đồng MySQL 5.6 trên phiên bản Amazon EC2, với tất cả lưu trữ trên 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)

Cơ sở dữ liệu chạy trên facepalm lưu trữ phân tán . Tôi sẽ điểm chuẩn hệ thống tập tin đang chạy trên hệ thống lưu trữ EC2 EBS. Có lẽ phương pháp đơn giản nhất là sử dụng một cái gì đó như s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc. Giả sử bạn có 512 MB để dự phòng. Bây giờ, vấn đề với điểm chuẩn này là (1) nó không tính đến các hiệu ứng bộ đệm và (2) độ phân giải không được tốt lắm. Nhưng nếu thử nghiệm này chậm, thì vấn đề chắc chắn là với EC2 EBS. Nếu thử nghiệm nhanh hoặc danh nghĩa, chúng ta phải đào sâu hơn và sử dụng các kỹ thuật tinh vi hơn.

Chương trình bonnie ++ có phần đầy đủ, nhưng nó không (AFAIK) xóa bộ đệm hệ điều hành giữa ghi và đọc. Tuy nhiên, bạn nên có một ý tưởng với một cái gì đó như bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>. Khi tôi thực hiện việc này trên máy ảo chạy trên bộ nhớ cục bộ, tôi nhận được:

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

Đây là những gì tôi nhận được khi chạy trên VM qua 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

Ví dụ EC2 nô lệ của bạn có kích thước tương tự với chủ trong trường hợp này không?

Nếu bạn đang chạy trên một ví dụ nhỏ hơn để tiết kiệm tiền, bạn có thể đang chạy vào cổ chai ở đó. Những giây phía sau là vài ngày. Được sao chép ngoại tuyến trong một thời gian dài hoặc điều này đã phát triển theo thời gian trong một số loại dữ liệu đầu vào tăng đột biến?