数据库异常数据恢复(1)-快速恢复和镜像恢复

(一) 数据库服务器的崩溃和恢复

1. 服务器的修复机制

数据库因为某些原因导致数据库突然异常donw机,为了保证数据库的使用,提供了一些机制进行数据库的恢复

  • 快速恢复:数据库异常down机后重启数据库自己的恢复方式,人工无法干预
  • 备份文件恢复:手动进行恢复的方式
  • 磁盘镜像和数据复制:都是一种灾备方式,从一定程度上可以机器自主反应保证应用的运行
    • 镜像:两个chunk,一个为主chunk,一个为镜像chunk,主chunk出现问题,会启用镜像chunk,在一定程度上可保证应用的运行
    • 数据复制:集群灾备

2. 数据库服务武器崩溃的类型和修复方式

  • 系统崩溃:因为电源或其他原因导致机器donw机,重启计算机后,数据库会通过快速恢复的机制,自动恢复
  • 磁盘崩溃:当包含数据库服务器的磁盘因为某些原因不能使用,针对这种,由于数据存放在磁盘中,只能通过备份文件恢复的方式进行恢复
  • 机器失败:如果是整个系统失败了,数据复制(HDR或RSS)提供的第二个数据库实例可以马上作为备份系统使用

(二) 数据库异常down机的表现方式和快速恢复

1. 数据库正常关闭和异常崩溃的差异

  • 正常关闭
    • 数据库正常关闭的情况下,最后一次操作是checkpoint
    • checkpoint之后物理日志会被清空
    • 逻辑日志最后一条是checkpoint
    • 消息日志包含了关闭数据库的时间
  • 异常崩溃
    • 异常关闭的数据库没有执行checkpoint
    • 物理日志没有情况
    • 逻辑日志最后一条不是checkpoint
    • 消息日志没有关闭数据库时间
    • 且数据库异常崩溃,可能会有断裂块的情况产生

2. 快速恢复概述

  • 快速恢复是数据库的一种特性,不能被认为干预,不能被关闭
  • 快速恢复只适合系统方面的异常崩溃,磁盘不可用的情况无法使用异常崩溃恢复
  • 快速恢复的目标有三个
    • 物理日志恢复:恢复到最近的检查点时间,达到物理日志恢复
    • 逻辑日志恢复:通过逻辑日志恢复到最近的逻辑一致状态
    • 事务回滚:回滚崩溃时没有完成的事务

3. 快速恢复的步骤

  • 物理日志恢复:
    • 由于异常关闭没有清空物理日志,所以将物理日志的内容读取到缓冲池内,清页线索会将内容刷新到磁盘中,刷到磁盘是为了避免出现异常down机前数据更新后脏块刷入了磁盘,但是物理日志未刷新的情况。刷新磁盘可以将磁盘的数据恢复到最后一个检查点时的状态
    • 如果物理日志中没有数据,则表示第一步已经完成
  • 逻辑日志前滚恢复到最近的逻辑性一致状态
    • 找到逻辑日志的最后一个checkpoint
    • 前滚最后一个checkpoint之后的所有操作记录
  • 回滚没有递交的事务或者系统失败时没有完成的事务
    • 回滚在逻辑日志中没有commit和rollback work配对的事务
    • 这样保证数据库内不会留下那些失败没有完成的事务

4. 快速恢复对记录日志开启缓冲和不记录日志两种数据库的差异

  • 数据库开启了日志缓冲:由于数据库开启了缓冲,可能出现日志没有刷新到逻辑日志文件中,但是还存在日志缓冲区的情况
    • 这种情况下:还在逻辑日志缓冲区的事务将丢失
    • 针对开启了日志缓冲的数据库,快速恢复无法保证完全恢复
  • 不记录日志的数据库:不会将数据库的操作记录保存记录到逻辑日志中
    • 其最后一次检查点之后的所有事务和操作都丢失

5. 快速恢复后消息日志中的记录

  • 第一步恢复之后记录Physical Recovery Complete的信息
  • 第二步恢复之后记录Logical Recovery Complete的信息
  • 还会记录提交了多少事务、回滚的事务、仍然打开的锁的当前数量
  • onlog可以详细分析

(三) 镜像崩溃和恢复

1. 镜像情况下主primary chunk和镜像Mchunk的状态


[gbasedbt@iZ2ze2nmdlhki0ezcrioayZ node4_dbs]$ onstat -d
Your evaluation license will expire on 2025-03-15 00:00:00
On-Line -- Up 00:02:01 -- 676080 Kbytes

