mysql5.7 主从复制配置

5.7新增了GTID特性，导致主从复制配置有些变化。

my.cnf配置

# replication    for master and slave
server_id = 1
log_bin=mysql-bin
binlog_format=mixed

# enable GTID
gtid-mode = on
enforce-gtid-consistency = true
log_slave_updates=1

# replication    for slave
relay_log=new-relay-bin
relay_log_info_file=new-relay-info
read_only=1

在主从库中增加用户

create user repl@'%' identified by 'xxxx';
grant replication slave, replication client on *.* to repl@'%';
flush priveleges;

锁定主库，导出数据

mysqldump.exe -u root -h 127.0.0.1 -p  --set-gtid-purged=OFF --all-databases --triggers --routines --events > ..\xxx.dmp

以--skip-slave-start方式启动从库，把主库数据导入从库

mysql -u root -h slave -p  < ..\xxx.dmp

在从库设置master

change master to master_host='master',
master_user='repl',
master_password='xxxx',
MASTER_AUTO_POSITION = 1;

因为是从dump恢复的从库，所以启动复制前，
先要设置好从库的gtid_purged，这是为了告诉从库，以前的数据已经不需要同步了，
以避免启动复制时，从库仍然试图重新执行binlog，发生sql错误。

stop slave;
reset slave;

-- 为了设置gtid_purged，必须先清除gtid_executed。
reset master;
-- 这个gtid set是主库的gtid_executed。
set global gtid_purged='146ca884-97f0-11e5-aa16-50e54948b96b:1-472';

show global variables like '%GTID%';
show master status;

-- 好像不用再执行change master了。。。
change master to master_host='master',
master_user='repl',
master_password='xxx',
MASTER_AUTO_POSITION = 1;

SHOW SLAVE STATUS;
start slave;

当IO_thread和SQL_thread都是running的时候，就说明从库启动正常了。


如果从库上需要跳过个别gtid的时候，可以通过插入空事务的方法来做。如果需要跳过的事务太多，就得循环了。。。

set GTID_NEXT='7b970848-a23c-11e5-af70-005056892477:44288'
begin;
commit;
SET GTID_NEXT='AUTOMATIC';

最后，可以通过mysqlbinlog命令来查看bin-log，以便定位复制出错的sql所对应的gtid。