Mysql基于gtid的主从复制以及半同步复制

基于gtid的主从复制

基于gtid主从复制简介

• mysql数据库从5.6.5开始新增一种基于gtid的复制方式。gtid（global transaction id）是对于一个已提交事务的编号。gtid实际上是由uuid+tid组成的，其中uuid是mysql实例的一个标识，tid则代表了该实例上交的事务数量，并且随着事务的提交单调递增。
• 主从复制默认是通过pos（position）复制，就是说在日志文档里，将用户进行的每一项操作都进行编号（pos），每一个事件都有一个起始编号，一个终止编号，在配置主从复制节点时，要求其从master的pos开始同步数据库里面的数据，这也称作传统复制技术。
• gtid就是类似pos的作用，不过它是整个mysql复制架构全局通用的，即在整个mysql冗余架构中，它们的日志文件里面事件的gtid的数值是一致的。
• gtid是一个对于已提交的事物的编号，并且是一个全局唯一的编号。
• 通过gtid保证每个主库上提交的事务在集群中有一个唯一的id。这种方式强化了主备的一致性，故障恢复及其容错能力。

pos与gtid的区别

• 两者都是日志文件里的一个标志，如果将整个mysql集群看作一个整体，pos就是局部的，gtid就是全局的。

实验环境

主机名(ip)	作用
server1(172.25.24.1)	master
server2(172.25.24.2)	slave

gtid主从复制

server1(master)

• 在异步复制实验的基础上，修改配置文件。

[root@server1 ~]# vim /etc/my.cnf

31 gtid_mode=ON
32 enforce-gtid-consistency=true

[root@server1 ~]# systemctl restart mysqld

• 查看server1的uuid。

[root@server1 ~]# cat /var/lib/mysql/auto.cnf 
[auto]
server-uuid=ba2ea735-b17c-11e9-a9e5-5254008d153c

server2(slave)

• 编辑配置文件，重启服务。

[root@server2 ~]# vim /etc/my.cnf

 30 gtid_mode=ON
 31 enforce-gtid-consistency=true

[root@server2 ~]# systemctl restart mysqld

• 先停止slave，添加新的模式，然后再次开启。查看两个线程的状态。

[root@server2 ~]# mysql -uroot -pWsp+123ld
mysql> stop slave;
mysql> change master to master_host='172.25.24.1',master_user='repl',master_password='Wsp+123ld',master_auto_position=1;
mysql> start slave;
mysql> show slave status\G;

测试

• server1插入数据。

mysql> insert into zhang.userlist values('lhr','22');
mysql> select * from zhang.userlist;
+----------+----------+
| username | password |
+----------+----------+
| zhang    | 11       |
| lhr      | 22       |
+----------+----------+

• 在server2查看数据库中的数据。

mysql> select * from zhang.userlist;
+----------+----------+
| username | password |
+----------+----------+
| zhang    | 11       |
| lhr      | 22       |
+----------+----------+

gtid半同步复制

定义

• MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果挂掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。则半同步复制就解决数据丢失的问题。

半同步复制特点

• 确保事务提交后binlog至少传输到一个从库
• 不保证从库应用完成这个事务的binlog
• 网络异常或从库宕机，卡主库，直到超时或从库恢复
  
• 事物在主库执行完binlog后接受到从库的ACK，才会回复客户端。所以，相比而言，性能有所降低。

server1(master)

• 安装半同步设置的服务插件。

INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';

• 查看插件状态。

SELECT PLUGIN_NAME, PLUGIN_STATUS
    ->        FROM INFORMATION_SCHEMA.PLUGINS
    ->        WHERE PLUGIN_NAME LIKE '%semi%';

• 开启半同步复制。

SET GLOBAL rpl_semi_sync_master_enabled=1;

• 查看环境变量。

mysql> SHOW VARIABLES LIKE 'rpl_semi_sync%';

• 查看状态变量。

mysql> SHOW STATUS LIKE '%rpl%';

server2(slave)

• 安装半同步插件

INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

• 查看插件状态。

 mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS
    -> FROM INFORMATION_SCHEMA.PLUGINS
    -> WHERE PLUGIN_NAME LIKE '%semi%';

• 开启半同步复制。

mysql> SET GLOBAL rpl_semi_sync_slave_enabled=1;

• 重启I/O线程（如果I/O线程的状态为connecting也可以重启I/O线程来解决）。如果没有重启I/O线程，则默认还是异步复制的状态。

mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;

• 查看slave的两个线程的状态。

mysql> show slave status\G;

• 查看环境变量。

mysql> show variables like '%rpl%';

测试

• 关闭slave的I/O线程。

mysql> STOP SLAVE IO_THREAD;

• 在master端插入数据测试，可以看到默认会等待10s（master端可以设置），当10s过后，会自动变为异步复制。

mysql> insert into userlist values('westos','666');
mysql> insert into userlist values('linux','456');

• slave端先查看，此时数据还未同步，重新打开I/O线程，发现数据同步了，但这是异步复制所同步过来的数据。

mysql> select * from zhang.userlist;
mysql> START SLAVE IO_THREAD;
mysql> select * from zhang.userlist;

• slave端查看数据同步的进度：

mysql> show processlist;