故障案例 | 主从复制环境中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。
随时监测磁盘剩余空间，保障主从正常回放。