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：

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

二 问题猜测

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

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

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

三 验证猜测

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

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

Part.2

问题解决

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

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

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

在 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，并且已经被官方修复。

本文转载自公众号滴滴技术（ID：didi_tech）。

原文链接：

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