信息化建设的不断推进,让各企业机关的活动越来越多依赖于关键业务信息系统,并在整个机构的运营和发展中起着至关重要的作用。一旦发生宕机故障或应用停机,将给机构带来巨大的经济损失。
对那些需要保障信息安全和提供不间断的信息服务的机构来说,业务系统的容错性和不间断性显得尤为重要。如何保障各种关键应用持续运营,达到永续经营的良性循环,已成为当今企事业单位和 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
评论