关于mysql:故障案例-主从复制环境中tokudb引擎报错排查过程

40次阅读

共计 3767 个字符，预计需要花费 10 分钟才能阅读完成。

欢送来到 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/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 公布！

正文完
mysql
发表至： mysql
2021-12-21
 0
关于mysql:技术分享-在GreatDB分布式部署模式中使用Chaos-Mesh做混沌测试
关于github:从零搭建自己的社区系统这个开源项目值得拥有
关于mysql:mysql-大数据表的分页性能优化
关于mysql:故障分析-MySQL-Router服务器后端那么闲为什么不让访问