rpl_semi_sync_master_wait_point - xiaoboluo768/qianjinliangfang GitHub Wiki
- 此变量控制半异步复制中主库在发起事务commit操作之后在什么节点等待从库接收binlog的ACK确认。
- 有效值有：AFTER_SYNC和AFTER_COMMIT，含义如下：
- AFTER_SYNC（默认值）：主库将每个事务写入二进制日志，并将二进制日志sync到磁盘。在sync binlog之后，主库等待从库该事务的ack确认。在收到任意一个（5.7中可以使用参数rpl_semi_sync_master_wait_for_slave_count来设置必须要接收到多少个从库的ack确认之后才执行后续的动作，默认值为1，与5.7之前的版本相同）从库的确认后，主人将在存储引擎层提交事务，并将事务提交结果返回给客户端
- AFTER_COMMIT：主库将每个事务写入二进制日志，并sync二进制日志到磁盘，同时在存储引擎层提交事务。主库在存储引擎层提交事务之后再等待从库该事务的ACK确认。在收到从库ACK确认后，主库返回结果给客户端
- 这些设置的复制特性(应用场景表现)如下所示：
- 使用AFTER_SYNC，在从库返回ACK确认给主库，主库在存储引擎层提交事务之后，对于已提交的事务，所有客户端在同一时间看到的事务相同。因此，所有客户端都在主库上看到的数据相同。在主库故障的情况下，主机上已提交的所有事务必然已被复制到从库（已保存到其中继日志中）。主库故障转移到从库时数据是无损的，因为主库最新提交的事务必须在从库中存在，从库拥有主库最新的数据。
- 使用AFTER_COMMIT，发起事务的客户端只有在服务器提交到存储引擎并接收到从库ACK确认后才会返回状态。在主库存储引擎层提交之后与主库收到从库的ACK确认之间的这段时间间隙，其他新发起的客户端可以在发起提交客户端返回结果之前看到它已提交的事务。那么如果主库发生错误，在主库崩溃之后故障切换到从库时（此时从库有可能并没有接收到主库的该事务的binlog events），对于之前在主库已经查询到的数据的用户，在故障转移到从库之后再次发起查询时，可能发现查询不到数据了，就像数据丢失了一样。
- 对于5.7.2之前的旧版本半同步复制插件，半同步复制中主库行为相当于该变量的AFTER_COMMIT的设置值对应的行为。
- 5.7.2或更高版本的semi-sync半同步复制插件与之前版本的半同步复制插件并不兼容，所以不能和之前版本的mysql server半同步复制机制混用
- 全局变量，动态变量，枚举类型，有效值为：AFTER_SYNC和AFTER_COMMIT，默认值为AFTER_SYNC，5.7.2版本引入
- 有效值有：AFTER_SYNC和AFTER_COMMIT，含义如下：
上一篇：rpl_semi_sync_master_wait_for_slave_count | 下一篇：performance_schema