
故障案例 | 主从复制环境中tokudb引擎报错排查过程
0.背景介绍
在某系统中为了保证历史数据的压缩性,采用tokudb引擎存储数据。
slave节点所在机器数据盘总大小33TB,故障时磁盘剩余空间1.1TB。
1.现象描述
master节点正常进行,slave节点的数据库错误日志如下:
此时slave不可进行读写,回放中止
2.原因分析
由于此前没有处理过tokudb相关问题,且受此时磁盘剩余1.1TB空间影响。因此,第一反应是检查 tmpdir 空间是否足够。
检查 tmpdir 目录的空间和内容,确认空间足够,应该不是问题原因。
再次检查错误日志,其中 1030 Got error 28 from storage engine 表明可能是tokudb的限制,因此检查tokudb引擎相关参数。
其中注意到参数 tokudb_fs_reserve_percent:
手册里该参数的解释是:
看到默认设置是5,也就是说磁盘剩余可用空间低于5%的时候,拒绝写入,直到释放出更多的空间。
此时slave节点数据盘剩余3%,应为问题原因。
3.处理方法
● 如评估具备重启条件,可更改tokudb_fs_reserve_percent后重启(本环境考虑实例数据量较大、安全等因素,未采用此方案)。
● 清除过期的binlog和relaylog,purge binary logs & relay_log_purge。
● 由于该机器上部署多个slave节点,且每个slave积压大量的relay log(12TB),因此确认masterbinlog信息后使用reset slave暂时清理中继日志,重新获取。
● 清理相关日志、无用的安装包等。
● 联系业务清理无用的数据表,master节点先truncate,slave节点执行set sql_log_bin=0;truncate table;set sql_log_bin=1。
● 随时监测磁盘剩余空间,保障主从正常回放。
4. 总结
tokudb为了保障数据库服务正常,每5秒检测一次磁盘剩余空间,默认剩余5%的时候阻塞写入,直到释放更多的空间再恢复正常。
该限制由只读的静态参数 tokudb_fs_reserve_percent 控制剩余百分比。在INNODB、MYISAM等引擎上没有这个参数可配置,因此磁盘能够写到100%。
在使用tokudb时,应提前考虑好该参数设置,当监测到磁盘使用95%以前就要准备扩容。当然,5%只是默认的percona推荐值,实际使用中应根据数据盘大小进行调整。
参考文档
tokudb引擎磁盘空间不足致使写入失败的调查, http://www.javashuo.com/article/p-kqgrahfp-bd.html
1030 Got error 28 from storage engine, https://stackoverflow.com/questions/10631387/1030-got-error-28-from-storage-engine
percona参数解析, https://www.percona.com/doc/percona-server/5.6/tokudb/tokudb_variables.html
本文转载自公众号GreatSQL