Dbspaces
address          number   flags      fchunk   nchunks  pgsize   flags    owner    name
472a8028         1        0x70002    1        1        2048     M  BA    gbasedbt rootdbs
4a899888         2        0x60001    2        1        2048     N  BA    gbasedbt llogdbs
4a899ab8         3        0x70001    3        1        2048     N  BA    gbasedbt plogdbs
4a899ce8         4        0x68001    4        1        2048     N SBA    gbasedbt sbspace1
4a9b7028         5        0x42001    5        1        16384    N TBA    gbasedbt tmpdbs1
4a9b7258         6        0x60001    6        1        16384    N  BA    gbasedbt datadbs1
4add9028         7        0x60002    7        1        16384    M  BA    gbasedbt db1dbs
 7 active, 2047 maximum

Chunks
address          chunk/dbs     offset     size       free       bpages     flags pathname
472a8258         1      1      0          102400     86165                 PO-B-D /home/gbasedbt/gbase/node4_dbs/rootdbs
472a9028         1      1      0          102400     0                     MD-B-- /home/gbasedbt/gbase/node4_dbs/rootdbs_mirror
4a9b7488         2      2      0          51200      1147                  PO-B-D /home/gbasedbt/gbase/node4_dbs/llogdbs
4a9b9028         3      3      0          51200      1447                  PO-B-D /home/gbasedbt/gbase/node4_dbs/plogdbs
4a9ba028         4      4      0          51200      47678      47678      POSB-D /home/gbasedbt/gbase/node4_dbs/sbspace1
                                 Metadata 3469       2581       3469
4a9bb028         5      5      0          6400       6347                  PO-B-- /home/gbasedbt/gbase/node4_dbs/tmpdbs1
4a9bc028         6      6      0          64000      63413                 PO-BED /home/gbasedbt/gbase/node4_dbs/datadbs1_1
4add9258         7      7      0          6250       6197                  PO-B-D /home/gbasedbt/gbase/node4_dbs/db1
4ab5c028         7      7      75000      6250       0                     MO-B-D /home/gbasedbt/gbase/node4_dbs/db1_mirror
 7 active, 32766 maximum

NOTE: The values in the "size" and "free" columns for DBspace chunks are
      displayed in terms of "pgsize" of the DBspace to which they belong.


Expanded chunk capacity mode: always
  • 镜像功能需要在数据库初始化时进行配置
  • 从上可以看出带有镜像功能的onstat -d和不带有镜像功能的onstat -d在flags列有着很大的差异
  • flags参数含义
    • primary主chunk
      • PO(Primary/Online):在线
      • PD(Primary/Down):down机
      • PR(Primary/Recovery):正在从镜像恢复
      • PI(Primary/Inconsistent):已经从镜像chunk恢复,但是没有逻辑恢复
    • 镜像chunk:
      • MO:在线
      • MD:donw机状态
      • MR:正在恢复

2. 带有镜像的chunk异常的后果

  • 如果primary chunk和镜像Mchunk都遇到了IO错误,或者primarychunk遇到了IO错误但是没有使用镜像,会显示离线
  • 如果离线的数据库是关键数据库,则数据库重启会失败
  • 如果离线的数据空间时非关键数据空间,启动会成功但是需要修复离线的chunk空间
  • 离线的chunk不会自动恢复,需要人工介入

3. 关于镜像chunk出现io错误时的相关参数ONDBSPACEDOWN

  • ONDBSPACEDOWN
    • 0:设备:标记为离线然后继续运行
    • 1:关闭数据库
    • 2:挂起所有的更新操作,直到下次检查点
  • 如果IO出现错误的chunk是关键chunk,只能进行关闭
  • 如果设置为2,服务器会继续检查产产生IO错误的chunk,如果在下次checkpoint时问题已经纠正,则不需要干预,数据库处理会恢复;如果没有恢复,则所有的线索都会挂起

4. chunk出现IO错误的一般处理方式

  • 修复chunk设备,关闭数据库并重启,数据库启动成功,chunk会变成在线状态
  • 把chunk标记为离线,挂起的线索会继续运行,可以通过onmode -o实现
    • onmode -o不能在磁盘设备不能恢复时使用,当替换了新磁盘,需要dbspace的热恢复

5. 镜像chunk恢复失败的chunk的命令

  • 针对出现问题的chunk使用镜像恢复如下
    • 实际上是把其中一个chunk的信息恢复到另一个chunk中
onspaces -s 失效的dbs -p 失效的chunk路径 -o 0 -O
  • 当恢复的dbs是blobdbs时,恢复是瞬间的
  • 当针对已经存在的dbspace增加镜像时,时间取决于dbspace的大小
  • 15
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值