数据库恢复技术

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 数据库恢复技术

1.事务:

是用户定义的一个数据库操作序列,是一个不可分割的工作单位(原子性) 一般的,一个程序中被包含多个事务。

2.事务的特性:(ACID)

  • 原子性:事务中的操作要么都做,要么都不做
  • 一致性:事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
  • 隔离性:一个事物的执行不能被其他事务干扰,并发执行的各个事务之间不能互相干扰
  • 持续性:一个事务一旦提交,它对数据库中数据的改变就应该是永久性的

3.破环ACID的可能:

  • 多个事务并发运行时,不同事务的操作交叉执行
  • 事务在运行过程中被强行停止

4.数据库恢复:

把数据库从错误状态恢复到某一已知的正确状态。

5.故障的分类:

  • 事物内部的故障:只影响这个事物本身,一般是非预期的,如运算溢出、因为死锁被撤销等,解决方法是强行回滚。
  • 称为事务撤销系统故障(软故障):造成系统停止运转的任何事件,使得系统重新启动。影响正在运行的所有事务,但不破坏数据库。
  • 介质故障(硬故障):指外存故障,如磁盘损坏
  • 计算机病毒

6.数据库恢复技术的实现:

建立冗余文件(后援副本)、登记日志文件。

7.数据转储:

  • 静态转储:系统中无运行事务时进行的转储,转储期间不允许任何事务执行。 优点:得到的一定是一个数据一致性的副本 缺点:降低了数据库的可用性
  • 动态转储:转储和用户事务可以并发执行 优点:系统可用性较好 缺点:转储得到的副本不一定一致,因此必须建立日志文件等级转储期间各事务对数据库的修改活动
  • 海量转储:每次转储整个数据库,恢复更方便
  • 增量转储:每次只转储上一次转储后更新过的数据,恢复较复杂

7.登记日志文件:

用来记录事务对数据库操作的文件。

8.登记日志文件主要记录啥?

  • 事务的开始。
  • 事务的结束。
  • 事务的操作。
  • 事务的标识。
  • 事务的操作对象。
  • 事务的操作类型。
  • 操作对象之前的值。
  • 操作对象之后的值。

9.登记日志文件原则:

  • 按事务的执行的时间顺序记录
  • 先记录在执行

10.恢复策略:

事务内部故障:

  • 1.反向扫描日志文件
  • 2.对所有操作进行逆操作。
  • 3.如此反复直到读到事务开始标记。

系统故障:

  • 1.正向扫描日志文件。
  • 2.对所有在故障发生前已经commit的事务加入REDO-LIST(重做队列)
  • 3.对所有没有commit标记的事务加入UNDO-LIST(撤销队列)

介质故障:

  • 1.引入最新的登记日志文件以及最新的数据库后援副本
  • 2.重复系统故障的操作(重做已完成,撤销未完成)

11.检查点技术: 我们知道数据库恢复子系统在恢复数据库时。需要扫描日志文件以及对事务进行重做或者撤销。因此,如果每次都要重新操作,每次都要扫描全部的日志文件。很浪费时间。为了解决这个文件,检查点技术应运而生。

12.检查点技术记录的内容:

  • 1.建立检查点时所有正在执行的事务。
  • 2.记录的事务中最近的日志文件地址。

13.动态维护日志文件的方法:

周期的执行、建立检查点,保存数据库状态的操作。

14.动态维护日志文件的具体步骤:

  • 1.将日志缓冲区的所有日志记录写入磁盘的日志文件。
  • 2.在日志文件中写入检查点。
  • 3.将数据缓冲区的数据写入磁盘。
  • 4.将检查点记录在日志文件的地址写入一个重新开始文件。

15.具有检查点记录的数据库恢复步骤:

  • 1.在重新开始文件中找到最后一个检查点记录的文件地址。由该地址在日志文件中找到最后一个检查点。
  • 2.获取最后一个检查点的全部事务记录。
  • 3.建立UNDO-LIST以及REDO-LIST队列。
  • 4.由检查点开始正向扫描日志文件。(将所有事务放入UNDO-LIST,如果存在事务提交,则从把该事务从UNDO-LIST移入REDO-LIST)
  • 5.REDO-LIST的所有事务操作重做。UNDO-LIST的所有事务操作撤销。

