Mysql基于GTIDs的复制

 

通过GTIDs【global transaction identifiers】,可以标识每一个事务，并且可以在其一旦提交追踪并应用于任何一个Slave上；这样 就不需要像BinaryLog复制依赖Log file 和位置。GTIDs完全基于事务，只要在Master提交的所有事务都在Slave上进行了Commit，那么就能保证Master和Slave之间的数据 一致性。你可以使用基于SBR或RBR的GTIDs来实现。推荐使用RBR【Row-based replication】.

　1 GTID介绍 

GTID的惟一性，不仅仅在Master上惟一，而是在整个集群中惟一。

GTID是由SourceId：transaction_Id 构成;SourceId用于标识源Server，即Master中的server_uuid[系统变量];transaction_id，是按照事务提交顺序而生成的序列数字。如第一个被提交的是1，则其GTID=XXXXXXXXXXXX:1.

GTID被存储于mysql.gtid_executed中，当gtid_mode=ON/ON_PERMISSIVE时。

GTID的生命周期

　　a.事务在Master上执行并提交

该事务用GTID标识，GTID由Master的UUID和一个非0的未被使用的事务序列号构成；该GTID被写入Master的BinLog中。

　　b.之后BinLog被传送到Slave上并存储在Slave的relay Log中【using established mechanisms for this process】.Slave读取到这个GTID，并为系统变量gtid_next赋值，这就告诉了Slave下一个要执行的事务【transaction】就是这个。

　　c.Slave确认该GTID是否已被使用【在其BinLog中】。若未用，则执行transaction并写入BinLog。需要注意的是：不仅仅是检查BinLog而且要确认没有其他session 已读取但未提交。换句话说，多个Clients不允许并行执行同一事务。

　　d.由于gtid_next不为空。Slave执行并写入BinLog。

2.构建GTID复制

　　a. 同步数据。即将Master与Slave的数据同步到一致，然后都开启SET @@global.read_only=ON;

　　b.停止Servers。可使用：mysqladmin -uroot -p shutdown

　　c.配置主从Server.确保双方都开启gtid_mode=ON，enforce_gtid_consistency=ON。

　　d.将Slave挂载到Master，告诉Slave将使用哪个Master作为复制的数据源。使用CHANGE MASTER TO语句，一定要启用MASTER_AUTO_POSITION=1,告诉Slave事务将由GTIDS标识。

　　e.启动Slave. START SLAVE.

　　f.关闭 read_only. SET @@global.read_only = OFF.

3.使用GTIDs限制

　　GTIDs是基于事务的【transactions】,所以对非事务的操作不会支持。

 　　CREATE TABLE ... SELECT statements .creat table ...select对基于语句的复制【SBR】是不安全的。

　　Temporary tables 。GTIDsg不支持CREATE  TEMPORARY TABLE AND DROP TEMPORARY TABLE .

　【Preventing execution of unsupported statements】阻止不支持语句的执行。为了防止GTID受到不支持语句的影响而失败，在参与复制的Server上都要使用enforce-gtid-consistency操作。

　　sql_slave_skip_counter用于跳过不支持的事务【这在GTIDs不支持】。

　　在gtid_mode=ON时不要进行mysql_upgrade,因为Mysql_update会用MyiSam引擎改变一些系统表。

　　也不要在gtid_mode=ON时进行mysqldump文件的导入。

也可参考这篇文章：

http://www.cnblogs.com/abobo/p/4242417.html 

 

转载于:https://www.cnblogs.com/itdev/p/6002713.html