上图中蓝色部分需要等待slave上的返回后才能继续进行,所以可能对master上的大并发性能产生一定的影响,但semi-sync Replication基本保证了主从上的数据一致,这里说基本保证,主要是因为,即使在semisync replication下,主机宕机了,也有可能造成某条数据的丢失,后面我们就来分析下这种异常的情况。
前面已经提到,semisync replication下,master提交事务后会等待从机的回复后进行下一条事务,如果在等待从机回复过程中,主机发生了意外宕机,这个时候,从机可能并没有接收到主机上传过来的binlog,而主机上该事务已经正常提交,这样进行主从切换后,从机上实际数据可能会比主机上少一条(最后一条),主从数据还是不一致。相比于异步复制,semisync replication减少了在主机异常后丢失数据量,但还是可能丢失一条事务数据,这是官方semisync replication的主要缺陷——最多丢失一条事务。
上面提到了即使是MySQL官方认为最安全的semisync replication,也存在丢失最后一条事务的可能性,那么如何能使事务得到足够的安全,也就是说,在某种情况下,即使发生master宕机,也不会造成哪怕一条事务的丢失?InnoSQL的VSR机制,就能保证master-slave下,master发生宕机,slave上也不会出现数据丢失。
InnoSQL VSR即InnoSQL Virtual Sync Replication的缩写,翻译过来是InnoSQL虚同步,之所以称之为虚同步,主要由于VSR保证了主上提交的数据写入到了从机的relay log,而不关心slave上relay log的回放是否已经完成,如果没有回放完成,那么主从上通过查询得到的数据可能是不一致的,也就是说,主从数据在某个时间点上并不是相同的,这要取决于从上relay log的回放速度,但是数据最终是一致的。
InnoSQL VSR基于官方semisync replication上进行改进,主要调整了数据在提交时的流程,把等待slave返回部分调整到了存储引擎提交之前,即如下图:
InnoSQL VSR提交流程
上图中我们把等待slave返回的操作放到了引擎层数据提交之前,只有当slave上收到binlog信息返回后,才允许master上进行数据提交,这样就保证了在master上提交的事务的binlog一定已经被slave接收到了,即使发生主机宕机,新的master上回放完relay log后的数据,与老的master上数据是一致的。
异步复制基本不影响master上的性能,但在主机宕机的情况下,会丢失部分数据;而官方semisync replication方案与InnoSQL VSR相比基本类似,对master上性能的影响也类似,所以在对数据一致性要求比较高的应用中,强烈推荐使用InnoSQL