早上7点多接到一个数据库服务器空间报警,磁盘空间不足。登陆数据库查看,MySQL slave 大量延迟,有68G 的relay log。查看slave status 发现Relay_Log_Pos ,Exec_Master_Log_Pos 位点始终不变。
根据slave 复制的原理可知 relay_log_pos 是指sql_thread 进程读取relay log文件的位点,exec_master_log_pos是sql_thread 执行relay log中相对于 主库master binlog file的位点。那为什么sql_thread 一直显示静止状态呢? 我们如下几个方面思考
从结果上看IO利用率极低,不可能导致sql_thread执行缓慢的或者静止的。
使用pt-pmp工具查看数据库进程此时的状态,能否获得一些线索。从pt-pmp执行结果上来看,注意 execute_command, reader_loop 函数,说明数据库一直在执行sql语句,只是执行的比较缓慢,循环读取relay log中的event 。我们进一步将问题范围缩小。
实际过程中该问题于晚上22点左右将延迟的relaylog应用完毕,该服务器的磁盘为sas 机械盘,io能力较差。如果更换为SSD 存储介质应该会更快一些。各位读者朋友如果还有其他想法,可以留言相互交流提供更好的解决方法。
主从复制结构是大家常用的MySQL 高可用的方案,但是往往由于各种因素,表结构设计不合理,主库大量写,从库备份等原因导致slave延迟,影响整体的可用性。MySQL DBA 一定要仔细review 数据库表结构设计,杜绝这类延迟隐患发生。