mysql gtid原理_gtid主从复制原理和报错解决

IP

版本

节点

10.10.10.100

centos7.2 + mysql5.6

master

10.10.10.200

centos7.2 + mysql5.6

slave

二、GTID的组成部分：

前面是server_uuid：后面是一个序列号

UUID：每个mysql实例的唯一ID，由于会传递到slave，所以也可以理解为源ID。

Sequence number：在每台MySQL服务器上都是从1开始自增长的序列，一个数值对应一个事务。

三、GTID比传统复制的优势：

1、更简单的实现failover，不用以前那样在需要找log_file和log_Pos。

2、更简单的搭建主从复制。

3、比传统复制更加安全。

4、GTID是连续没有空洞的，因此主从库出现数据冲突时，可以用添加空事物的方式进行跳过。

5、多线程复制

四、GTID的工作原理：

1、master更新数据时，会在事务前产生GTID，一同记录到binlog日志中。

2、slave端的i/o 线程将变更的binlog，写入到本地的relay log中。

3、sql线程从relay log中获取GTID，然后对比slave端的binlog是否有记录。

4、如果有记录，说明该GTID的事务已经执行，slave会忽略。

5、如果没有记录，slave就会从relay log中执行该GTID的事务，并记录到binlog。

6、在解析过程中会判断是否有主键，如果没有就用二级索引，如果没有就用全部扫描。

五、相关变量

GTID_PURGED ：已经执行完被删除的binlog的事务，它是GTID_EXECUTED的子集，从MySQL5.6.9开始，该变量无法被设置。

GTID_OWNED : 表示正在执行的事务的gtid以及对应的线程ID。

GTID_EXECUTED： 表示已经在该实例上执行过的事务； 执行RESET MASTER 会将该变量置空; 我们还可以通过设置GTID_NEXT执行一个空事务，来影响GTID_EXECUTED

GTID_NEXT： 是SESSION级别变量，表示下一个将被使用的GTID

在内存中也维护了与GTID_PURGED， GTID_OWNED, GTID_EXECUTED相对应的全局对象gtid_state。

gtid_state中维护了三个集合，其中logged_gtids对应GTID_EXECUTED， lost_gtids对应GTID_PURGED，owned_gtids对应GTID_OWNED

六、要点

slave在接受master的binlog时，会校验master的GTID是否已经执行过(一个服务器只能执行一次)。为了保证主从数据的一致性，多线程只能同时执行一个GTID。

七，GTID主从复制搭建：

1，两台机器各自安装好mysql

2，两台服务器各自安装好mysql，修改root密码，启动mysql数据库

在主库上导出数据：

mysql> flush tables with read lock;

# mysqldump -uroot -p --default-character-set=utf8 --single-transaction --flush-logs --set-gtid-purged=OFF wbdb > /tmp/wbdb.sql

mysql> unlock tables;

# mysql -uroot -p --default-character-set=utf8 < database.sql

3,配置my.cnf参数，加入以下项目：

主：

server-id = 1

log-bin=mysql-bin

binlog_format=row

#当设置隔离级别为READ-COMMITED必须设置二进制日志格式为ROW

#添加以下这些选项

log-slave-updates=true #slave更新是否记入日志

lower_case_table_names =1 #大小写不敏感

gtid-mode=on # 启用gtid类型，