一、基本知识
关于异步复制：
异步复制（Asynchronous replication）
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
关于全同步复制：
全同步复制（Fully synchronous replication）
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
关于半同步复制：
半同步复制（Semisynchronous replication）
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。（半同步复制：一主多从模式下，有一个从节点返回成功，即成功，不必等待多个节点全部返回）
在2010年MySQL 5.5版本之前，一直采用的是这种异步复制的方式。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。于是在MySQL在5.5中就顺其自然地引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中
对照官方文档
https://dev.mysql.com/doc/refman/5.7/en/replication-semisync-installation.html
1）正常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。
2）异常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。
3）很大的问题是：主机和从机事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。
为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制。
MySQL半同步，MySQL5.5由Google贡献的补丁才开始支持半同步复制（semi Replication）模式，该模式可以确保从服务器接收完主服务器发送的binlog日志文件并写入自己的中继日志（relay log）里，然后会给主服务器一个反馈，告诉对方已经接收到完毕，这时主库线程才返回当前session告知操作完成，当出现超时情况时，源主服务器会暂时切换到异步复制模式，直到至少有一台设置为半同步复制模式的从服务器及时收到信息为止。
原理：
主从同步可以同步多个数据库，也可以设置为一个数据库同步，如果设置一个数据库，在从服务器上其他数据可以写操作
半同步复制模式在主服务器和从服务器同时启用，否则主服务器默认使用异步复制模式
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
注意！：
异步复制可能会造成数据丢失，半同步复制就是为了解决数据丢失的问题
master做完一步等一步，需要等待至少一个slave节点完成复制之后才开始进行下一个操作 master做大事件的时候，需要进行半同步，master节点等待一个节点即可 当半同步出现问题的时候会自动切换为异步同步 银行数据库全同步，master节点等待集群中的所有全部节点 数据库要避免慢查询问题，会造成延迟，占用数据库的IO 优点：提高了数据完整性，数据至少会存在两个节点（master节点和一个slave节点） 加了消息确认ACK，不会造成数据丢失 出现问题会自动降低为异步复制
二、实验环境
server1:172.25.68.1 主库
server2:172.25.68.2
srever3: 172.25.68.3 关闭mysql-proxy
二、配置过程
在server1:
1.在主库上（server1）安装插件
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
2.查看插件是否安装
mysql> SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE '%semi%';
3.激活插件
mysql> SET GLOBAL rpl_semi_sync_master_enabled =1;
在server2:
1.在slave节点上（server2）也安装插件
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
2.激活插件
SET GLOBAL rpl_semi_sync_slave_enabled =1;
3.重启IO线程使半同步生效
mysql> STOP SLAVE IO_THREAD;
mysql> START SLAVE IO_THREAD;
从库重启io进程，激活插件之后必须重启io进程，否则不会生效，重启不成功说明两端数据不同步。
在srevr1:
1.在master节点上查看
mysql> show status like '%rpl%';
看到
| Rpl_semi_sync_master_status | ON |
表示已开启
mysql> show variables like '%rpl%';
+-------------------------------------------+------------+
| Variable_name | Value |
+-------------------------------------------+------------+
| rpl_semi_sync_master_enabled | ON | 是否开启半同步
| rpl_semi_sync_master_timeout | 10000 | 切换复制的timeout
| rpl_semi_sync_master_trace_level | 32 |用于开启半同步复制模式时的调试级别,默认是32
| rpl_semi_sync_master_wait_for_slave_count | 1 |至少有N个slave接收到日志
| rpl_semi_sync_master_wait_no_slave | ON |是否允许master 每个事物提交后都要等待slave的receipt信号。默认为on
| rpl_semi_sync_master_wait_point | AFTER_SYNC | 等待的point
| rpl_stop_slave_timeout | 31536000 |
+-------------------------------------------+--------控制stop slave 的执行时间，在重放一个大的事务的时候,突然执行stop slave,命令 stop slave会执行很久,这个时候可能产生死锁或阻塞,严重影响性能----+
https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html #具体参数可以看官方文档
默认延迟10s
在server2：
1.在slave节点上查看
mysql> show variables like '%rpl%';
+---------------------------------+----------+
| Variable_name | Value |
+---------------------------------+----------+
| rpl_semi_sync_slave_enabled | ON |是否开启半同步
| rpl_semi_sync_slave_trace_level | 32 |用于开启半同步复制模式时的调试级别,默认是32
| rpl_stop_slave_timeout | 31536000 |
+---------------------------------+----------+
2.停止slave上的io线程再测试
mysql> STOP SLAVE IO_THREAD;
在server1：
1.在master上插入数据
mysql> use westos;
mysql> insert into usertb values ('user6','123');
Query OK, 1 row affected (10.01 sec) #等待10s才成功，因为上面超时时间是10s，10s后如果没有收到slave节点的返回，就会切换到异步复制
2.查看半同步状态也是off，待同步的事务也是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 | 0 |
| 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 |
+--------------------------------------------+-------+
3.再次插入时就不会延迟，因为已经是异步了
mysql> insert into usertb values ('user7','123');
Query OK, 1 row affected (0.00 sec)
在server2:
1.slave上开启io线程
mysql> START SLAVE IO_THREAD;
2.查看进程
在server2
mysql> show processlist;输出结果显示了有哪些线程在运行
在server1：
说明各列的含义和用途
| id列 | 一个标识 |
|---|---|
| user列 | 显示当前用户，如果不是root，这个命令就只显示你权限范围内的sql语句 |
| host列: | 显示这个语句是从哪个ip 的哪个端口上发出的。可用来追踪出问题语句的用户 |
| db列: | 显示这个进程目前连接的是哪个数据库 |
| command列: | 显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect） |
| time列: | 此这个状态持续的时间，单位是秒 |
| state列 | :显示使用当前连接的sql语句的状态 |
4135
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
