mysql5.6复制新特性
一、名词解释：
1：
server_uuid：服务器身份ID。在第一次启动Mysql时，会自动生成一个server_uuid并写入到数据目录下auto.cnf文件里，官方不建议修改。
[root@mysql5_6 data]# pwd
/usr/local/mysql/data
[root@mysql5_6 data]# cat auto.cnf
[auto]
server-uuid=b0869d03-d4a9-11e1-a2ee-000c290a6b8f
2：
GTID：全局事务标识符。当开始这个功能时，每次事务提交都会在binlog里生成一个唯一的标示符，它由server_uuid和事务ID组成。首次提交的事务ID为1，第二次为2，第三次为3，依次类推。
查看主机master
show master status;
File Position Binlog_Do_DB Binlog_Ignore_DB Executed_Gtid_Set
binlog.000001 184761 D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-515
在binlog日志已经存在的D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-515值，如果有新进来的binlog日志中的gtid有和原来有重复，新进来的语句不执行。
二、新特性
1：支持多线程复制.事实上是针对每个database开启相应的独立线程。即每个库有一个单独的(sql thread)如果线上业务中，只有一个database或者绝大多数压力集中在个别database的话，多线程并发复制特性就没有意义了
2:启用GTID，无须再知道binlog和POS点，需要知道master的IP、端口，账号密码即可，因为同步复制是自动的，mysql通过内部机制GTID自动找点同步
在my.cnf使用
gtid_mode = ON
disable-gtid-unsafe-statements = 1
注意：这两个参数无法在线修改，只能在my.cnf修改。
三、问题：
GTID的局限性：
1.GTID同步复制是基于事务。所以Myisam表不支持，这可能导致多个GTID分配给同一个事务。
(5.6.9版本已经修改，支持修改Myisam表)
2.gtid_mode和disable-gtid-unsafe-statements必须同时使用，不同时使用，启动Mysql报错。
3.无法修改myisam表的数据，会提示Updates to non-transactional tables are forbidden when disable-gtid-unsafe-statements"
4.不支持CREATE TEMPORARY TABLE、DROP TEMPORARY TABLE 临时表操作
5.不支持CREATE TABLE ... SELECT语句。因为该语句会被拆分成create table 和insert两个事务，并且这个两个事务被分配了同一个GTID，这会导致insert被备库忽略掉
6.GTID是自动同步，复制的时候没办法使用全备份+偏移量日志这种办法还原，从机的第一次同步只能从主机的第一个事务点开始还原，所以主机的binlog日志必须保持完整，binlog日志不能丢失。（mysql手册说mysql5.6.9以后的版本可以使用全备份+偏移量日志这种办法还原，继续等待mysql5.6.9出来后再测试）。
以上的问题是RC版，相信到了正式版出来后，问题会有很大的改善。
（5.6.9的测试结果支持全备份+偏移量日志，执行mysqldump命令的时候，在dmp文件中会记录SET @@GLOBAL.GTID_PURGED='E6916BE4-4E3F-11E2-BBC7-000C29EE3F03:1-157'，但是设置GTID_PURGED ,必须保证gtid_executed没有设置过，执行reset master即可。）
四、测试步骤：
1：在my.cnf设置相应的参数
在master设置
log-bin = binlog
binlog_format = mixed
gtid_mode = ON
disable-gtid-unsafe-statements = 1
binlog_cache_size = 4M
max_binlog_size = 1G
max_binlog_cache_size = 2G
sync_binlog = 1
expire_logs_days = 1
在slave设置
#binlog
log-bin = binlog
binlog_format = mixed
gtid_mode = ON
disable-gtid-unsafe-statements = 1
binlog_cache_size = 4M
max_binlog_size = 1G
max_binlog_cache_size = 2G
sync_binlog = 1
expire_logs_days = 1
slave_parallel_workers #开启基于库的多线程复制。默认是0，不开启，最大并发数为1024个线程
#relay log
max_relay_log_size = 1G
relay_log_purge = 1
relay_log_recovery = 1 #当被设置成ENABLED，在CRASH后自动放弃所有未执行的relay-log,并且重新从MASTER获取日志；这样保证relay-log的完整
#master_verify_checksum = 1 #主从复制事件校验，master
#slave_sql_verify_checksum = 1 #主从复制事件校验
#slave_allow_batching = 1
log_slave_updates
2：在slave执行
CHANGE MASTER TO
MASTER_HOST = '127.0.0.1',
MASTER_PORT = 3306,
MASTER_USER = 'rel',
MASTER_PASSWORD = '123',
MASTER_AUTO_POSITION = 1,
MASTER_DELAY=30; #延时30秒执行
注意：此参数功能，relay日志会及时同步到slave机，只是日志的中的事件会根据事件的时间戳延时30秒执行。此功能在实际场景中运用也较多。
3：启动slave
start slave;
五、观察结果：
在slave执行 show slave status G;
观察Retrieved_Gtid_Set和Executed_Gtid_Set项。
Retrieved_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:2602
Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2602
Retrieved_Gtid_Set项：记录了relay日志从Master获取了binlog日志的位置
Executed_Gtid_Set项：记录本机执行的binlog日志位置（如果是从机，包括Master的binlog日志位置和slave本身的binlog日志位置）
预测：
Executed_Gtid_Set：从本机的binlog中获取，如果binlong日志中记录了主机的Gtid，那么即使我们在从机重新同步，从机的IO进程依然不会从主机获取这些数据，
测试如下：
第一步：在slave执行:show slave stauts G;
Retrieved_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2601
Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2601
显示的Slave从Master同步，relay获取了执行了D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2601,然后执行，在binglog日志中记录了D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2601。
第二步：在slave执行
1:stop slave;
2:reset slave;
3:删除所有relay文件;
4:CHANGE MASTER TO
MASTER_HOST = '127.0.0.1',
MASTER_PORT = 3306,
MASTER_USER = 'rel',
MASTER_PASSWORD = '123',
MASTER_AUTO_POSITION = 1,
MASTER_DELAY=30;
5:start slave;
执行show slave status G;
Retrieved_Gtid_Set:
Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2601
Retrieved_Gtid_Set项没有值，说明重新同步的时候，relay没有从master取数据。
第三步：在master执行一条sql语句
在slave执行show slave status G;
Retrieved_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:2602
Executed_Gtid_Set: D68DBC47-3AAE-11E2-BC2F-842B2B699BDA:1-2602
观测结果符合预期。
