一、名词解释: 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 binlog.000001
184761 在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版,相信到了正式版出来后,问题会有很大的改善。 四、测试步骤: 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 观测结果符合预期。 |
|