Mysql主从复制的三种同步方式和半同步复制配置

主从复制原理

1.当master节点接收到一个写请求时，这个写请求可能是增删改操作，此时会把写请求的更新操作都记录到binlog日志中。

2.master节点会把数据复制给slave节点，这个过程，需要每个slave节点连接到master节点上，master节点就会为每一个slave节点分别创建一个binlog dump线程，用于向各个slave节点发送binlog日志。

3.binlog dump线程会读取master节点上的binlog日志，然后将binlog日志发送给slave节点上的I/O线程。当主库读取事件的时候，会在binlog上加锁，读取完成之后，再将锁释放掉。

4.slave节点上的I/O线程接收到binlog日志后，会将binlog日志先写入到本地的relaylog中，relaylog中就保存了binlog日志。

5.slave节点上的SQL线程，会来读取relaylog中的binlog日志，将其解析成具体的增删改操作，把这些在master节点上进行过的操作，重新在slave节点上也重做一遍，达到数据还原的效果，这样就可以保证master节点和slave节点的数据一致性了。

过程中binlog和relay log都是顺序读写。

主从同步的数据内容其实是二进制日志（Binlog），存储的是一个又一个的事件（Event），这些事件分别对应着数据库的更新操作，比如INSERT、UPDATE、DELETE等。

另外我们还需要注意的是，不是所有版本的MySQL都默认开启了服务器的二进制日志，在进行主从同步的时候，我们需要先检查服务器是否已经开启了二进制日志。

二进制日志，它是一个文件，在进行网络传输的过程中就一定会存在一些延迟，比如200ms，这样就可能造成用户在从库上读取的数据不是最新的数据，也就会造成主从同步中的数据不一致的情况发生。比如我们对一条记录进行更新，这个操作是在主库上完成的，而在很短的时间内，比如100ms，又对同一个记录进行读取，这时候从库还没有完成数据的同步，那么，我们通过从库读取到的数据就是一条旧的数据。这时候就要了解数据复制方式了。

MySQL主从复制主要有以下几种模式：

基于SQL语句的复制（Statement-Based Replication, SBR）：这是MySQL默认的复制方式。主服务器记录并发送执行的每条SQL语句到从服务器执行。这种方式的优点是复制日志较小，可以节约I/O，提高性能。但缺点是在某些情况下，如非确定性SQL语句或涉及系统函数等，可能会导致主从数据的不一致。

基于行的复制（Row-Based Replication, RBR）：在这种模式下，主服务器记录哪些行被修改并发送到从服务器。这种方式的优点是可以避免SBR模式中的非确定性问题，确保主从数据的一致性。但缺点是复制日志较大，尤其是对大表的全表修改操作。

混合模式复制（Mixed-Based Replication, MBR）：这种模式结合了SBR和RBR的优点。它默认使用SBR，但当遇到可能导致数据不一致的情况时，它会自动切换到RBR。这种方式可以在保持复制效率的同时，尽可能保证数据的一致性。

此外，MySQL主从复制还包括异步模式、半同步模式、GTID模式以及多源复制模式，其中默认是异步模式。

1.异步复制（Asynchronous replication）

MySQL默认采用的复制策略就是异步复制，当主库提交事务后，会通知binlog dump线程发送binlog日志给从库，一旦binlog dump线程将binlog日志发送给从库之后，不需要等到从库也同步完成事务，主库就会将处理结果返回给客户端。

因为主库只管自己执行完事务，主库在执行完客户端提交的事务后会立即将结果返给客户端，并不关心从库是否已经接收并处理，这就可能导致短暂的主从数据不一致的问题了，比如刚在主库插入的新数据，如果马上在从库查询，就可能查询不到。

而且，当主库提交事物后，如果宕机挂掉了，此时可能binlog还没来得及同步给从库，这时候如果为了恢复故障切换主从节点的话，就会出现数据丢失的问题，所以异步复制虽然性能高，但数据一致性上是最弱的。

这样就会有一个问题：主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。

2.全同步复制（Fully synchronous replication）

指当主库执行完一个事务，要求所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。因此，虽然全同步复制数据一致性得到保证了，但是主库完成一个事务需要等待所有从库也完成，性能会比较低。

3.半同步复制（Semisynchronous replication）

MySQL 5.5版本之后开始支持半同步复制的方式。半同步复制的方式介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库收到了Binlog并写到中继日志relay log中再返回给客户端。这样做的好处就是提高了数据的一致性，当然相比于异步复制来说，至少多增加了一个网络连接的延迟，降低了主库写的效率。

相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。

4.增强半同步复制（Lossless Semi-Sync Replication）

增强半同步复制，是 MySQL 5.7.2后的版本对半同步复制做的一个改进，原理上几乎是一样的，主要是解决幻读的问题。主库配置了参数rpl_semi_sync_master_wait_point = AFTER_SYNC后，主库在存储引擎提交事务前，必须先收到从库数据同步完成的确认信息后，才能提交事务，以此来解决幻读问题。

二、半同步复制配置

主数据库配置

从数据库配置

查看半同步是否在运行

三、半同步复制转为异步复制的情况

当半同步复制发生超时（由rpl_semi_sync_master_timeout参数控制，默认为10000ms，即10s），会暂时关闭半同步复制，转而使用异步复制，也就是会自动降为异步工作。

当master dump线程发送完一个事务的所有事件之后，如果在rpl_semi_sync_master_timeout内，收到了从库的响应，则主从又重新恢复为半同步复制。

四、使用半同步复制注意点

1.在一主多从的架构中，如果要开启半同步复制，并不要求所有的从都是半同步复制。

2.MySQL 5.7极大的提升了半同步复制的性能。

实际项目中具体问题具体分析，数据库优化可以先从SQL优化，索引优化以及Redis缓存等方面来考虑，然后再考虑是否采用主从架构实现读写分离。

选择哪种复制模式取决于具体的需求。例如，如果数据库主要执行大量的简单查询，并且希望尽可能减小复制日志的大小，那么SBR可能是最好的选择。如果数据库经常执行复杂的、涉及大量行的修改操作，并且更关心数据的一致性，那么RBR可能是更好的选择。如果数据库同时具有上述两种情况，那么MBR可能是最好的选择。

请注意，MySQL的版本和配置也可能影响可用的复制模式。在选择复制模式时，建议参考MySQL的官方文档和最佳实践，并根据实际情况进行测试和评估。