Linux企业实战---mysql的半同步复制

1.MySQL 主从复制模式

异步模式（mysql async-mode）

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

全同步模式

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

半同步模式(mysql semi-sync)

介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

这种模式下主节点只需要接收到其中一台从节点的返回信息，就会commit；否则需要等待直到超时时间然后切换成异步模式再提交；这样做的目的可以使主从数据库的数据延迟缩小，可以提高数据安全性，确保了事务提交后，binlog至少传输到了一个从节点上，不能保证从节点将此事务更新到db中。性能上会有一定的降低，响应时间会变长。

2.基于GTID的半同步复制模式的实现

该实验必须在实现基于GTID的主从复制的基础上进行，基于GTID的主从复制可参考上一篇博客：

配置server1（主库）
（1）加载插件，并查看插件加载是否成功

[root@server1 mysql]# mysql -uroot -pWestos+001

mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so';
Query OK, 0 rows affected (0.09 sec)

在这里插入图片描述
查看插件是否加载成功（active表示成功）

mysql> select PLUGIN_NAME,PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS where PLUGIN_NAME like '%semi%';

在这里插入图片描述
（2）启动半同步复制，并查看半同步复制是否在运行

mysql> SET GLOBAL rpl_semi_sync_master_enabled=1;			#启动半同步复制
Query OK, 0 rows affected (0.00 sec)

mysql> show status like '%rpl%';		#查看半同步复制的状态是否是打开状态的
mysql>  show variables like '%rpl%';		#查看半同步复制的一些参数变量

在这里插入图片描述

rpl_semi_sync_master_timeout的值是10000（单位是毫秒），表示半同步复制时，当从库的io线程关闭时，主库等待10s。
当然10s这个时间是可以改的，通过参数SET GLOBAL rpl_semi_sync_master_timeout =N;更改。在实际的生产过程中，为了防止数据丢失，一般将N设置为无穷大。
配置server2（从库）
（1）加载插件，并查看插件加载是否成功

[root@server2 mysql]# mysql -uroot -pWestos+001


mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';
Query OK, 0 rows affected (0.05 sec)

查看插件是否加载成功

mysql> select PLUGIN_NAME,PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS where PLUGIN_NAME like '%semi%';

在这里插入图片描述
（2）启动半同步复制，并查看半同步复制是否在运行

mysql> SET GLOBAL rpl_semi_sync_slave_enabled=1;		#启动半同步复制
Query OK, 0 rows affected (0.00 sec)

slave端启动半同步复制之后,不能立即生效,需要重启slave端的io线程

mysql> stop slave IO_THREAD;
Query OK, 0 rows affected (0.02 sec)

mysql> start slave IO_THREAD;
Query OK, 0 rows affected (0.00 sec)

查看半同步复制状态

mysql> show status like '%rpl%';			#查看半同步复制是否打开
mysql> show variables like '%rpl%';			#查看半同步复制的一些参数变量

在这里插入图片描述

测试：
（1）在从库关闭io线程

mysql> stop slave IO_THREAD;
Query OK, 0 rows affected (0.02 sec)

（2）在主库更新数据，并查看更新以后的数据

mysql> use westos;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> insert into usertb values ('user6','666');
Query OK, 1 row affected (10.06 sec)				#一直停留10秒才会返回OK

有10秒的延迟，这是因为从库的io进程关闭了，不能及时的写入数据；主库等待10秒之后从库还没有起来，主库不再等待直接写入
等待完毕，10秒后直接写入
再次插入数据，主库直接写入，没有延迟
此时可以看到，数据传送成功之后，半同步复制就会关闭（这是因为从库没有成功接收到数据）。

show status like '%rpl%'或show status like 'semi’都可以。
Rpl_semi_sync_master_no_tx为失败次数，yes为成功次数
Rpl_semi_sync_master_yes_tx为1，半同步成功

 mysql> show status like '%rpl%';
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 0     |
| Rpl_semi_sync_master_net_avg_wait_time     | 0     |
| Rpl_semi_sync_master_net_wait_time         | 0     |
| Rpl_semi_sync_master_net_waits             | 1     |
| Rpl_semi_sync_master_no_times              | 1     |
| Rpl_semi_sync_master_no_tx                 | 1     |
| Rpl_semi_sync_master_status                | OFF   |
| Rpl_semi_sync_master_timefunc_failures     | 0     |
| Rpl_semi_sync_master_tx_avg_wait_time      | 0     |
| Rpl_semi_sync_master_tx_wait_time          | 0     |
| Rpl_semi_sync_master_tx_waits              | 0     |
| Rpl_semi_sync_master_wait_pos_backtraverse | 0     |
| Rpl_semi_sync_master_wait_sessions         | 0     |
| Rpl_semi_sync_master_yes_tx                | 0     |
+--------------------------------------------+-------+
14 rows in set (0.00 sec)

可以看到主库添加数据成功

mysql> select * from usertb;
+----------+----------+
| username | password |
+----------+----------+
| user1    | 123      |
| user2    | 123      |
| user3    | 123      |
| user6    | 666      |
+----------+----------+
4 rows in set (0.00 sec)

（3）在从库查看更新之后的数据

mysql> use westos;
Database changed
mysql> desc westos;
ERROR 1146 (42S02): Table 'westos.westos' doesn't exist
mysql> select * from usertb;
+----------+----------+
| username | password |
+----------+----------+
| user1    | 123      |
| user2    | 123      |
| user3    | 123      |
+----------+----------+
3 rows in set (0.00 sec)

发现内容没有同步

（4）在从库打开io线程，再次查看更新以后的数据

mysql> start slave IO_THREAD;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from usertb;
+----------+----------+
| username | password |
+----------+----------+
| user1    | 123      |
| user2    | 123      |
| user3    | 123      |
| user6    | 666      |
+----------+----------+
4 rows in set (0.00 sec)

当从库打开io线程之后，从库就接受到了数据，那么半同步复制又会重新开启

结论：
关闭server2上面的slave，然后在server1上面插入数据
sever1（master）等待10s发现server2（slave）没有发送ACK消息，自动变为异步同步，
然后在server2上把slave上面开启，会把之前的数据读过来

也就是说只要从库的io进程恢复工作就会立即同步没有同步的数据
半同步复制失败后会自动切换成异步复制，从库进程起来之后会检测主从库数据是否同步；若不同步，将会采用异步复制的方式同步数据
将插件安装在数据库中是临时的，退出重新登陆会失效，永久的可以将配置写在配置文件中

皮皮彭

发布了149 篇原创文章 · 获赞 1 · 访问量 3009

私信关注