企业建站找哪家,网络营销的认识,网站分为哪些部分组成部分组成,wordpress转移空间0、基础知识and问题 从基础上我们了解#xff1a; #xff08;1#xff09;redolog作为数据库保证持久化的日志#xff0c;在update事务提交后就会按一定的策略刷入磁盘中#xff0c;在刷入后#xff0c;即使数据库断电宕机#xff0c;mysql也能从redolog中恢复数据到磁…0、基础知识and问题 从基础上我们了解 1redolog作为数据库保证持久化的日志在update事务提交后就会按一定的策略刷入磁盘中在刷入后即使数据库断电宕机mysql也能从redolog中恢复数据到磁盘中从而实现持久化。 2同样的对于binlog主要用于主从数据库之间的数据同步以及数据库的全数据恢复常规的步骤是类似的主库的update过程就会写binlog提交后就按照一定的策略刷入磁盘中。紧接着在主从同步中通过以下步骤发送给从库从库通过读取中继日志实现主从的一致性。 3对于undolog会在开启事务update更新之前先记录相应的旧值方便事务的回滚。
问题 现在有一个问题由于RedoLog和BinLog的刷盘过程是相互独立的两个过程那么在主从同步的过程中如果发生数据库宕机如果RedoLog日志或者BinLog日志的其中之一成功刷盘而另一个没有成功由于相互独立这是有可能发生的那么就会发生以下情况 如果在将 redo log 刷入到磁盘之后 MySQL 突然宕机了而 binlog 还没有来得及写入。 MySQL 重启后通过 redo log 能将数据字段恢复到新值 但是 binlog 里面没有记录这条更新语句在主从架构中binlog 会被复制到从库由于 binlog 丢失了这条更新语句从库的这字段是旧值与主库的值不一致性如果在将 binlog 刷入到磁盘之后 MySQL 突然宕机了而 redo log 还没有来得及写入。 由于 redo log 还没写崩溃恢复以后这个事务无效所以数据字段还是旧值 而 binlog 里面记录了这条更新语句在主从架构中binlog 会被复制到从库从库执行了这条更新语句那么字段是新值与主库的值不一致性 那么该如何在断电宕机情况下保证主从的一致性呢 即 数据库的两阶段提交策略。
1、 两阶段提交的具体过程 两阶段就是让redolog分为两阶段提交因为redolog的操作可以撤销通过一个MySQL 内部开启一个 XA 事务注意这个事务是一个宏观上的大事务而不是sql语句组成的事务分两阶段来完成 XA 事务的提交来保证redolog和binglog两个日志的刷盘这两个任务的原子性。 具体来说redolog的提交分为了prepare阶段和commit阶段 1prepare阶段将redolog的事务状态设为prepare、将事务XID写入redo log并把redo log持久化到磁盘中 2commit阶段把事务XID写入binlog并把binlog刷盘然后将redo log事务状态设置为commit 我们发现实际上这个过程的核心是通过日志的事务ID来判断是否完成某个步骤的例如在这样的过程下如果出现异常是如何保证双方的一致性呢 断电后在 MySQL 重启后会按顺序扫描 redo log 文件碰到处于 prepare 状态的 redo log就拿着 redo log 中的 XID 去 binlog 查看是否存在此 XID 如果redolog都刷盘失败那就全都回滚如果 binlog 中没有当前内部 XA 事务的 XID说明虽然redolog 完成刷盘但是 binlog 还没有刷盘则回滚整个 XA事务。因为有undolog所以可以回滚提交了的redolog如果 binlog 中有当前内部 XA 事务的 XID说明 redolog 和 binlog 都已经完成了刷盘则提交事务。如果redolog都是commit状态了那更没问题了 2、个人思考 在学习的过程中我在思考一个问题为什么两阶段提交要让redolog分两阶段而不是让binlog分成两阶段提交呢 和同学探讨请教后发现是因为两阶段提交的redolog即使redolog刷盘了如果binlog没刷盘我就让两个事情都回滚就好了对主从数据不会有任何影响。 但是如果让binlog两阶段提交如果binlog刷盘成功了、而redolog刷盘失败由于binlog刷盘一成功就会进行主从复制从数据库的数据已经被刷盘了此时虽然redolog失败、我想把整个大事务rollback但由于已经把binlog同步给从数据库已然无力回天。 实在是豁然开朗啊。 3、两阶段提交的弊端 磁盘 I/O 次数高对于“双1”配置每个事务提交都会进行两次 fsync刷盘一次是 redo log 刷盘另一次是 binlog 刷盘。锁竞争激烈两阶段提交虽然能够保证「单事务」两个日志的内容一致但在「多事务」的情况下却不能保证两者的提交顺序一致因此在两阶段提交的流程基础上还需要加一个锁来保证提交的原子性从而保证多事务的情况下两个日志的提交顺序一致。
