MariaDB 几种热备同步方式比较

 

 

异步：主库将事务Binlog事件写入到Binlog文件中，此时主库只会通知一下Dump线程发送这些新的Binlog，然后主库就会继续处理提交操作，而此时不会保证这些Binlog传到任何一个从库节点上。主库的事务执行不会管备库的同步进度，如果备库落后，主库不幸crash，那么就会导致数据丢失。

半同步：是介于全同步复制和异步复制之间的一种，主库只需要等待至少一个从库节点收到并且Flush Binlog到Relay Log文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全执行并且提交的反馈，这样就节省了很多时间。数据丢失的风险，当一个事物commit之后，如果主节点此时宕机了，切换到从库，那么从库还没有接到之前event，那么在主库成功提交的数据，在从库也就看不到了，此时就是数据丢失的情况；

全同步机制：当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才能继续做后续操作。这里面有一个很明显的缺点就是，主库完成一个事务的时间被拉长，性能降低。

无损复制：基于半同步的一种优化，半同步是将事物首先commit之后再等待slave端的ACK，这样会导致数据的幻读，然而无损复制是等ACK应答之后再去commit事务。同样上面的问题，如果主节点宕机了，切换到了从节点，但是主节点的event事件依旧没有去提交，此时两边都没有这个事务，所以从某种意义来说不会有数据丢失。但是也同样存在一个问题，如果主库数据传输到Slave后，Slave进行ack确认时主库宕机，那么当主库重新启动后由于redo和binlog都有事务信息，所以这个或这组事务必然会提交成功，那么主从数据一致，皆大欢喜。那么如果说主库数据在传输到从库的过程中宕机，那么从库必然没有最新binlog，当主库重启后同样会提交最后这个或这组事务，此时就意味着主从数据不一致。如果你想让老的主库做新主库的从库，就需要人工干预处理了。这也是基于无损复制做高可用需要考虑的。

参考链接
http://www.ywnds.com/?p=7023