此实验要在搭建好基于gtid的主从复制基础上操作
一、设置半同步
-
主机
mysql> install plugin rpl_semi_sync_master soname 'semisync_master.so'; Query OK, 0 rows affected (0.08 sec) mysql> set global rpl_semi_sync_master_enabled=1; Query OK, 0 rows affected (0.00 sec) mysql> SELECT PLUGIN_NAME,PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
-
从机
mysql> install plugin rpl_semi_sync_slave soname 'semisync_slave.so';(加载semisync_master插件,在初次加载插件后,MySQL会将该插件记录到系统表mysql.plugin中,下次启动时系统则会自动加载该插件了,无需再次执行上面的命令。) Query OK, 0 rows affected (0.10 sec) mysql> set global rpl_semi_sync_slave_enabled=1; Query OK, 0 rows affected (0.00 sec) mysql> STOP SLAVE IO_THREAD;(一定要对slave的IO线程进行重启) Query OK, 0 rows affected (0.07 sec) mysql> START SLAVE IO_THREAD; Query OK, 0 rows affected (0.00 sec)
二、测试
-
当从机关闭IO线程后(stop slave IO_THREAD;)
主机创建一个数据库HR:
从机查看不到
从机打开IO线程,可查看到数据库HR此时的数据库HR是通过异步复制过来的;
此时,在主机上查看rpl状态:
-
当从及IO线程打开时:
主机创建一个数据库
半同步复制,它向异步复制协议添加一个同步步骤。这意味着主节点在提交时等待从节点ACK确认它已经接收到事务。只有这样,主节点才恢复提交操作。
从机可以查看到
在主机上查看状态:
mysql> show status like '%rpl%';
+--------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients | 1 |(有多少个Semi-sync的备库)
| Rpl_semi_sync_master_net_avg_wait_time | 0 |(事物提交后,等待备库响应的平均时间)
| Rpl_semi_sync_master_net_wait_time | 0 |(等待网络响应的总次数)
| Rpl_semi_sync_master_net_waits | 2 |(总的网络等待时间)
| Rpl_semi_sync_master_no_times | 1 |(一共有几次从Semi-sync跌回普通状态)
| Rpl_semi_sync_master_no_tx | 1 |(备库未及时响应的事务数)
| Rpl_semi_sync_master_status | ON |(主库上Semi-sync是否正常开启)
| Rpl_semi_sync_master_timefunc_failures | 0 |(时间函数未正常工作的次数)
| Rpl_semi_sync_master_tx_avg_wait_time | 714 |(开启Semi-sync,事务返回需要等待的平均时间)
| Rpl_semi_sync_master_tx_wait_time | 714 |(事务等待备库响应的总时间)
| Rpl_semi_sync_master_tx_waits | 1 |(事务等待备库响应的总次数)
| Rpl_semi_sync_master_wait_pos_backtraverse | 0 |(改变当前等待最小二进制日志的次数)
| Rpl_semi_sync_master_wait_sessions | 0 |(当前有几个线程在等备库响应)
| Rpl_semi_sync_master_yes_tx | 1 |(Semi-sync模式下,成功的事务数)