首页 / 日志 / 理解数据库日志进行故障修复的原理
理解数据库日志进行故障修复的原理
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了理解数据库日志进行故障修复的原理，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含5765字，纯文字阅读大概需要9分钟。
内容图文
一、前言
无论是在数据库，还是其他的业务系统，日志是非常重要的。日志通常在系统中有如下的作用：
1. 业务问题定位。系统开发中，谁没写几个BUG? 有了日志，就能方便快速定位问题，修复系统。这也是我们用日志最多的地方。
2. 系统运行流程监控。 雁过必留痕，通过日志可以进行系统校验，确保系统是按预定的流程运行，而不是你以为的方式。毕竟计算机运行的方式是它以为，而不是你以为。
3. 安全审计。 在无纸化办公的时代，谁做了什么事不是删记录就可以像鸵鸟一样，把头埋在沙里，以为万事无虞。
4. 故障修复。 这个基本是数据库的标配。无论是MySQL还是Redis, 无论是Mongodb还是ES, 都有日志协助修复系统。
本文梳理的重点就是数据库如何利用日志进行故障修复。
二、系统故障
在《事务处理概念与技术》一书中，记录了故障方方面面的来源：环境、操作、维护、硬件、软件、过程等。
作为用户，我们希望故障修复后，系统能够正常工作。或者说，我们希望系统能够容忍一些故障(容错)，以保障系统工作时长更久，996是不够的，最好是7*24。毕竟在自动化处理业务流程的时代，系统处理业务流程的效率太高(例如：支付宝助力天猫双11 OceanBase 每秒处理峰值达到6100 万次)。 停机的代价太大。对于电商和金融，每笔处理的流水都是白花花的银子，系统一罢工，损失不是一个人请假或者离职那么微不足道。
故障虽然出现的概率小，但是致命，不得不防。
三、应对措施
在《事务处理概念与技术》中，事务的理解很简单：数据库状态的变更。比如，我发工资了，那么我银行卡里余额就变多了，这个余额就是银行卡的一个状态。在发工资这个业务流程中，涉及到的另一端是公司银行卡的钱变少了。
数据库需要保障业务流程中，涉及到的主体状态变更是一致的，不然公司的帐就乱了。
这就引出了事务的特性：ACID。 ACID的规约其实就类似于合同法，当流程正常时是压箱底用不到的，当流程出现争端，才需要用合同的条约解决问题。其实理解ACID，用结婚这个现实中的例子更容易理解。严谨一些，以中国的《婚姻法》为例。
原子性-A：最开始两个人的状态都是【未婚】，领到结婚证的一刻，两个人的状态都变成了【已婚】。 两个人的状态是绑定在一起的。
一致性-C：两个人的状态都从【未婚】变成了【已婚】。这里隐藏了一致性的约束：男方只能有一个现任妻子，女方只能有一个现任丈夫。 如同数据库唯一索引的约束一样。
隔离型-I：两个结婚跟别人无关，不影响其他扯证的情侣。
持久性-D：除非离婚，不然婚姻状态是持续的。
事务的隔离性由锁机制实现，原子性、一致性和持久性由事务的日志保障。
理解了基础概念，我们来做思想实验。假如我们的业务流程因为代码Bug(比如除0)中断了，如何保障数据库一致性约束呢？即我们的异常处理终极目的是保障数据库中状态的一致性，确保系统符合业务规范要求。
undo日志
如果状态异常了，恢复现场就OK了。比如驾校练车，那就是一遍一遍地roll back。我们通过undo日志记录事务变更前的状态，如果当前事务处理异常，回滚到原来的状态，就像这个事情没有发生一样。用T代表事务，X代表事务变更的元素，v代表X原来的值。那么<T,X,v>就是日志记录的三个必要字段。 例如：<发工资,张三, 0> 代表发工资前，月光族张三的银行卡上没有钱了。
系统处理事务中会有如下关键日志信息：
日志<START T> 表示一个事务的开始。
日志<COMMIT T>表示一个事务的提交，日志<ABORT T>表示一个事务中止。对于一个事务，<COMMIT T>和<ABORT T>只会记录一条。
一个事务的处理流程如下：
S1：记录<START T>表示开启一个事务。
S2：记录undo日志：<T,X,v>，表示事务元素变更前的状态。（要求持久化）
S3：改变X元素，使其状态变更。（要求持久化）
S4：记录<COMMIT T>,表示事务提交。
当系统出现故障，暂停提供服务并启动故障修复程序。
S1: 反向遍历日志，对于已经有<COMMIT T>的事务，无需处理。
S2：对于没有<COMMIT T>的事务，用undo日志将事务恢复到变更前的状态。
注意，故障修复的每个操作，又构成了新的事务。
Undo日志修复流程就引发了两个概念：检查点(checkpoint)和幂等(idompotent)。
检查点：由于系统故障概率一般较低，导致积累的日志规模庞大。如果遍历整个历史日志，故障修复的效率就太低了。所以用检查点机制来记录系统无故障的里程牌。如果出现故障，修复程序回滚到里程碑处就可以停止了。
幂等：如果故障修复时候，也出故障了。怎么办？确保日志修复的操作是幂等的。有了这个限制，重试就解决问题了。 所谓幂等，执行一次和执行多次结果是一样的。《事务处理概念与技术》中，有个非常形象的例子：
“把核反应堆的反应棒向下移动2cm”就是非幂等的，
“把核反应堆得反应棒移动到xx位置”就是幂等的。
Redo日志
使用undo日志，会引发性能问题。即事务改变的数据写到磁盘前，不能提交该事务。这就意味着，没笔事务操作都至少有3次磁盘操作。所谓按下葫芦浮起瓢。必须有一种新的机制，这就是Redo日志的来源。
如果说Undo日志代表一种消极的人生态度，Redo日志就是一种积极的人生态度。颇有不破楼兰终不还的气势。即如果系统出现故障，由于我们已经记录了我们要到达的终点，那么失败重试就可以了，退什么退！
类似于undo日志，redo日志记录事务<T,X,v>代表事务T改变元素X的值为v，v就是新值。
使用redo日志的事务流程如下：
S1：记录<START T>表示开启一个事务。
S2：记录redo日志：<T,X,v>，表示事务元素变更前的状态。（要求持久化）
S3：记录<COMMIT T>,表示事务提交。（要求持久化）
S4：改变X元素，使其状态变更。
相比undo日志，COMMIT T提前了。这样的话，事务是否完成依然是检查日志中有没有COMMIT信息，但是这个流程已经不能保障有COMMIT的事务数据固化到硬盘了。这就要求检查点生成时，必须保证数据已经落盘。
故障修复流程也是相当简单：
S1: 找出所有已经COMMIT的事务
S2：使用redo日志重新执行原事务的操作
Undo/Redo日志
Redo日志要求在事务提交和日志记录刷新前，将所有修改过的块保留在缓冲区中，这样可能增加事务需要的平均缓冲区数量。而且，如果数据库元素不是完整的块，undo日志和redo日志在检查点过程中，对于如何处理缓冲区都存在矛盾。所以新的方案由出炉了，就是undo/redo综合体，颇有要你命三千的意味。即记录日志的时候，记录<T,X,v,w>4个值，代表事务T改变了元素X，x的旧值是v,新值是w。
使用undo/redo日志的事务流程如下：
S1：记录<START T>表示开启一个事务。
S2：记录undo/redo日志：<T,X,v,w>，事务T改变了元素X，x的旧值是v,新值是w。（要求持久化）
S3：修改数据库元素
S4：记录<COMMIT T>日志。
这里S3和S4并没有明确顺序要求。
这里就可以根据当前缓冲区的状态灵活控制了，<COMMIT T>的修改数据库元素的操作谁先谁后已经不重要了。
故障恢复：
S1: 遍历日志
S2：对于已经COMMIT的事务，使用redo重做
S3：对于没有COMMIT的事务，使用undo回滚
后续
本文简单总结了事务、ACID的理解方式。从思想原理上梳理了undo、redo、undo/redo机制的演变过程，也梳理了检查点和幂等两个概念的来源。后续将分析MySQL, ES等数据库的日志实现，结合实际了解其在工业产品中的落地姿势。
参考
《事务处理概念与技术》
《数据库系统实现》
内容总结
以上是互联网集市为您收集整理的理解数据库日志进行故障修复的原理全部内容，希望文章能够帮你解决理解数据库日志进行故障修复的原理所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。