MySQL8升级对备份的影响
2023-01-13 08:59 abce 阅读(137) 评论(0) 编辑 收藏 举报最近将MySQL5.7.26升级到8.0.27后，备份遇到了一些问题。
升级采用的是使用复制节点的备份，使用percona xtrabackup做的的物理备份。
对于MySQL5.7，用的是PXB2.4做的物理备份。考虑到兼容性的问题，在升级到MySQL8.0后，也将PXB升级到了8.0.27。
在讨论遇到的问题之前，来看看PXB的一些选项：
·slave-info
打印和存储源库的二进制日志的位置
·safe-slave-backup
帮助处理复制节点的临时表，当使用该参数时，会停止sql thread、等待直到没有临时表表了才会开始备份
·lock-ddl
备份时，该选项会阻塞从库上所有的ddl操作，这样就不会有ddl事件损坏备份。dml事件仍然会继续，只会阻塞ddl事件。
回来之前提到的问题，在数据库顺利升级到MySQL8.0.27之后，我们遇到了好几个与备份有关的问题。其中一个主要的问题就是在从库执行备份的时候，从库复制失败了。
通过以下两项我们确定了在升级后没有做别的改动：
1.备份命令没有变化
2.所有表都是innodb表，没有发生引擎变化
此外，我们发现，一旦pxb开始备份，所在的从库的复制就会停止。进一步检查，我们发现只是sql thread停止了，而io thread是运行的。这就指向一个事实，复制中断是因为pxb在备份的时候开启了--safe-slave-backup选项。在从库执行备份也是推荐开启该参数。
然后，我们注意到在5.7中，备份也是开启了选项--safe-slave-backup,但是备份运行正常且复制也不会受到影响。只不过在升级MySQL的同时，也将pxb从2.4.20升级到了8.0.27。
为了更深入的了解，我做了一个简单的测试。使用PXB 8.0.27和PXB 2.4.26做备份。在测试中，发现PXB8.0,参数的--safe-slave-backup在备份开始后停掉了sql thread(在拷贝innodb文件之前)。在这个测试中，完整的备份需要20秒完成，在整个备份过程中，sql thread都是被停掉的。
2022-12-23T10:43:00.668080-00:00 0 [Note] [MYTEST] [Xtrabackup] Using server version 8.0.27 **2022-12-23T10:43:00.717674-00:00 0 [Note] [MYTEST] [Xtrabackup] Slave open temp tables: 0 2022-12-23T10:43:00.720502-00:00 0 [Note] [MYTEST] [Xtrabackup] Slave is safe to backup.** 2022-12-23T10:43:00.720573-00:00 0 [Note] [MYTEST] [Xtrabackup] Executing LOCK INSTANCE FOR BACKUP ... ... ... 2022-12-23T10:43:01.248442-00:00 2 [Note] [MYTEST] [Xtrabackup] Copying ./db/t.ibd to /root/backups/db/t.ibd 2022-12-23T10:43:01.980691-00:00 1 [Note] [MYTEST] [Xtrabackup] >> log scanned up to (64948804922) ... ... **2022-12-23T10:43:19.589799-00:00 0 [Note] [MYTEST] [Xtrabackup] Executing FLUSH TABLES WITH READ LOCK...** **2022-12-23T10:43:19.590675-00:00 0 [Note] [MYTEST] [Xtrabackup] Starting to backup non-InnoDB tables and files** ... ... 2022-12-23T10:43:20.610477-00:00 0 [Note] [MYTEST] [Xtrabackup] Finished backing up non-InnoDB tables and files 2022-12-23T10:43:20.676140-00:00 0 [Note] [MYTEST] [Xtrabackup] Stopping log copying thread at LSN 64948804922 2022-12-23T10:43:20.728679-00:00 0 [Note] [MYTEST] [Xtrabackup] Executing UNLOCK INSTANCE 2022-12-23T10:43:20.729034-00:00 0 [Note] [MYTEST] [Xtrabackup] Executing UNLOCK TABLES 2022-12-23T10:43:20.729254-00:00 0 [Note] [MYTEST] [Xtrabackup] All tables unlocked **2022-12-23T10:43:20.729268-00:00 0 [Note] [MYTEST] [Xtrabackup] Starting slave SQL thread** ... ... 2022-12-23T10:43:22.099206-00:00 0 [Note] [MYTEST] [Xtrabackup] completed OK!
但是，在PXB 2.4版本中，sql thread只有在复制非InnoDB文件时才会停止，而在备份InnoDB文件时sql thread不会停止。因此，在整个20秒的备份过程中，sql thread只停止了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) ... ... 221223 11:20:21 [01] Copying ./db/t.ibd to /root/backups/db/t.ibd 221223 11:20:22 >> log scanned up to (3991557882) ... 221223 11:20:35 >> log scanned up to (3991557882) 221223 11:20:35 [01] ...done ... ... **221223 11:20:36 Slave open temp tables: 0 221223 11:20:36 Slave is safe to backup.** 221223 11:20:36 Executing FLUSH NO_WRITE_TO_BINLOG TABLES... 221223 11:20:36 Executing FLUSH TABLES WITH READ LOCK... **221223 11:20:36 Starting to backup non-InnoDB tables and files** ... ... 221223 11:20:40 Finished backing up non-InnoDB tables and files ... ... **221223 11:20:40 Executing UNLOCK TABLES 221223 11:20:40 All tables unlocked Starting slave SQL thread** ... ... 221223 11:20:40 completed OK!
PXB的safe-slave-backup选项旨在确保数据库副本的一致备份。在8.0.22之前的版本中，该选项将在备份InnoDB表之后和复制非InnoDB数据文件之前停止SQL thread。但是，如果在备份过程中对备份副本执行复制的DDL语句，则可能导致备份损坏。
为了解决这个问题，在8.0.22版本中更改了safe-slave-backup选项的行为。现在，当指定此选项时，将在备份进程开始时发出"STOP SLAVE SQL_THREAD"命令。这可以防止在备份期间执行任何复制的DDL语句，确保备份的一致性和可靠性。
这就是为什么在PXB包升级到8.0后，当备份进程启动时复制被停止，并且它停止了SQL Thread，即使所有的表都是InnoDB。
