Galera MySQL 5.7.17 bug 修复

阅读数:146 2019 年 9 月 15 日 23:18

Galera MySQL 5.7.17 bug修复

Galera MySQL 5.7.17 由于设置 innodb_undo_table_spaces 大于 0 导致使用 RSYNC 进行全量数据同步失败的原因及解决办法

Part.1

一 问题现场

将一个初始化过(执行过–initialize)的节点添加到 Galera MySQL 集群中时:数据同步完成后,Innodb 使用 undo log 中的记录回滚未提交的事务时会触发下面的 ERROR:

Galera MySQL 5.7.17 bug修复Galera MySQL 5.7.17 bug修复

ERROR 说 Innodb 访问了一个 undo log 表空间之外的数据页。

二 问题猜测

在 Galera MySQL 中,向正在运行的集群中添加一个节点时会触发全量数据同步——SST。SST 会选择一个 donor,并将这个 donor 的整个数据目录中的内容同步给新添加的节点。

照此,如果新添加的节点上的数据是 donor 节点的一份一模一样的拷贝的话,那 undo log 也会是 donor 节点正在使用的 undo log,理论上也就不会出现任何问题。

所以怀疑是在进行 SST 的时候出了问题,没能正常同步 undo log。

三 验证猜测

删除没能正常同步数据的节点数据文件夹夹内的所有文件(恢复到–initialize 之前的状态)并启动 MySQL,将这个节点添加到集群中,发现数据文件夹内并没有 undo log:

Galera MySQL 5.7.17 bug修复

于是产生上面 ERROR 的原因可以确定为是执行 SST 时没能正常同步 undo log table space。

Part.2

问题解决

出现问题的 Galera MySQL 集群使用 rsync 作为 SST 同步数据的方法;在使用 rsync 同步数据时默认会使用【/usr/bin/wsrep_sst_rsync】程序。

改程序在调用 rsync 传输数据之前会为 rsync 设置如下的文件过滤规则:

Galera MySQL 5.7.17 bug修复

可以看出文件过滤规则中虽然指定了 innodb 的系统表空间 iddata, 但是却没有添加 undo log 表空间的文件——以 undo 开头的文件:

Galera MySQL 5.7.17 bug修复

在 MySQL 5.7 之后的版本,为了避免大的事务造成系统表空间变的过大,将配置【innodb_undo_table_spaces】设置为大于 0 的值时,Innodb 使用独立于系统表空间之外的文件存储 undo log;但是 Galera MySQL 的【wsrep_sst_rsync】却没有考虑到这一点,导致进行数据同步时,没能正确同步独立的 undo log 表空间。

于是在 wsrep_sst_rsync 程序中设置文件过滤的行中进行如下修改:

之后就可以成功添加节点了。

Part.3

问题跟进

目前这个问题已经提交给了 Galera MySQL,并且已经被官方修复。

Galera MySQL 5.7.17 bug修复

本文转载自公众号滴滴技术(ID:didi_tech)。

原文链接:

https://mp.weixin.qq.com/s/wKdU7GskIIFRVDGOXKry-Q

评论

发布