mysql 级联同步不成功_MySQL级联复制中的数据同步第二篇）

在线QQ客服：1922638

专业的SQL Server、MySQL数据库同步软件

我今天解决了两个非常有趣的MySQL问题，简要分享一下。

首先是昨天提到的级联复制情况。由于架构已调整，我们将删除其中一个中继节点(新加坡节点)，并直接使用北京节点连接到北美节点。

可以参考更多信息。

MySQL级联复制中的数据同步(R11注释第20天)

总体结构如下:

这样，为了避免重建从属库，并且在没有GTID的情况下，我们可以统一计划偏移量并平滑迁移。

实施后的架构图如下:

看起来相对简单，但是偏移量确实是一件微不足道的工作。我还要感谢我的同事程镇，一起讨论了实现方法和细节。

通常，当前的北京节点有较大的延迟，因此一般的想法是停止新加坡节点的从服务器(当然，要确保从服务器的read_master_log_pos和Exec_Master_Log_Pos必须绑定)，也可以直接停止io_thread(停

从属io_thread)，或停止从属，让北京节点与GAP绑定，然后直接平稳地切换至北美节点。

北京节点(从节点)和新加坡节点(主节点)的偏移量如下:

北京(从属)

新加坡(主语言)

\ gt;显示奴隶？状态\\\\ G

\ gt;表演大师？状态\\\\ G

Master_Log_File :？ binlog.000408

文件:binlog.000408

Read_Master_Log_Pos : 129590180

位置 :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。可以看出，延迟已经很大。

这里容易混淆的一件事是新加坡节点(从站)的偏移量。

新加坡(从属)

\ gt; 显示？奴隶状态\\\\ 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

Beijing节点到水平的偏移是675358376而不是287660027

一段时间之后，它终于如预期的那样被捆绑到675358376上。

数据如下:

北京(从属)

新加坡(主语言)

\ gt;显示从属状态\\\\ G

\ gt;表演大师？状态\\\\ G

Master_Log_File :？ binlog.000408

文件:binlog.000408

Read_Master_Log_Pos :？ 675358376

位置:675358376

Relay_Log_File : mysql-relay-bin.002281

Binlog_Do_DB :？

Relay_Log_Pos : 414747263

Binlog_Ignore_DB :？

Relay_Master_Log_File :？ binlog.000408

问题此时出现 ，北美的从属节点已接受数据更改，偏移量肯定是增长的同时，此时重要的参考仍然是新加坡从节点的偏移量信息。从下面可以看出，偏移量存在显着差异。如果没有参考依据，则无法开始设置。

新加坡(从属)

北美奴隶(主人)

\ gt;显示？奴隶状态\\\\ G

\ gt;表演大师？状态\\\\ G

Master_Log_File :？ binlog.000621

文件:binlog.000621

Read_Master_Log_Pos :？ 287660027

位置:344035385

Relay_Log_File : mysql-relay-bin.002070

Binlog_Do_DB :？

Relay_Log_Pos : 287660170

Binlog_Ignore_DB :？

Relay_Master_Log_File :？ binlog.000621

接下来是Beijing节点的亮点。开始使用Change Master修改

停止从属；

更改主？ MASTER_HOST =” xxxx”，

？ MASTER_USER =” repl_new” ，？

？ MASTER_PASSWORD =” xxxx” ，？

？ MASTER_PORT = 3306 ，？

？ master_log_file =” binlog.000621″，

？ master_log_pos = 287660027;

启动奴隶;

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

启动从属服务器后，您可以看到偏移量开始显着增加。

Read_Master_Log_Pos:288885733

快速将北美偏移量从母版中偏移

查看北美主信息

北美从属节点

\ gt;显示主状态\\\\ G

文件:binlog.000621

位置:348627763

Binlog_Do_DB:

Binlog_Ignore_DB:

这样，完成了看似复杂的平滑迁移过程。昨天，我给出了下面的级联的非常深刻的副本。

在整个过程的操作成功完成之后，我更加渴望GTID的出色功能。手动分析和判断确实令人困惑。

从” ITPUB博客”中，链接:http://blog.itpub.net/23718752/viewspace-2131248/，如果您需要转载，请注明出处，否则，您将承担责任。