Mysql奴隶陷入“系统locking”

我的MySQL从属在Slave_SQL_Running_State: System lock花费了很多时间Slave_SQL_Running_State: System lock 。 我可以看到系统当前I / O写入绑定,并且它正在处理日志,尽pipe缓慢。 当处于这种状态时, Show processlist不显示“等待主站发送事件”和“系统locking”以外的任何内容。

我的所有表(系统表除外)都是InnoDB,并且禁用了外部locking。 奴隶在这个状态下做什么?

以下是一些要求的信息:

首先,这是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) 

    运行在分布式存储facepalm上的数据库。 我会对运行在EC2 EBS存储系统之上的文件系统进行基准testing。 可能最简单的方法是使用s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc s=$(date +%s); dd if=/dev/zero of=<database-dir> bs=1M count=512; e=$(date +%s); echo "scale=4; 512 / ( $e - $s )" | bc 。 假设你有512MB空余空间。 现在,这个基准testing的问题是(1)没有考虑到caching效果,(2)解决scheme不是很好。 但是,如果这个testing很慢,那么问题肯定是EC2 EBS。 如果testing是快速或名义的,我们必须进一步挖掘和使用更复杂的技术。

    Bonnie ++程序有一定的适用性,但它不会在写入和读取之间刷新操作系统缓冲区(AFAIK)。 不过,你应该得到一个像bonnie++ -u mysql -r 8 -s 16:512 -n 1 -b -d <mysql-data-directory>的想法。 当我在本地存储上运行的虚拟机上执行此操作时,我得到:

     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 

    在这种情况下,您的从属EC2实例是否与主服务器的大小相似?

    如果你在一个较小的实例上运行来节省资金,那么你可能会跑到那里的一个瓶颈。 落后的时间是几天。 复制脱机了很长一段时间,还是在某种数据input尖峰期间随着时间的推移而增长?