MySQL 基于GTID的复制 --5.6开始

GTID：全局事务ID，其保证为每一个在主上提交的事务在复制集群中可以生成一个唯一的ID

GTID=source_id:transaction_id

原理：从库告诉主库已执行的GTID值，然后主库把没有执行的GTID告诉唯一的一个从库，从库在执行这些GTID值

优点：可以很方便的进行故障转移（启动了log_slave_update从库保存了主库的二进制日志，从而可以很方便的进行切换）

从库不会丢失主库上的任何修改（主库二进制日志没删除的情况下）

缺点：故障处理比较复杂（比如从库的主键冲突，必须在从库上插入空事务的方式才能跳过这种错误） ，对执行的SQL有一定的限制。



配置步骤：

1. 创建复制账号（同日志点复制），一定不要在其他从库上手动建立相同的账号。

create user ‘reple’@’172.20.249.%’ identified by ‘123456’;

grant replication slave, replication client on . to ‘repl’@’172.20.249.%’;

2. 配置主从库

主库（必须）：

log-bin=/usr/local/mysql/log/mysql-bin

server_id = 1

gtid_mode = on ##启动gtid模式复制

enforce-gtid-consistency

注意此参数主要：SQL一些语句就不能使用了：create table ..select；在事务中使用create temporary 建立临时表使用关联更新事务表和非事务表。

log-slave-updates=on（5.7已经去掉了）

从库（必须）：

server_id=2

relay_log=/usr/local/mysql/log/relay_log

gtid_mode=on

enforce-gtid-consistency

从库（建议）：

log-slave-update=on

read_only=on

master_info_repository=TABLE

relay_log_info_repository=TABLE

两个标红的参数说明：指定了从服务器连接柱服务器的信息及中继日志的存储方式，默认是记录在文件中的，此配置是要将其存储在数据库表中，这两个表使用innodb存储引擎，所以在数据库崩溃时可以只用innodb引擎特点对这两个表进行恢复。

3. 初始化从库（通日志点复制的初始化）

mysqldump –master-data = 2 –single-transaction –triggers –routines – all-databases >> all.sql ###只能冷备，如果使用了非innodb还用使用 lock-tables参数对表加锁 maste-data：记录二进制日志偏移量等信息

xtrabackup –slave-info ##可在线热备，同样对非innodb要加锁。

4. 配置复制

change master to master_host=’ip’,

master_user=’repl’,

master_password=’123456’,

master_auto_position=1; ####告诉从服务器使用gtid复制方式。

**遇到的问题是：重启mysql服务的时候报error.log文件找不到，必须要给mysql用户赋权。

这是因为我把error.log的路径在my.cnf中修改为/usr/local/mysql/logs/error.log,不过我创建了这个目录并且将这个目录改为mysql用户但是还是报错，最后没办法手工touch了error.log就可以了，这里不知道mysql为什么不能自动创建error.log。是我不知道其中原理还是哪里有问题，请高手留言指正。**