前往小程序,Get更优阅读体验!
立即前往
发布
社区首页 >专栏 >数据库的故障恢复

数据库的故障恢复

原创
作者头像
潋湄
修改2024-12-11 09:29:10
修改2024-12-11 09:29:10
2260
举报
文章被收录于专栏:数据库数据库

推荐一篇优质文章:https://cloud.tencent.com/developer/article/2474322?policyId=20240001&traceId=01jesmy38j9nrp142z5gzy1vqt 这篇文章细致讲解了数据库中的redolog、undolog以及binlog的作用,能够让我们对于数据库的日志有充分的认识

在经历了一段时间的忙碌后,终于又能抽出点时间写篇博客了,今天我们介绍一下数据库中的故障恢复,可以说,数据库中事务的ACID特性的保障有很大一部分都源于数据库的故障恢复功能,在数据库的编写代码中,有10%左右的代码都是关于故障恢复,本文旨在介绍数据库的故障恢复类型以及恢复手段

前置知识

在了解故障恢复机制之前,我们要先了解一下数据库中数据存储的运行方式,在我们执行插入或者修改语句时,表面上看我们会将数据直接写入磁盘中,但是实际上数据库中的数据交换流程如下:

数据库中的数据存储架构
数据库中的数据存储架构

我们可以看到,当客户端要写入数据到数据库中时,首先会将数据库保存在DB buffer(Database Buffer)中,也就是数据库缓存中,而真正写入到DB(磁盘)是通过持久化操作,将缓存的数据最终同步到磁盘中的,而实际上数据库进行数据处理时,由于计算机对于缓存的访问速度远远大于磁盘的访问速度,因此也会先从缓存中查找数据,如果不存在才会将数据块从磁盘中进行调入,也就是所谓的I/O操作

数据库对于数据的存取处理
数据库对于数据的存取处理

而正是因为引入了一个中间缓存层,根据计算机中程序执行的局部性原理,当程序执行时,有90%的运行程序会使用10%的运行资源,因此通过将这10%的运行资源存入缓存,我们就能加快应用程序的执行,但是引入中间缓存却也增加了我们对于数据库的故障恢复

数据库故障恢复

故障类型

数据库的故障主要有以下几个方面:

事务故障:该类型故障主要是某一个程序(事务)自身运行错误所引起的故障,它会影响该程序本身

系统故障:由于外界因素(掉电、非正常关机)引起的故障,由于事务运行时会使用到数据库缓冲区的数据,因此可能会影响正在运行的事务以及已经运行的事务

介质故障:由于介质损坏导致的故障,该类型的故障一般来说是不可逆的,介质的损坏会导致数据的丢失

故障恢复

对于不同类型的故障,数据库制定了不同的恢复策略:

事务故障恢复

由于事务故障时程序本身运行错误导致的,因此我们通过使用重做日志(Redo Log)撤销日志(Undo Log)进行解决,对此可以看我的这篇文章:https://cloud.tencent.com/developer/article/2451996

系统故障恢复

在这里我们要引入运行日志的概念:

运行日志:它是DBMS(数据库管理系统)维护的一个文件,该文件以流水方式记录了每一个事务对数据库的每一次操作及操作顺序

当事务执行对于数据库的操作时,首先会写运行日志,只有当运行日志写入成功后,才会与数据库缓冲区进行数据交换:

事务对于数据库操作的执行次序
事务对于数据库操作的执行次序

因此,当系统发生故障时,数据库便可以按照运行日志记录的事务操作顺序分情况进行处理:

发生故障时已经结束的事务:对于这种类型的事务,由于这些事务写入缓存的数据还没有持久化到磁盘中,因此我们需要重做事务(Redo Log)将缓冲区的数据写入磁盘中

发生故障时未结束的事务:这些事务在对缓冲区进行数据操作的过程中便被中断了,因此会导致缓冲区的数据发生错误,需要撤销事务(Undo Log)将对于缓冲区数据的修改撤回

通过运行日志进行系统故障恢复
通过运行日志进行系统故障恢复

但是运行日志中保存的数据是庞大的,我们如果每次都从头进行故障恢复效率缓慢,因此数据库引入了检查点,在运行日志中,检查点代表一个时刻,在这个时刻,DBMS会强制使DB Buffer中的内容与DB中保持一致,即将DB buffer更新的所有内容写回DB中,因此检查点表示这个点之前的内存数据与介质数据时保持一致的

引入检查点的系统故障恢复
引入检查点的系统故障恢复

在这个图中我们可以看出,当故障发生时,我们从检查点开始查看运行日志,在故障点前结束的事务(红色实线)就重做(Redo Log),故障点前未结束的事务进行撤销(Undo Log)

介质故障恢复

对于介质故障恢复,也就是磁盘的数据丢失,我们可以通过增加副本来恢复,这有点类似于我们在搭建数据库(MySQL、Redis)时的主从复制,我们会定期将主节点的数据同步到从节点中,如果主节点发生了宕机,我们便可以继续使用从节点保证数据的可靠性:

引入副本进行介质恢复
引入副本进行介质恢复

虽然我们引入了介质副本,但是当介质故障发生时,由于对于缓冲区影响的不确定性,我们还需要通过系统恢复查看运行日志文件来重做或者撤销事务对于介质副本的影响,而与介质存储类似,我们在介质副本中引入了转储点的概念,在转储点时刻,系统会强制将运行日志上的更改同步到备份文件中,因此当发生介质故障恢复时,我们会从运行日志的转储点开始对备份文件进行恢复:

在转储点对备份文件进行恢复
在转储点对备份文件进行恢复

至此,我们便解决了数据库中的故障恢复,数据库通过事务的撤销与重做、运行日志和备份来进行故障恢复,保证事务的原子性与一致性,提高数据库的可靠性:

好了,这就是本篇文章的全部内容了,希望对你有所帮助!!!

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 前置知识
  • 数据库故障恢复
    • 故障类型
    • 故障恢复
      • 事务故障恢复
      • 系统故障恢复
      • 介质故障恢复
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档