当前 火山引擎 RDS for MySQL 的同步方式有两种，分别为异步复制和半同步复制，下面会分析下二者的不同。
主库上产生的 binlog 通过 binlog dump 线程发送给从库，从库的 IO 线程 将 binlog 日志保存到 relay-log 中，然后备库的 SQL 线程进行回放来达到数据同步的目的。
在异步复制中，主库在binlog 落盘之前，binlog dump 线程将 binlog 推送到从库，然后继续执行事务commit的逻辑，不管从库是否已经成功接收到 binlog 还是已经应用。 异步复制最大的问题在于无法保证主库和从库的数据一致性。
使用 MySQL 异步复制最大的问题在于当主库崩溃，当前从库上一部分数据还没有被接收到，在故障转移之后导致数据不一致，基于此缺陷，MySQL 推出了半同步复制。
半同步复制 - after_commit
MySQL 在 5.5 中 引入了半同步复制机制，其中的关键点在于：主库在的事务需要保证从库接收到 binlog 并返回 ACK 确认之后，主库上的事务才会返回成功给客户端。
after_commit 模式最大的问题在于幻读。在这种模式下，在等待 ACK 的过程中，实际上在存储引擎内部事务已经成功提交，发起事务的客户端一直阻塞在事务返回成功阶段，但是其他客户端可以查到此最新提交的事务，在故障转移之后，新的主库确查询不到这条貌似已经提交的事务，好像发生了幻读一样。
增强半同步 - after_sync
基于上述 after_commit 的缺陷，从 5.7 开始，MySQL 开始支持增强半同步，在这种模式下，主库上的事务在存储引擎层提交之前，必须要等到从库的 ACK 确认，否则拒绝提交事务。即使在故障转移之后，也不会发生幻读的情况，因为在之前的主库上事务并没有提交成功。
after_commit 与 after_sync 相比，after_commit 模式是在 InnoDB 层的 Commit Log 之后等待 ACK，而 after_sync 是在 MySQL Server 层的 write binlog 后，等待 ACK。
在您创建 RDS for MySQL 实例时，默认支持的方式为半同步复制，您可以根据您自身的业务特点，选择合适的复制方式，在控制台上查看，修改复制模式如下图：
[1] https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html 如果您有其他问题，欢迎您联系火山引擎技术支持服务
