数据库异常数据恢复（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的大小