MySQL传统复制与GTID复制的原理阐述

MySQL复制
MySQL异步复制架构中传统复制的原理阐述
MySQL异步复制架构中GTID复制的原理阐述
一、GTID的概述：
二、GTID的组成部分：
三、GTID如何产生
四、GTID相关的变量
五、GTID比传统复制的优势与限制：
优势
GTID的限制
六、GTID的工作原理：

MySQL复制

MySQL异步复制架构中传统复制的原理阐述

MySQL传统复制是基于MySQL二进制文件（mysql-bin.000001），加上对应日志文件中每个事件的偏移量位置点（postion）。

• 三个线程来实现：主库Binlog Dump，从库IO和SQL线程
• Master所有数据库变更写进Binary log, 主库线程 binlog dump把Binary log内容发送到从库slave上（slave被动接受数据，不是主动去获取）。
• Slave IO线程读取Master上Binary log日志信息，把接受到的Binary log日志写到本地中继日志 Relay log
• Slave SQL线程读取Ralay log日志内容写入本地数据库实例

MySQL异步复制架构中GTID复制的原理阐述

一、GTID的概述：

• 1、全局事物标识：global transaction identifieds。
• 2、GTID事物是全局唯一性的，且一个事务对应一个GTID。
• 3、一个GTID在一个服务器上只执行一次，避免重复执行导致数据混乱或者主从不一致。
• 4、GTID用来代替classic的复制方法，不在使用binlog+pos开启复制。而是使用master_auto_postion=1的方式自动匹配GTID断点进行复制。
• 5、MySQL-5.6.5开始支持的，MySQL-5.6.10后开始完善。
• 6、在传统的slave端，binlog是不用开启的，但是在GTID中，slave端的binlog是必须开启的，目的是记录执行过的GTID（强制）；但是从5.7.5版本开始无需在GTID模式下启用参数log_slave_updates

二、GTID的组成部分：

GTID = source_id:transaction_id 
source_id正常即是server_uuid，在第一次启动时生成（函数generate_server_uuid），并持久化到DATADIR/auto.cnf文件里。 
transaction_id是顺序化的序列号（sequence number），在每台MySQL服务器上都是从1开始自增长的序列，是事务的唯一标识。例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23 
GTID 的集合（GTIDs）可以用source_id+transaction_id范围表示，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-18 
复杂一点的：如果这组 GTIDs 来自不同的 source_id，各组 source_id 之间用逗号分隔；如果事务序号有多个范围区间，各组范围之间用冒号分隔，例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5:11-18,2C256447-3F0D-431B-9A12-575BB20C1507:1-27

三、GTID如何产生

GTID的生成受gtid_next控制。 
在Master上，gtid_next是默认的AUTOMATIC,即GTID在每次事务提交时自动生成。它从当前已执行的GTID集合（即gtid_executed）中，找一个大于0的未使用的最小值作为下个事务GTID。同时将GTID写入到binlog（set gtid_next记录），在实际的更新事务记录之前。 
在Slave上，从binlog先读取到主库的GTID(即set gtid_next记录)，而后执行的事务采用该GTID。

四、GTID相关的变量

• GTID_EXECUTED 
  表示已经在该实例上执行过的事务； 执行RESET MASTER 会将该变量置空; 我们还可以通过设置GTID_NEXT在执行一个空事务，来影响GTID_EXECUTED
• GTID_PURGED 
  已经被删除了binlog的事务，它是GTID_EXECUTED的子集，只有在GTID_EXECUTED为空时才能设置该变量，修改GTID_PURGED会同时更新GTID_EXECUTED和GTID_PURGED的值。
• GTID_OWNED 
  表示正在执行的事务的gtid以及对应的线程ID。
• GTID_NEXT 
  SESSION级别变量，表示下一个将被使用的GTID。

五、GTID比传统复制的优势与限制：

优势

• 1、更简单的实现failover，不用以前那样在需要找log_file和log_Pos。
• 2、更简单的搭建主从复制。
• 3、复制集群有一个统一的方式识别复制位置，给集群管理带来了便利。
• 4、正常情况下，GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

GTID的限制

• 1、在一个事务里面混合使用引擎如Innodb(支持事务)、MyISAM（不支持事务）， 造成多个GTIDs和同一个事务相关联出错
• 2、CREATE TABLE…..SELECT 不能使用，该语句产生的两个event在某一情况 会使用同一个GTID（同一个GTID在slave只能被使用一次）
  • 1th event:创建表语句create table
  • 2th event:插入数据语句insert
• 3、CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE 不能在事务内使用 （启用了--enforce-gtid-consistency参数)。

六、GTID的工作原理：

• 1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。
• 2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。
• 3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。
• 4、如果有记录，说明该GTID的事务已经执行，slave会忽略。
• 5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。
• 6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。