MySQL数据安全系列之三:高可用方案

前文中 《MySQL数据安全系列之二:备份选择》已经提到备份是防止数据丢失的一种很好的措施,通过定时备份,能避免大面积的数据丢失,但如果服务出现异常宕机,通过备份来恢复数据,停止对外服务的风险是不能避免的,因为数据恢复根据数据量的大小不同,通常都需要很长的恢复时间,而这段时间内服务对外都是不可用的,如果对服务要求比较高,还是需要使用MySQL的高可用方案。MySQL支持主(master)、从(slave)形式的架构,通过binlog进行中间数据的传递。


MySQL主从架构


  • 异步复制
MySQL默认支持异步复制,只要在主机(master)上配置binlog,从机(slave)上通过change master指定相应的主机就能建立异步复制。在异步复制的场景下,主机负责把binlog写入binlog文件,从机通过建立到主机的连接获取binlog信息。由于从机到主机之间是通过网络连接,可能造成从机获取binlog的速度会比主机写入binlog的速度慢很多,这样就会造成从机上数据的延迟,如果这个时候主机出现意外crash后无法正常启动,把从机提升为主机后,可能会有部分数据丢失(还没有传到从机部分binlog数据)
MySQL异步复制可能丢失数据
上图中阴影部分binlog数据可能由于主机的宕机而丢失,因为异步复制的从机可能当前读取的binlog点在pos1的位置,而master实际写入已经到pos2的位置,如果这个时候master意外宕机后(无法启动),pos1到pos2之前的数据就会被丢失(当然可以通过手工把master上的binlog补到slave上,这需要对MySQL非常熟悉)。

  •     Semi-sync Replication的原理
上图中蓝色部分需要等待slave上的返回后才能继续进行,所以可能对master上的大并发性能产生一定的影响,但semi-sync Replication基本保证了主从上的数据一致,这里说基本保证,主要是因为,即使在semisync replication下,主机宕机了,也有可能造成某条数据的丢失,后面我们就来分析下这种异常的情况。
前面已经提到,semisync replication下,master提交事务后会等待从机的回复后进行下一条事务,如果在等待从机回复过程中,主机发生了意外宕机,这个时候,从机可能并没有接收到主机上传过来的binlog,而主机上该事务已经正常提交,这样进行主从切换后,从机上实际数据可能会比主机上少一条(最后一条),主从数据还是不一致。相比于异步复制,semisync replication减少了在主机异常后丢失数据量,但还是可能丢失一条事务数据,这是官方semisync replication的主要缺陷——最多丢失一条事务。

  • InnoSQL VSR
上面提到了即使是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

本文来自网易实践者社区,经作者蒋鸿翔授权发布。