MySQL级联复制中的数据同步（第二篇）(r11笔记第21天)

今天还是说说级联复制的问题情况，因为架构做了调整，我们要删除其中的一个中继节点（新加坡节点），而直接使用北京节点去连接北美的节点。

更多的信息可以参考。

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

大体的架构方式如下：

如此一来，为了避免重建从库，而且没有GTID的情况下，我们可以统一规划一下偏移量，平滑迁移。

实现后的架构图如下：

看起来还是比较简单，但是偏移量真是一个比较琐碎细致的活儿。在此也感谢我的同事程振，我们一起讨论了实现的方式和细节。

大体来说，目前的北京节点的延迟较大，所以大体的思路就是停止新加坡节点的slave，（当然要保证slave的read_master_log_pos和Exec_Master_Log_Pos要追平）也可以直接停止io_thread(stop slave io_thread),或者stop slave，让北京节点去追平GAP，然后直接平滑切换到北美的节点上。

北京节点（slave）和新加坡节点（master）的偏移量情况如下：

北京节点要去新加坡节点读取数据变化，得追平GAP，可以看出延迟已经很大了。

这里有一点很容易弄混淆，那就是新加坡节点（slave）的偏移量。

北京节点要追平的偏移量是675358376而非287660027

过了些时间，总算是追平了，和预期的一样，是追平到了675358376。

数据如下：

这个时候问题就来了，北美的slave节点已经接受数据变化，偏移量肯定在增长，而这个时候一个重要的参考依旧就是新加坡slave节点的偏移量信息。从下面可以看出偏移量已经有了重大的差别，如果没有参考基础就无从开始设置。

接下来就是北京节点的重头戏了。开始使用change master来修改

stop slave; CHANGE MASTER TO MASTER_HOST='xxxx', MASTER_USER='repl_new', MASTER_PASSWORD='xxxx', MASTER_PORT=3306, master_log_file='binlog.000621', master_log_pos=287660027； start slave;

如上的两个重要参数就取自新加坡的从节点信息。

然后start slave之后，就可以看到偏移量开始大幅度提升。

Read_Master_Log_Pos: 288885733

很快就追平了北美从库（master）的偏移量

查看北美从库（master）的信息

如此一来一个看似复杂的平滑迁移过程就完成了。昨天我蛮有深意的给出下面的一个级联复制图.

整个过程操作顺利完成之后，也让我对GTID这个很不错的特性更加渴望。手工来分析判断，真是很让人费神。