MySQL 8 升级的故事及其对备份的影响

最近，我们在一个客户环境中进行了大版本升级，从 MySQL 5.7.26 升级到 8.0.27。在此版本升级后，我们遇到了其中一个节点的备份和复制问题。

在本位中，我将详细解释这些问题，并推荐一种从复制环境进行备份的方法。

首先，我们将所有的数据库节点从5.7.26升级到8.0.27，作为推荐方法，我们对其中一个副本节点进行备份设置。使用 Percona XtraBackup （PXB）进行物理备份，因此在备份期间不会锁定数据库。

对于 MySQL5.7 ，使用 PXB2.4 进行备份。由于 MySQL8.0 中新的数据字典、重做日志和回滚日志，在将数据库升级到8.0 之后，我们还将 PXB 升级到 8.0.27 以避免兼容性问题。

在详细讨论我们最初的问题之前，让我们看看在从复制环境进行备份以确保一致性时 PXB 应使用的一些选项。在本例中也使用了这些选项

–slave-info：它打印并存储源服务器的二进制日志位置，这对于从源创建新副本非常有用。

-safe-slave-backup：此选项对于处理副本上的临时表非常有用，当使用此选项时，它会停止 SQL 线程，并等到没有临时表后再进行备份。

-lock-ddl：此选项在备份运行时阻止副本上所有 DDL 操作，因此任何 DDL 事件都不会破坏备份。DML 都可以继续， DDL 被阻止。

现在回到我们最初的问题，在数据库升级到 8.0.27 之后，我们注意到了几个与备份相关的问题。我们注意到的一个主要问题是备份期间副本节点上的复制失败。

我们确定了以下事项，以确保升级后没有任何变化：

1. 备份命令没有更改
2. 所有的表都是 InnoDB 存储引擎，并且没有做存储引擎更改。

此外，我们注意到每当 PXB 开始进行备份时，备份服务器上的复制就会停止。进一步检查后，我们注意到只有 SQL 线程在备份启动时停止，IO 线程保持运行。这是因为 PXB 使用 -safe-slave-backup 备份选项运行，这是前面提到的从副本节点进行备份的推荐方法。

但是，我们注意到，在5.7环境中，备份也使用 -safe-slave-backup 选项运行，而且当时备份运行良好，复制也没有问题。在这次大版本升级中，我们对备份所做的唯一更改是将 PXB 版本从 2.4.20 升级到 8.0.27。

为更深入的理解，我做了一个简单的测试，使用 PXB 8.0.27 和 PXB 2.4.26 进行备份。在这个测试中，我注意到在 PXB 8.0中，-safe-slave-backup 在备份开始后立即停止 SQL 线程（甚至在复制 InnoDB 文件之前）。在这个测试场景中，完整的备份大约需要20秒才能完成，SQL 线程在整个过程中都处于停止状态。

2022-09-09T11:15:00.668080-00:00 0 [Note] [MY-011825] [Xtrabackup] Using server version 8.0.27

**2022-09-09T11:15:00.717674-00:00 0 [Note] [MY-011825] [Xtrabackup] Slave open temp tables: 0

2022-09-09T11:15:00.720502-00:00 0 [Note] [MY-011825] [Xtrabackup] Slave is safe to backup.**

2022-09-09T11:15:00.720573-00:00 0 [Note] [MY-011825] [Xtrabackup] Executing LOCK INSTANCE FOR BACKUP 

...

...

...

2022-09-09T11:15:01.248442-00:00 2 [Note] [MY-011825] [Xtrabackup] Copying ./db/t.ibd to /root/backups/db/t.ibd

2022-09-09T11:15:01.980691-00:00 1 [Note] [MY-011825] [Xtrabackup] >> log scanned up to (64948804922)

...

...

**2022-09-09T11:15:19.589799-00:00 0 [Note] [MY-011825] [Xtrabackup] Executing FLUSH TABLES WITH READ LOCK...**

**2022-09-09T11:15:19.590675-00:00 0 [Note] [MY-011825] [Xtrabackup] Starting to backup non-InnoDB tables and files**

...

...

2022-09-09T11:15:20.610477-00:00 0 [Note] [MY-011825] [Xtrabackup] Finished backing up non-InnoDB tables and files

2022-09-09T11:15:20.676140-00:00 0 [Note] [MY-011825] [Xtrabackup] Stopping log copying thread at LSN 64948804922

2022-09-09T11:15:20.728679-00:00 0 [Note] [MY-011825] [Xtrabackup] Executing UNLOCK INSTANCE

2022-09-09T11:15:20.729034-00:00 0 [Note] [MY-011825] [Xtrabackup] Executing UNLOCK TABLES

2022-09-09T11:15:20.729254-00:00 0 [Note] [MY-011825] [Xtrabackup] All tables unlocked

**2022-09-09T11:15:20.729268-00:00 0 [Note] [MY-011825] [Xtrabackup] Starting slave SQL thread**

...

...

2022-09-09T11:15:22.099206-00:00 0 [Note] [MY-011825] [Xtrabackup] completed OK!

然而，在 PXB2.4 版本中，只有在复制非 InnoDB 文件时，SQL 线程才会停止，并在备份 InnoDB 文件的时候，SQL 线程不会停止。因此，在整个20秒的备份期间，SQL线程仅停止了4秒。

Using server version 5.7.26

/usr/bin/xtrabackup version 2.4.26 based on MySQL server 5.7.35 Linux (x86_64) (revision id: 19de43b)

...

...

220909 11:20:21 [01] Copying ./db/t.ibd to /root/backups/db/t.ibd

220909 11:20:22 >> log scanned up to (3991557882)

...

220909 11:20:35 >> log scanned up to (3991557882)

220909 11:20:35 [01]        ...done

...

...

**220909 11:20:36 Slave open temp tables: 0

220909 11:20:36 Slave is safe to backup.**

220909 11:20:36 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...

220909 11:20:36 Executing FLUSH TABLES WITH READ LOCK...

**220909 11:20:36 Starting to backup non-InnoDB tables and files**

...

...

220909 11:20:40 Finished backing up non-InnoDB tables and files

...

...

**220909 11:20:40 Executing UNLOCK TABLES

220909 11:20:40 All tables unlocked

Starting slave SQL thread**

...

...

220909 11:20:40 completed OK!