问题1:Mysql是如何保证不丢数据的?

众所周知,事务一旦提交,则对数据的改变将永久有效,这是数据库持久性的特性.那么Mysql是如何做到不丢数据的?什么是commit?事务commit时Mysql又做了什么?

数据的持久性机制依赖server层的binlog以及InnoDB存储引擎层的redolog.
事务的commit操作本身,包含两个阶段的处理:
准备阶段:
server调用InnoDB写入redolog

完成阶段:
1.server写入binlog
2.server调用InnoDB,写入commit标签(在redolog中)

其中,事务提交是否成功,以binlog是否成功落盘为准.
场景1:
准备阶段失败,redolog没有写入,则提交失败,且数据一致.

场景2:
准备阶段成功,redolog写入,完成阶段server写入binlog失败,则提交失败.此时数据不一致(存在redolog但不存在binlog).宕机恢复时,因为不存在binlog,因此需要对事务进行回滚.

场景3
完成阶段server写入binlog成功,server调用InnoDB,写入commit标签失败,则提交成功.此时数据不一致(redolog中缺少commit标志).宕机恢复时,补偿写入commit标签以及后续处理.

总结,提交时的两阶段处理,可以保证数据的持久性,以及binlog和redolog内部的一致性.

问题2:如何提高Mysql可用性?

Mysql的ACID的特性保证了其单机的可靠性,但是存在单点风险.
由此引出了主从架构和复制的概念.

所谓复制,就是slave负责从master读取binlog,并写入自己的relaylog中,之后通过relaylog进行重放,已达到数据同步的目的.

问题3:Mysql支持哪些复制以及对应的优缺点?

生产环境中常见的复制包含异步复制和半同步复制两种.

异步复制就是在master事务提交后,立即给客户端返回结果,将复制操作变为异步的.优点是不会影响客户端的响应时效,缺点是无法保证主从间的数据一致性.如果master宕机,则slave可能会丢失数据.

半同步复制就是在事务提交后,结果返回给客户端之前,增加了与slave见的复制和确认过程,只有接到slave的ack后,才会返回给客户端结果.相比异步复制,它增加了等待的时间,也即降低了客户端响应失效,但是保证了master与slave间的强一致性.

注意:如果master等待slave的ack时超时,则会降级为异步复制模式,所以生产中要将超时时间设置的足够大,来保证半同步的有效性.

问题4:Mysql5.7之前半同步存在的问题?

Mysql5.7之前,半同步的复制流程为:
prepare(写redolog)->写binlog->写commit标志->复制->确认.
这对应rpl_semi_sync_master_point=AFTER_COMMIT的配置.

复制发生在commit完成之后,因此在复制期间,客户端拿到结果之前,事务结果已经可见了.也就是说,其他会话会先于当前会话看到事务结果.

为了解决这一问题,Mysql5.7增加了rpl_semi_sync_master_point=AFTER_SYNC的配置,将复制流程变为:
prepare(写redolog)->写binlog->复制->确认->写commit标志.
也就是说复制和确认发生在binlog写入成功之后,InnoDBcommit之前,由此,在复制完成之前,其他会话不会看到当前事务的结果.

问题5:主从架构下,如何保证可用性的同时,确保数据一致性?

前文所述,事务的持久性是以binlog写入是否成功为准的.如果master在binlog写入成功之后,复制之前发生宕机,则slave没有拿到master的binlog.此时如果为了高可用而进行slave升主操作时,会导致丢数据.

通常的解决方案是:在升主之前进行主从之间的数据对比校验,以确保数据一致性.

问题6:数据校验期间Mysql不可写如何解决?

通常通过多主从组,加数据分片和路由解决.当某个master宕机时,将写入请求导入另外的master,并在此期间对故障master进行恢复和数据校验.

另外,为了对机房断电进行容灾,通常采用一机房双master-slave,外加多机房的部署架构.