今天解决了两个蛮有意思的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这个很不错的特性更加渴望。手工来分析判断，真是很让人费神。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2131248/，如需转载，请注明出处，否则将追究法律责任。