首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >MySQL级联复制中的数据同步(r11笔记第20天)

MySQL级联复制中的数据同步(r11笔记第20天)

作者头像
jeanron100
发布2018-03-21 11:24:04
7890
发布2018-03-21 11:24:04
举报

最近开发的同事反馈了一个问题,说有一台北京节点的MySQL数据库数据延迟太大,想让我们帮忙看看怎么解决。

这个问题一下子让我想起了之前“水深火热”的日子,因为这是一套MySQL级联复制的环境。这么做的目的也是为了能够方便数据查询和统计任务,看起来虽好,但是老是有一些不可控因素。

北美使用AWS在北美,都是实时的业务数据,考虑了灾备和读写分离使用了一主一从的架构,新加坡节点2是一个中继节点,也使用了AWS,可以看到新加坡节点是北美节点的从库,但是北京的主库。 北京节点是一个IDC设备。就这样一个级联复制的环境就跑起来了。

由于新加坡的节点网络延迟太大,而且很不稳定,之前的一部分业务最后就索性迁移到中国香港的云服务上了。剩下的这部分业务稳定运行了一段时间,但是最近经常发现数据延迟很大,这个问题又提上了日程。

我们经过讨论,开发同事建议,索性直接连北美节点吧,我这边简单做了测试,网速其实还是要好一点。所以改进后的架构如下:

但是这里就面临一个问题,怎么去无缝的把节点的数据顺利切换过去。发现这个问题变得有些纠结了,因为新加坡的节点目前和北京节点是有延迟,直接切换过去肯定不行,而且偏移量在不同的节点都有不小的差别。怎么调和呢。

每当到这个时候我就想起了MySQL非常经典的架构图。

碰到实际的问题再来看的时候发现有很多地方就需要加深理解了。

单纯使用偏移量,我和同事在纸上分析和讨论,感谢总是有一些不确定的地方。这让我就非常怀念起了5.6推出的GTID,这个特性在这个问题前真是太有用了。GTID的统一格式是由source_id加transaction_id构成。这个source_id就是UUID,是一个唯一性标示,在读写分离,一主多从的环境,还有当下的级联复制的环境中尤其有用,因为是全局事务的概念,所以不会出现重复的情况,这一点和Oracle里物理一致性的SCN很有相似的味道。

在这个问题中,如果能够启用GTID,那么北美节点的UUID在北京节点还是一个唯一性的标示,能够正确的标识和应用事务信息。

但是当前的环境是5.5版本,很遗憾使用不了,那么一种折中的办法就是停止新加坡的节点,然后让北京节点去追平数据,然后以这个为基准,让北京节点继续从北美的slave节点继续抓取增量的数据变化。

整个过程就会使用change master的方式来完成了。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2016-12-21,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 SQL Server
腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档