【云中沙箱】云上RDS数据的本地同步

RDS主从架构

    应用连接RDS，流量通过SLB指向主从节点的master，所以如果我们连接RDS的账户具有REPLICATION SLAVE, REPLICATION CLIENT的权限，则就可以把主库master的产生的binlog同步到本地数据库中去，实现数据同步。

    但是这种根据binlog文件和位点来同步RDS的数据到本地的方式非常容易导致同步中断，因为当RDS发生了主备切换（主备切换，重启，跨机迁移），本地数据库所指向RDS的binlog 位点则会发生变化（RDS主库与备库的binlog位点是不一致的），这样就会导致本地数据库与RDS的数据复制同步中断。

    在RDS 5.6的版本中主备同步使用新复制方式GTID，RDS的主备具有相同的GTID，那么如果主备发生切换，重启或者迁移，主备的GTID是不会发生变化，那么ECS和RDS的同步链路则不会发生中断，所以如果要将RDS的数据同步到本地，则需要将RDS升级到5.6的版本。

GTID简介

    Global Transaction ID,全局事务ID，在整个事务架构中每一个事务ID号是全局唯一的，不止是在一个节点上而是整个主从复制架构中每任何两个事务的ID号都不会相同。

• 全局事务ID是怎么生成的？
  

简单来讲是由mysql服务器自动管理的，在mysql5.6以后每一个mysql服务器都有一个全局唯一的ID号叫做uuid，通用唯一识别码 (Universally Unique Identifier)，而GTID就是由当前节点的UUID（一个128位的随机数）和为当前节点生成的随机数（TID）组成的，因此只要UUID不同再在此基础上保证事务ID不同就保证全局不一样了。

• 全局事务ID有何用处？
  

简单来讲GTID能够保证让一个从服务器到其他的从服务器那里实现数据复制而且能够实现数据整合的。GTID在分布式架构中可以保证数据的一致性。从而也实现了mysql的高可用性。

    默认情况下将一个事务记录进二进制文件时将首先记录它的GTID而且GTID和事务相关信息一并要发送给从服务器由从服务器在在本地应用认证但是绝对不会改变原来的事务ID号。因此在GTID的架构上就算有了N层架构，复制是N级架构、事务ID依然不会改变；有效的保证了数据的完整和安全性。