信息化建设的不断推进，让各企业机关的活动越来越多依赖于关键业务信息系统，并在整个机构的运营和发展中起着至关重要的作用。一旦发生宕机故障或应用停机，将给机构带来巨大的经济损失。

对那些需要保障信息安全和提供不间断的信息服务的机构来说，业务系统的容错性和不间断性显得尤为重要。如何保障各种关键应用持续运营，达到永续经营的良性循环，已成为当今企事业单位和IT领域急需解决的关键问题。

本文详细记录了华为云技术专家在 MySQL 实践中遇到的数据高可用备份问题，看似简单的“主备切换”和“备机备份”背后，有哪些隐患？

生产环境数据库的主备高可用架构

生产环境的数据库多数是带备份的，至少是一主一备，目的是当主机出现宕机但是又不能很快恢复时，把业务切换到备机上，快速恢复业务，这是常说的高可用。

但是备机也可能会故障，有时候还需要基于当前的数据做一份新的数据库出来，此时怎么做？是不是还得一个冷备份呢？所以基本的数据库架构很多是这样的：

数据库基本架构

最初我们做RDS for MySQL 备份也是基于这样的模型，但不同的是，我们引入了对象存储系统（OBject Storage）。因为实例较多，发生切换时不能靠人工处理，因此引入了高可用系统（High Available）。针对备份，我们也抽象出一个独立系统，用来处理复杂的备份和还原过程，称之为备份恢复系统（Backup and Restore）。最终的框架图如下：

高可用备份框架图

优化

触发备份时，可能会导致主机资源被占用，例如压缩时占用 CPU 资源，上传会占用IO，所以业界RDS for MySQL都会在备机上做备份，但是仅仅是换个主机这么简单吗？下面重点说说我们在此过程中踩过的一个坑吧！

敲黑板划重点

基于备机备份第1个带来的问题我们要正视，那就是可能的延迟，整体上延迟时间为：

OBS上的数据时间晚于备机的数据时间晚于主机的数据时间

即：OBS上的数据可能晚于备机的数据，而后者又晚于主机的数据。
这个延迟会带来其它问题，我们在做高可用和可靠性混合测试时碰到过。

假设A的uuid为A，B的uuid为B，具体操作步骤和数据如下：

看下我们测试的结果

图1 新备机

图2 新主机

大家注意，如果这部分数据没有同步过来其实是一个非常危险的动作。因为此时主备复制关系都是正常的，所以很容易被忽略。而且由于这样的延迟关系，该场景下的问题的发生是一个大概率事件。

很显现，MySQL并没有按照大家想象中那样去做。很多 DBA 都做过这样的实验，把已经从主机同步过来的数据在备机删除掉，然后设置已经执行的 GTID 为之前的值，数据会重新从主机同步过来，而且只认 GTID 不认内容，可是为什么现在就不行了呢？

在此过程中，我们进行了各种检查。先是验证是否备份出现问题，然后又验证是否还原步骤出现问题，然而都不是…… 总不能是数据库 A 通过识别 GTID 发现，有部分数据是以自己的 uuid 开头，所以才没有同步吧？

所以我们尝试修改了A主机的server-uuid为C，但并没有任何结果。这样的结果，一度让我的思路陷入僵局，感觉大脑中的主备复制知识要被刷新了。打开解析后的binlog，看到 binlog 中使用的是 server ID，我想mysql是不是通过server ID来识别呢？抱着病重乱投医的心态，我尝试修改了 server ID，结果却意外地成功了！于是我们又顺着这条线索，查看 MySQL 官方文档，发现一个不常用参数。

–replicate-same-server-id

本文转载自华为云产品与解决方案公众号。

原文链接：https://mp.weixin.qq.com/s/MStqLOeYWFHdgVWY--fbwg

创作场景

MySQL“主备切换”碰到“备机备份”，竟有这种隐患？