今天解决了两个蛮有意思的MySQL问题，简单分享出来。
首先是昨天说的级联复制的情况，因为架构做了调整，我们要删除其中的一个中继节点（新加坡节点），而直接使用北京节点去连接北美的节点。
更多的信息可以参考。
大体的架构方式如下：
如此一来，为了避免重建从库，而且没有GTID的情况下，我们可以统一规划一下偏移量，平滑迁移。
实现后的架构图如下：
看起来还是比较简单，但是偏移量真是一个比较琐碎细致的活儿。在此也感谢我的同事程振，我们一起讨论了实现的方式和细节。
大体来说，目前的北京节点的延迟较大，所以大体的思路就是停止新加坡节点的slave，（当然要保证slave的read_master_log_pos和Exec_Master_Log_Pos要追平）也可以直接停止io_thread(stop
slave io_thread),或者stop slave，让北京节点去追平GAP，然后直接平滑切换到北美的节点上。
北京节点（slave）和新加坡节点（master）的偏移量情况如下：
| 北京(slave) | 新加坡（master) |
| >show slave status\G | > show master status\G |
| Master_Log_File: binlog.000408 | File: binlog.000408 |
| Read_Master_Log_Pos: 129590180 | Position: 675358376 |
| Relay_Log_File: mysql-relay-bin.002263 | Binlog_Do_DB: |
| Relay_Log_Pos: 25551626 | Binlog_Ignore_DB: |
| Relay_Master_Log_File: binlog.000408 |
北京节点要去新加坡节点读取数据变化，得追平GAP，可以看出延迟已经很大了。
这里有一点很容易弄混淆，那就是新加坡节点（slave）的偏移量。
| 新加坡（slave) |
| > show slave status\G |
| Master_Log_File: binlog.000621 |
| Read_Master_Log_Pos: 287660027 |
| Relay_Log_File: mysql-relay-bin.002070 |
| Relay_Log_Pos: 287660170 |
| Relay_Master_Log_File: binlog.000621 |
北京节点要追平的偏移量是675358376而非287660027
过了些时间，总算是追平了，和预期的一样，是追平到了675358376。
数据如下：
| 北京(slave) | 新加坡（master) |
| >show slave status\G | > show master status\G |
| Master_Log_File: binlog.000408 | File: binlog.000408 |
| Read_Master_Log_Pos: 675358376 | Position: 675358376 |
| Relay_Log_File: mysql-relay-bin.002281 | Binlog_Do_DB: |
| Relay_Log_Pos: 414747263 | Binlog_Ignore_DB: |
| Relay_Master_Log_File: binlog.000408 |
这个时候问题就来了，北美的slave节点已经接受数据变化，偏移量肯定在增长，而这个时候一个重要的参考依旧就是新加坡slave节点的偏移量信息。从下面可以看出偏移量已经有了重大的差别，如果没有参考基础就无从开始设置。
| 新加坡（slave) | 北美从库（master) |
| > show slave status\G | > show master status\G |
| Master_Log_File: binlog.000621 | File: binlog.000621 |
| Read_Master_Log_Pos: 287660027 | Position: 344035385 |
| Relay_Log_File: mysql-relay-bin.002070 | Binlog_Do_DB: |
| Relay_Log_Pos: 287660170 | Binlog_Ignore_DB: |
| Relay_Master_Log_File: binlog.000621 |
接下来就是北京节点的重头戏了。开始使用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）的信息
| 北美slave节点 |
| > show master status\G |
| File: binlog.000621 |
| Position: 348627763 |
| Binlog_Do_DB: |
| Binlog_Ignore_DB: |
如此一来一个看似复杂的平滑迁移过程就完成了。昨天我蛮有深意的给出下面的一个级联复制图.
整个过程操作顺利完成之后，也让我对GTID这个很不错的特性更加渴望。手工来分析判断，真是很让人费神。