mysql主从复制的原理

 

数据库主从复制

 

 

MySQL传统复制：

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

三个线程：主库BinlogDump，从库IO和SQL线程

过程：1、Master所有数据库变更写进Binary log 

            2、主库dump线程把Binary log内容发送到从库slave上(slave被动接受数据，不是主动去获取)。 

            3、从库Slave IO线程读取Master上Binary log日志信息，把接受到的Binary log日志写到本地中继日志 Relay log

            4、Slave SQL线程读取Ralay log日志内容写入本地数据库实例

 

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) 

transaction_id是顺序化的序列号(sequence number)，在每台MySQL服务器上都是从1开始自增长的序列，是事务的唯一标识。例如：3E11FA47-71CA-11E1-9E33-C80AA9429562:23 

三、GTID的工作原理： 

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2、主库dump线程把Bin log内容发送到从库slave上

3、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

4、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。如果有记录，说明该GTID的事务已经执行，slave 会忽略。如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

5、在解析过程中会判断是否有主键，如果有就用二级索引，如果没有就用全部扫描。  

四、GTID的限制 

1、在一个事务里面混合使用引擎如Innodb(支持事务)、MyISAM(不支持事务)， 造成多个GTIDs和同一个事务相关联出错（不能混合使用mysql引擎） 

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参数)。

 

问题：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。所以引入半同步复制

 

半同步复制：

semi-sync replication，半同步

解决复制延迟问题，延迟会导致数据不同步

AFTER_COMMIT（5.6默认值）master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。

 

AFTER_SYNC（5.7默认值，但5.6中无此模式）master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。

因此5.7引入了after_sync模式，带来的主要收益是解决after_commit导致的master crash主从间数据不一致问题，因此在引入after_sync模式后，所有提交的数据已经都被复制，故障切换时数据一致性将得到提升。
 

mysql 全同步组复制（MGR）

去中心化分布式全同步（官方文档）

mysql group replication