欢送来到 GreatSQL社区分享的MySQL技术文章，如有疑难或想学习的内容，能够在下方评论区留言，看到后会进行解答
  • GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

0.背景介绍

在某零碎中为了保障历史数据的压缩性，采纳tokudb引擎存储数据。

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

[root@redhat76-greatdb greatdb]# df -hFilesystem      Size  Used Avail Use% Mounted on/dev/vda1        33T   32T  1.1T  97% /devtmpfs         63G     0   63G   0% /devtmpfs            63G     0   63G   0% /dev/shmtmpfs            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:10302021-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_percentCommand Line: YesConfig File: YesScope: GlobalDynamic: NoVariable Type: NumericRange: 0-100Default Value: 5This 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/artic...
  • 1030 Got error 28 from storage engine, https://stackoverflow.com/que...
  • percona参数解析, https://www.percona.com/doc/p...

Enjoy GreatSQL :)

文章举荐：

GreatSQL MGR FAQ
https://mp.weixin.qq.com/s/J6...

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

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

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

万答#15，都有哪些状况可能导致MGR服务无奈启动
https://mp.weixin.qq.com/s/in...

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

对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

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

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

Bilibili：
https://space.bilibili.com/13...

微信&QQ群：
可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697
微信小助手：wanlidbc

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