16.数据库镜像:

由数据库自动COPY数据保存在另外的磁盘中。一旦出现介质故障则用数据库镜像继续使用。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
10天前
|
存储 NoSQL 关系型数据库
非关系型数据库-MongoDB技术(二)
非关系型数据库-MongoDB技术(二)
|
10天前
|
NoSQL 关系型数据库 MongoDB
非关系型数据库-MongoDB技术(一)
非关系型数据库-MongoDB技术(一)
|
2月前
|
Java 关系型数据库 MySQL
"解锁Java Web传奇之旅:从JDK1.8到Tomcat,再到MariaDB,一场跨越数据库的冒险安装盛宴,挑战你的技术极限!"
【8月更文挑战第19天】在Linux上搭建Java Web应用环境,需安装JDK 1.8、Tomcat及MariaDB。本指南详述了使用apt-get安装OpenJDK 1.8的方法,并验证其版本。接着下载与解压Tomcat至`/usr/local/`目录,并启动服务。最后,通过apt-get安装MariaDB,设置基本安全配置。完成这些步骤后,即可验证各组件的状态,为部署Java Web应用打下基础。
42 1
|
2月前
|
SQL Java 关系型数据库
探索Java数据库连接的奥秘:JDBC技术全攻略
探索Java数据库连接的奥秘:JDBC技术全攻略
44 8
|
2月前
|
存储 缓存 负载均衡
【PolarDB-X 技术揭秘】Lizard B+tree:揭秘分布式数据库索引优化的终极奥秘!
【8月更文挑战第25天】PolarDB-X是阿里云的一款分布式数据库产品,其核心组件Lizard B+tree针对分布式环境优化,解决了传统B+tree面临的数据分片与跨节点查询等问题。Lizard B+tree通过一致性哈希实现数据分片,确保分布式一致性;智能分区实现了负载均衡;高效的搜索算法与缓存机制降低了查询延迟;副本机制确保了系统的高可用性。此外,PolarDB-X通过自适应分支因子、缓存优化、异步写入、数据压缩和智能分片等策略进一步提升了Lizard B+tree的性能,使其能够在分布式环境下提供高性能的索引服务。这些优化不仅提高了查询速度,还确保了系统的稳定性和可靠性。
62 5
|
2月前
|
Cloud Native 数据库 开发者
云原生数据库2.0问题之帮助阿里云数据库加速技术更新如何解决
云原生数据库2.0问题之帮助阿里云数据库加速技术更新如何解决
|
2月前
|
Cloud Native 关系型数据库 分布式数据库
云原生数据库2.0问题之PolarDB利用云计算技术红利如何解决
云原生数据库2.0问题之PolarDB利用云计算技术红利如何解决
|
2月前
|
关系型数据库 OLAP 分布式数据库
揭秘Polardb与OceanBase:从OLTP到OLAP,你的业务选对数据库了吗?热点技术对比,激发你的选择好奇心!
【8月更文挑战第22天】在数据库领域,阿里巴巴的Polardb与OceanBase各具特色。Polardb采用共享存储架构,分离计算与存储,适配高并发OLTP场景,如电商交易;OceanBase利用灵活的分布式架构,优化数据分布与处理,擅长OLAP分析及大规模数据管理。选择时需考量业务特性——Polardb适合事务密集型应用,而OceanBase则为数据分析提供强大支持。
198 2
|
22天前
|
存储 负载均衡 数据库
探索后端技术:从服务器架构到数据库优化的实践之旅
在当今数字化时代,后端技术作为支撑网站和应用运行的核心,扮演着至关重要的角色。本文将带领读者深入后端技术的两大关键领域——服务器架构和数据库优化,通过实践案例揭示其背后的原理与技巧。无论是对于初学者还是经验丰富的开发者,这篇文章都将提供宝贵的见解和实用的知识,帮助读者在后端开发的道路上更进一步。
下一篇
无影云桌面