在官方文档中提到，最保险可靠的复制方式，是基于row的复制，所以宁可牺牲一些性能也要保证数据的安全。

现实环境中，master主数据库MySQL 5.6.10(msi安装方式)安装在Windows 2008 Server x64上，slave从服务器是一台老旧的DELL服务器，运行CentOS 6.4 x64系统，源码编译安装MySQL 5.6.10的Linux版本，安装过程可以参考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/09/2951544.html

不同平台下，MySQL是有一些差异的，要小心处理。

第一个问题是，Windows平台下，文件名大小写不敏感，造成对应的MySQL的数据表名称默认都采用小写字母方式，同时大小不写敏感，参考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/18/2966106.html 为了能将数据同步复制到Linux平台的MySQL，我们需要设置Linux平台下MySQL的数据表名称设置：(修改my.cnf文件)

	
	

		[mysqld]  
	

	

		lower_case_table_names=1 
	

第二个问题是，自增字段0值的问题。因为现有数据库是MSSQL，业务逻辑需要某些表的自增字段从0开始。参考我以前的博文：http://www.cnblogs.com/jlzhou/archive/2013/03/18/2965384.html 为了在Windows平台和Linux平台的MySQL之间复制数据，增加全局变量设置，在my.ini和my.cnf中分别添加NO_AUTO_VALUE_ON_ZERO设置到sql-mode行：

	
	

		//my.ini 该文件默认在Windows7或Windows2008操作系统中位于 C:\ProgramData\MySQL\MySQL Server 5.6 目录下（采用MSI安装方式），如果你自定义了数据目录，则该配置文件在数据目录下。  
	

	

		# Set the SQL mode to strict  
	

	

		sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALUE_ON_ZERO"  
	

现在开始配置GTID复制，先配置master端的my.ini文件，加入下述配置，然后重启master的MySQL服务：

	
	

		binlog-format=ROW  
	

	

		log-bin=master-bin.log  
	

	

		log-bin-index=master-bin.index 
	

	

		log-slave-updates=true 
	

	

		gtid-mode=on 
	

	

		enforce-gtid-consistency=true 
	

	

		master-info-repository=TABLE 
	

	

		relay-log-info-repository=TABLE 
	

	

		sync-master-info=1  
	

	

		slave-parallel-workers=2  
	

	

		binlog-checksum=CRC32  
	

	

		master-verify-checksum=1  
	

	

		slave-sql-verify-checksum=1  
	

	

		binlog-rows-query-log-events=1  
	

	

		server-id=1  
	

	

		sync_binlog=1 
	

再修改slave端的my.cnf文件，加入下述配置，然后重启slave的MySQL服务：

	
	

		binlog-format=ROW  
	

	

		log-bin=slave-bin.log  
	

	

		log-bin-index=slave-bin.index 
	

	

		log-slave-updates=true 
	

	

		gtid-mode=on 
	

	

		enforce-gtid-consistency=true 
	

	

		master-info-repository=TABLE 
	

	

		relay-log-info-repository=TABLE 
	

	

		sync-master-info=1  
	

	

		slave-parallel-workers=2  
	

	

		binlog-checksum=CRC32  
	

	

		master-verify-checksum=1  
	

	

		slave-sql-verify-checksum=1  
	

	

		binlog-rows-query-log-events=1  
	

	

		server-id=2  
	

	

		sync_binlog=1 
	

其实，并不需要在slave端启用binlog，但是为了在master故障时，方便的转换slave到master，并且方便建立slave的slave，所以采用和主服务器类似的配置。
 
复制设置会将用于复制的用户和密码以明文形式保存在master.info文件中，最好为复制建立专用的用户，授予 REPLICATION SLAVE 权限。
 
在master端执行：
 
GRANT REPLICATION SLAVE ON *.* TO 'repluser'@'192.168.1.101' IDENTIFIED BY '12345678'; 
最后，在slave执行指向master的命令，并开启slave复制。
 
CHANGE MASTER TO MASTER_HOST='192.168.1.100', MASTER_PORT=3306, MASTER_USER='repluser',MASTER_PASSWORD='12345678', master_auto_position=1; START slave; 
这时就可以测试在master上建立数据库，建表，然后监控slave的复制状态了。
 
本文中没有涉及到已有数据库在master上的情况，请参考这篇博文：http://www.zhaokunyao.com/archives/4131

后记：
 
附上备份和恢复脚本：命令行执行

	
	

		Backup from remote server scripts:  
	

	

		 
	

	

		// for test database:  
	

	

		"C:\MySQL\MySQL Server 5.6\bin\mysqldump.exe" --user=root --max_allowed_packet=1G --host=10.192.8.105 --port=3306 --default-character-set=utf8 --set-gtid-purged=OFF --password --databases test > "C:\\Backup\\test.dump.sql"  
	

	

		 
	

	

		Restore to local dev machine scripts:  
	

	

		 
	

	

		// for test database:  
	

	

		"C:\MySQL\MySQL Server 5.6\bin\mysql.exe" --host=localhost --user=root --port=3306 --password --default-character-set=utf8 --comments < "C:\\Backup\\test.dump.sql" 
	

注意，上述脚本中，备份的部分要加入--set-gtid-purged=OFF参数，防止在备份出的sql脚本中生成 SET @@global.gtid_purged 语句：
 
Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF.

官方文档关于set-gtid-purged是这样写的：

This option enables control over global transaction ID (GTID) information written to the dump file, by indicating whether to add a SET @@global.gtid_purged statement to the output. 

原文链接：http://www.cnblogs.com/jlzhou/archive/2013/03/22/2975913.html