最近对数据库做了升级,从5.1升级到5.6,同时对备库做了innobackupex备份。然后奇怪的事情发生了,同样大小的两个备库,A备份的时候没有延时,响应时间正常,B备份延时400S左右,响应时间较长。于是进行了一番调查。
从MySQL 5.6的配置参数对比,两个实例都是一样,于是排除配置参数导致延时,从机器的性能对比,两个实例的服务器配置都是一样,连接数,qps都类似。于是着手查看innobackupex的原理;
innobackupex是一个封装了xtrabackup的Perl脚本,支持同时备份innodb和myisam,但在对myisam备份时需要加锁。她的主要工作原理如图:
innobackupex在步骤1,2阶段,数据库是正常情况,可读可写无影响。为了保持数据的一致性,对表加只读锁(步骤3),在步骤4中,如果表过多过大,将会导致这个步骤的完成时间过长,导致中间会有大量的>> log scanned up to (368469785511)
>> log scanned up to (368469785511)
>> log scanned up to (368469785511)存在,从而导致锁表时间过久,进而影响数据库响应时间。导致数据库延时。
而我遇到的问题正是备份库因为test库中有大量的表和数据量很大的表存在,导致锁表后copy文件过慢,从而大量的log scanned up ,导致响应慢,延时。清除test库中的垃圾数据后,备份恢复正常。无延时记录。