文章目录
基于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;