环境介绍:
Ubuntu Server 16.04.2+MySQL 5.7.17 Community Server (GPL)
MySQL安装
通过APT的方式安装，官方指导文档地址：
https://dev.mysql.com/downloads/repo/apt/
1、下载mysql-apt-config_0.8.3-1_all.deb
2、安装deb
A Quick Guide to Using the MySQL APT Repository：
https://dev.mysql.com/doc/mysql-apt-repo-quick-guide/en/
|
1 |
|
3、更新源
|
1 |
|
4、安装MySQL
|
1 |
|
5、根据提示选择安装和设置密码。
另外，还需要对其进行设置，绑定的IP和打开防火墙的3306端口，这里主要是学习MySQL半同步复制，对MySQL的安装不做多解释，如果疑问欢迎留言。
MySQL半同步复制介绍
（1）默认情况下，MySQL的复制功能是异步的，异步复制可以提供最佳的性能， 主库把binlog日志发送给从库，这一动作就结束了，并不会验证从库是否接收完毕，这一过程，也就意味着有可能出现当主服务器或从服务器端发生故障的时候，有可能从服务器没有接收到主服务器发送过来的binlog日志，这就会造成主服务器和从服务器的数据不一致，甚至在恢复时造成数据的丢失。
注意：
半同步复制模式必须在主服务器和从服务器端同时开启，否则主服务器默认使用异步复制模式。
（2）异步复制案例:
MySQL5.6 数据库主从（Master/Slave）同步安装与配置详解
（3）为了解决上述可能发生的错误，MySQL 5.5 引入了一种半同步复制模式。该模式可以确保从服务器接收完主服务器发送的binlog日志文件并写入到自己的中继日志relay log里，然后会给主服务器一个反馈，告诉主服务器已经接收完毕，这时主服务线程才返回给当前session告知操作完成。
（4）当出现超时情况是，主服务器会暂时切换到异步复制模式，直到至少有一个从服务器从及时收到信息为止。
（5）中继日志的自我修复:
从MySQL 5.5.X 版本开始，增加了relay_log_recovery参数，这个参数的作用是：当slave从库宕机后，假如relay.log损坏了，导致一部分中继日志没有处理，则自动放弃所有未执行的relay-log,并且重新从master上获取日志，这样就保证了relay-log的完整性。默认情况下该功能是关闭的，将relay_log_recovery的值设置为1时，可在slave从库上开启该功能，建议开启。
（6）半同步复制与异步复制的切换：
半同步复制的工作原理就是当slave从库IO_Thread线程将binlog日志接收完毕之后，要给master主库一个确认，如果rpl_semi_sync_master_timeout=10000 (10秒)超过10秒未收到slave从库的接受确认信号，那么就会自动切换为传统的异步复制模式。
MySQL半同步复制配置
首先，需要安装两个MySQL，这里是：
- Master：192.168.1.227
- Slave：192.168.1.224
原始数据库的模样如下：
一、Master配置
（1）在Master数据库安装半同步复制插件：
|
1 |
|
（2）设置Master上开启半同步复制：
|
1 |
|
（3）修改mysqld.cnf 配置文件：
上图指出了MySQL配置的文件路径。
|
1 2 3 4 5 6 7 |
|
（4）修改MySQL server-uuid配置文件：
|
1 2 |
|
修改 auto.cnf文件，server-uuid的值格式固定，为了和Slave的区别开
|
1 2 |
|
（5）查看配置是否成功：
|
1 |
|
（6）参数说明：
1、rpl_semi_sync_master_enabled = 1,表示在master上已经开启了半同步复制模式；
2、rpl_semi_sync_master_timeout = 10000，表示如果主库在某次事务中的等待时间超过10000毫秒，则降级为异步复制模式，不在等待slave从库。如果主库再次探测到slave从恢复了，则会自动切换回半同步复制模式；
3、rpl_semi_sync_master_wait_no_slave ,表示是否允许master每个事务提交后都要等待slave的接收确认信号。默认为ON，即每一个事务都会等待。如果为OFF，则slave追赶上之后，也不会开启半同步复制模式，需要手工开启；
4、rpl_semi_sync_master_trace_level = 32,指用于开启半同步复制模式时的调试级别，默认为32。
可以看出，在配置Master的时候，只设置了1，其他的都采取的默认设置。
二、Slave配置
（1）在Slave数据库安装半同步复制插件：
|
1 |
|
（2）设置Slave上开启半同步复制：
|
1 |
|
（3）修改mysqld.cnf 配置文件：
|
1 2 3 4 5 6 |
|
（4）修改MySQL server-uuid配置文件：
|
1 2 |
|
修改 auto.cnf文件，server-uuid的值格式固定，为了和Slave的区别开
|
1 2 |
|
确保和Master的server-uuid不一样！
（5）查看配置是否成功：
|
1 |
|
（6）参数说明：
1、rpl_semi_sync_slave_enabled = 1,表示在slave上已经开启了半同步复制模式；
2、rpl_semi_sync_slave_trace_level = 32,指用于开启半同步复制模式时的调试级别，默认为32。
三、为Slave指定Master
（1）命令行模式下重启Master
|
1 |
|
（2）命令行模式下重启Slave
|
1 |
|
（3）查看Master状态：
|
1 2 3 4 5 6 7 8 9 10 |
|
注意：
|
1 2 |
|
很重要，后边需要使用！
（4）为Slave指定Master：
1、首先关闭Slave的半同步复制
|
1 2 |
|
2、为Slave指定Master
|
1 2 3 |
|
其中：
|
1 2 3 4 5 |
|
注意：
在MySQL 5.6版本以后，在进行主从复制的时候可以使用GTID的方式，无需再找binglog和pos点，只需要知道主服务器的IP、端口、账户、密码就可以实现自动找点同步，开启GTID功能的时候就不用再使用binlog和pos了。详细信息，请查阅相关资料进行学习。
3、开启Slave的半同步复制
|
1 2 |
|
四、测试半同步复制是否成功
五、如何优雅的关闭Slave同步信息
在某些时候，一台服务器不再用来作为Slave，那么我们就需要清楚他的同步信息，一般会使用：
|
1 2 |
|
但是，这样再通过show master status\G显示的时候：
|
1 |
|
还是会出现同步的信息，这是因为执行了 reset slave 只是把 master.info 和 relay-log.info 文件删除了，但同步信息还在，如果有人在执行start slave命令开启了同步功能，结果就会又从头开始同步了，有可能还会造成数据的丢失。
如何让其清除的更干净哪？请使用下边的命令：
|
1 2 |
|
再次执行show master status\G就不会再有任何信息了。
六、部分异常场景模拟
（1）半同步复制与异步复制的切换：
上述已经介绍了为什么会出现半同步复制到异步复制的切换，那么现在模拟一个场景进行演示。
场景如下：
1、关闭slave同步，停止IO接收binlog日志
|
1 |
|
该操作就将IO线程关闭，等待10秒之后，如果master未收到来自slave的确认信息，就会切换到异步复制模式：
上图看到slave已经关闭了半同步复制模式，再次开启：
|
1 |
|
此时，已经还原到半同步复制模式了。
（2）同步报错案例演示：
我们，首先从slave库上删除数据库表 ufind，然后到master再次删除该库ufind，该同步就会报错：
Last_Error: Error ‘Can‘t drop database ‘ufind‘; database doesn‘t exist‘ on query. Default database: ‘ufind‘. Query: ‘DROP DATABASE `ufind`‘
此时，查看半同步状态：
是开启的，因此没有将半同步复制模式转化为异步复制模式，可以看出半同步复制模式跟IO_Thread是有直接关系的，但跟SQL_THREAD没有关系。
也就是说，slave从库接收完二进制日志后给master主库一个确认，但是他不会管relay-log中继日志是否执行完毕。
六、半同步复制模式性能分析及优缺点
在通常情况下，由于异步复制模式不需要等待从服务器的响应，其速度较半同步复制模式要快，吞吐率要高，在数据进行更新、插入、删除的时候其速度要高于半同步复制模式。但是，半同步复制模式有利于数据的一致性，对于一些数据一致性要求较高的，网络波动较小的可以采用半同步复制模式。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。
原文地址：https://www.cnblogs.com/HKROnline-SyncNavigator/p/10971469.html