故障案例 | 主从复制环境中tokudb引擎报错排查过程

欢迎来到 GreatSQL社区分享的MySQL技术文章，如有疑问或想学习的内容，可以在下方评论区留言，看到后会进行解答

GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。

0.背景介绍

在某系统中为了保证历史数据的压缩性，采用tokudb引擎存储数据。

slave节点所在机器数据盘总大小33TB，故障时磁盘剩余空间1.1TB。

[root@redhat76-greatdb greatdb]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        33T   32T  1.1T  97% /
devtmpfs         63G     0   63G   0% /dev
tmpfs            63G     0   63G   0% /dev/shm
tmpfs            63G  4.0G   59G   7% /run

1.现象描述

master节点正常进行，slave节点的数据库错误日志如下：

2021-05-08T18:31:00.210203+08:00 44458 [ERROR] Slave SQL for channel '': Worker 1 failed executing transaction 'fb18799a-afeb-11eb-a3f0-fa163e18e1d9:513684180' at master log greatdb-bin.031344, end_log_pos 8397; Could not execute write_rows event on table test.t1; Got error 28 from storage engine, Error_code: 1030; handler error No Error!; the event's master log FIRST, end_log_pos 8397, Error_code:1030
2021-05-08T18:31:00.210236+08:00 44457 [Warning] Slave SQL for channel '': ... The slave coordinator and worker threads are stoppped, possibly leaving data in inconsistent state, A restart should restore consistency automatically, althougn using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code:1756

此时slave不可进行读写，回放中止

2.原因分析

由于此前没有处理过tokudb相关问题，且受此时磁盘剩余1.1TB空间影响。因此，第一反应是检查 tmpdir 空间是否足够。

MySQL [(none)]> show variables like '%tmpdir%';
+-------------------+----------------------------------------+
| Variable_name     | Value                                  |
+-------------------+----------------------------------------+
| innodb_tmpdir     |                                        |
| slave_load_tmpdir | /greatdb/tmp                           |
| tmpdir            | /greatdb/dbdata/greatdb57_data3307/tmp |
+-------------------+----------------------------------------+
3 rows in set (0.01 sec)

检查 tmpdir 目录的空间和内容，确认空间足够，应该不是问题原因。

再次检查错误日志，其中 1030 Got error 28 from storage engine 表明可能是tokudb的限制，因此检查tokudb引擎相关参数。

其中注意到参数 tokudb_fs_reserve_percent：

MySQL [(none)]> show variables like '%tokudb%fs%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| tokudb_fs_reserve_percent | 5     |
| tokudb_fsync_log_period   | 0     |
+---------------------------+-------+
2 rows in set (0.00 sec)

手册里该参数的解释是：

variable tokudb_fs_reserve_percent
Command Line: Yes
Config File: Yes
Scope: Global
Dynamic: No
Variable Type: Numeric
Range: 0-100
Default Value: 5
This variable controls the percentage of the file system that must be available for inserts to be allowed. By default, this is set to 5. We recommend that this reserve be at least half the size of your physical memory. See Full Disks for more information.

看到默认设置是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

Enjoy GreatSQL 😃

万答#12，MGR整个集群挂掉后，如何才能自动选主，不用手动干预
https://mp.weixin.qq.com/s/07o1poO44zwQIvaJNKEoPA

『2021数据技术嘉年华·ON LINE』：《MySQL高可用架构演进及实践》
https://mp.weixin.qq.com/s/u7k99y6i7riq7ScYs7ySnA

一条sql语句慢在哪之抓包分析
https://mp.weixin.qq.com/s/AYibbzl860D90rOeyjB6IQ

万答#15，都有哪些情况可能导致MGR服务无法启动
https://mp.weixin.qq.com/s/inSGpd0Q_XIl2Mb-VsvNsA

技术分享 | 为什么MGR一致性模式不推荐AFTER
https://mp.weixin.qq.com/s/rNeq479RNsklY1BlfKOsYg

关于 GreatSQL

GreatSQL是由万里数据库维护的MySQL分支，专注于提升MGR可靠性及性能，支持InnoDB并行查询特性，是适用于金融级应用的MySQL分支版本。

Gitee:
https://gitee.com/GreatSQL/GreatSQL

GitHub:
https://github.com/GreatSQL/GreatSQL

Bilibili：
https://space.bilibili.com/1363850082/video

微信&QQ群：
可搜索添加GreatSQL社区助手微信好友，发送验证信息“加群”加入GreatSQL/MGR交流微信群

QQ群：533341697
微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 发布！

posted @ 2021-12-21 13:40 GreatSQL 阅读(105) 评论(0) 编辑收藏举报

刷新页面返回顶部

GreatSQL