本文介绍了SinoDB服务器上可能发生的故障类型，描述了快速恢复过程，介绍如何检查 chunk 和 dbspace 的状态以及如何识别与恢复相关的配置参数。
1. 系统故障的类型
SinoDB数据库服务器用于系统恢复的机制有以下几种：
- 快速恢复
- 磁盘镜像
- 从归档中恢复
- 数据复制
以下是一些可能出现的系统故障的类型，以及对应的可能采用的系统恢复：
-
系统崩溃——如果因电源故障或其他原因计算机系统宕机，数据库服务器必须在重启电脑系统后快速恢复到一致的状态。快速恢复就用于此目的。
-
磁盘崩溃——如果由于任何原因，导致包含服务器数据的磁盘变得不可用，必须有一种方法能将磁盘上的数据恢复到一个一致的状态。你可以从归档中进行复原，并且前滚逻辑日志来将系统退回到磁盘变得不可用时那个状态。如果磁盘是镜像的，任何原因导致的磁盘故障，服务器会继续运行且不受影响。
-
系统故障——在系统完全崩溃时，数据复制提供一个辅助数据库服务器作为立即可用的备份系统。
2. 快速恢复
快速恢复是指任何时候服务器的运行模式从脱机切换到静默模式时的自动的、容错的功能。
快速恢复将实现两个目标：
- 使用物理日志将服务器返回到最近、已知的物理一致状态：即最近的检查点
- 使用逻辑日志将服务器返回到逻辑一致状态，即通过前滚自检查点以来发生的所有事务，并且回滚所有未被提交的事务
快速恢复是使服务器从断电或操作系统故障等造成的系统崩溃中快速恢复过来的一个功能。但它不能为介质故障提供恢复机制（如磁盘崩溃）。
快速恢复首先将系统恢复到最近的、已知的物理一致状态，即最近的系统检查点的位置。然后，它会执行逻辑日志中自最近检查点之后的所有事务。最后，再回滚所有在故障发生时未提交的事务。最终使数据库处于一个一致状态，这个状态与故障发生时活动事务的完成是相关的。
无法停用快速恢复过程;每当数据库服务器启动时，都会自动进行快速恢复。
2.1 正常关机时的系统状态
如果服务器可在控的方式下，通过使用 onmode进行系统关机，则关机前的最后一项将会执行检查点操作。这意味着将物理日志清空，以及逻辑日志的最后一条记录是检查点记录。
在正常关机后，系统消息日志中的最后一个条目将指出服务器停止的时间。
2.2 崩溃后的系统状态
在系统故障的事件中，检查点不是服务器宕机前发生的最后一个事件。这样，物理日志就不会被清空，且逻辑日志中的最后一条记录也不是检查点记录。在某些罕见的情况下，逻辑日志可能有一个断言失败（assertion failure）的条目。在这些情况下，当将服务器重新启动时，快速恢复进程都会运行。
如果消息日志最后一个条目没有指出服务器 stop 的消息，那么系统就不是以受控的方式关闭的。则服务器重新启动时，就需要快速恢复功能来复原服务器。
2.3 快速恢复
快速恢复通过以下面两个阶段来完成：
- 数据库服务器使用物理日志返回到最近已知的物理一致点：最近的检查点。
- 数据库服务器使用逻辑日志来返回到逻辑一致状态，即通过前滚最近检查点之后发生的所有已提交的事务，并且回滚所有未完成的事务。
快速恢复的工作方式，取决于上一检查点是完全检查点还是模糊检查点。这一小节讨论完全检查点后的快速恢复。
快速恢复：步骤1
快速恢复过程的第一步是读取物理日志文件。（超出指向最后一个检查点后第一页的指针），则完成快速恢复的第一步。如果物理日志中存在新条目，则需要下面操作。
从物理日志中恢复前映像页
为了继续恢复过程的第一步，读取物理日志中所有前映像，并将这些映像页写回它们在磁盘上本来的地址上。这可以确保磁盘上的数据可以反映出上次检查点时所处理的页面的状态。这项任务通过先读取物理日志中的所有前映像到共享内存中，然后执行检查点操作来完成的。这是恢复这些页面最有效的方法，因为它允许页清除程序来写这些数据。
当所有物理日志中的前映像都处理完时，快速恢复机制的第一步就完成了。
这个 undoing 是必要的，因为共享内存缓冲池中的已修改页可能在检查点发生之前就被刷新到磁盘上了。这确保了发生的前滚过程对处于其原始状态的数据起作用。
快速恢复：步骤2
快速恢复机制的下一步是在逻辑日志中定位最后一个检查点记录。这条记录位置的地址可以在系统保留页中找到。
快速恢复：步骤3
找到检查点记录后，将逻辑日志该点后的所有事务都进行前滚，就是重新执行该检查点以后对数据库的所有修改。
若逻辑日志中自最后的检查点以后的所有条目都完成了重现，那么快速恢复的第三步就完成了
快速恢复：步骤4
快速恢复机制中的第四步是回滚任何没有提交的事务或回退在逻辑日志中所有与之相关的工作。这将确保在系统故障时仍未完成的事务不会保留在系统内。所有含 COMMIT 或 ROLLBACK WORK语句的事务都将得到保留。
为了执行完整的回滚，必须越过检查点记录往回读取整个逻辑日志（在一个事务周期内可能会发生几个检查点）。
当这个快速恢复的第四步完成后，所有已经提交的事务都会被恢复，并所有未完成（没有提交)的事务都被撤销掉，系统启动过程可以继续进行，服务器将处于静默模式中。
2.4 快速恢复之后的系统状态
-
带有日志的数据库:
当完成快速恢复时，所有完成的事务都被复原；所有不完整的事务将回滚，使数据库处于一致性状态。 -
不带日志的数据库：
若未使用事务日志，则仅会执行步骤 1。数据库将复原至最后一个检查点的状态。
快速恢复机制完成时，所有在系统故障时已完成的事务将会得到恢复。所有在系统故障时未完成的事务将被回滚。这确保数据库恢复至完全的完整状态。
有缓冲日志的数据库
须要知道的是快速恢复仅能恢复在逻辑日志中所记录的事务。若启用了缓冲日志，则已经提交事务的事务记录有可能并未被写至磁盘（而可能是还在日志缓冲区内）。那么，系统故障时仍处于日志缓冲区的所有事务均会丢失。因此，在快速恢复机制中，有可能无法恢复应用认为已提交的所有事务。
不带日志的数据库
如果数据库未使用事务日志，则用于前滚过程所需的逻辑日志中没有任何事务记录。若系统故障时事务日志未启用，则当系统重启并进行快速恢复时，只会将系统复原至最后的检查点状态。由于逻辑日志中不含有数据库的事务，因此，快速恢复的第二步以及之后的步骤无法应用于数据库。换言之，在最后的检查点之后、所有对无日志的数据库的改动均会丢失。
2.5 快速恢复后的信息日志
快速恢复发生时，不同步骤的完成状态将被记录在服务器日志文件中。
- Physical Recovery Complete：指的是快速恢复第一步已完成，表示从物理日志中复原了多少个前映像。
- Logical Recovery Complete：指的是第二步与第三步已完成，代表已恢复和确认的、回滚的、以及仍处于打开状态的、无法获取所需锁（Open 和 Bad Locks 信息仅适用分布服务器的环境中）的事务的数量。无法从该信息中确切得知已恢复的事务和已回滚的事务。若需要找到该信息，则可使用 onlog 实用程序寻找所涉及的事务。
2.6 恢复时间目标
- onconfig配置参数：RTO_SERVER_RESTART
- 设置为 60 到 1800 秒（1–30 分钟）以指定允许快速恢复的目标时间
- 服务器自动监控当前工作负载并调整检查点频率以满足 RTO 策略
- 每次快速恢复时对服务器进行微调，以提高可预测性
- 使用onmode -wm或-wf对参数进行动态更新
- 想要关闭的话，设置RTO_SERVER_RESTART为0
– 禁用自动检查点频率
– 使用 CKPTINTVL 设置触发检查点
为了帮助提高快速恢复期间的性能，您可以设置RTO_SERVER_RESTART配置参数。此参数可用于设置目标恢复时间目标 （RTO） 以实现快速恢复。根据参数设置，服务器监视工作负载并调整检查点的频率，以满足定义的 RTO 策略。每次服务器进行快速恢复时，它都能够更好地预测最符合策略的频率。
默认情况下，RTO_SERVER_RESTART参数处于禁用状态，CKPTINTVL 参数确定检查点频率。如果启用了 CKPTINTVL，则会忽略RTO_SERVER_RESTART。
物理日志、逻辑日志和缓冲池必须足够大，以容纳所有将在RTO_SERVER_RESTART时间段内发生的更新。如果物理日志或逻辑日志空间太小，则会触发检查点，因为日志资源的使用速度过快，而不是因为 RTO 策略。太小的缓冲池也会导致恢复速度变慢，因为磁盘刷新更频繁地发生，从而导致 I/O 调用增加。
3. 带镜像的介质故障及恢复
3.1 带镜像的介质故障
当使用镜像时，若主 chunk 遇到 I/O 错误，服务器会自动切换至镜像 chunk。从寻找、读取或写入调用所返回的 I/O 错误会导致一个 chunk 被标记为脱机（在标记 chunk 为脱机（down）之前，服务器会再次尝试执行相关操作以确认存在错误）。
指明 chunk 为脱机的信息将会写入信息日志文件中。在 dbspace 和 chunk 的 onstat 输出中，chunk 标记为脱机表示该 chunk 出现了问题。管理员应修复 chunk 设备并启动恢复过程。一个脱机的 chunk 无法自动恢复，管理员必须干预。
由 onstat -d 命令输出的 chunk 报告中，标记列显示 -PO（Primary/Online）表示主 chunk 是联机状态。标记列中的 -PD（Primary/Down）表示一个 chunk 为脱机状态。对正在从镜像 chunk 复原过程中的主 chunk，状态为 -PR（Primary/Recovery)）。若主 chunk 从备份中物理上而非逻辑上复原过来了，则标记为 -PI（Primary/Inconsistent)。镜像 chunk 的标记通常为 -MO （Mirror/Online）、或-MD （Mirror/Down）、或 -MR(Mirror/Recovery)。
若主 chunk 和镜像 chunk 都遇到了 I/O 错误，或者当没有对 dbspace 或 blobspace 激活镜像而主 chunk 遇到 I/O 错误时，相应的 chunk 会被标记为脱机。这时若使系统脱机、再重新上线，则服务器可能会初始化失败。如果此脱机的 chunk 是属于一个重要的 dbspace（根dbspace，或包含逻辑日志、物理日志的 dbspace），则服务器就无法初始化。要想启动服务器，就必须修复 chunk 设备，然后从备份中恢复系统。若有不重要的 dbspace 包含了脱机的主 chunk，则启动服务器到 Online 模式是有可能的。但是，仍无法访问含有脱机 chunk 的 dbspace。一旦 chunk 设备修复完毕，可以在服务器处于联机模式时恢复这些 dbspace。以上称之为热恢复（warm restore），在后续模块中会继续讨论。
3.2 镜像 chunk 的恢复
当一个镜像（或主）chunk 恢复后，或当启动 dbspace 或 blobspace 的镜像时，则发生镜像（或主）chunk 的恢复。这样的恢复是将一对主/镜像 chunk 中的其中一个的内容复制至另一个的过程。
在恢复时，会对主/镜像两个 chunk 开始双重写入（即，服务器会写入至这两个 chunk）。同时，从主 chunk 的所有页复制至镜像 chunk。该动作允许同时写入至主 chunk 以及镜像 chunk，而且，此时镜像 chunk 开始与主 chunk 同步。
使用 onspaces 命令启动一个脱机的主 chunk 或镜像 chunk 的恢复。
onspaces -s spacename -p pathname -o offset -O
其中：
spacename 为 dbspace、blobspace、或 sbspace 的名字。
当创建一个带镜像的 dbspace 或 blobspace 时，恢复几乎是瞬时的。而对现有空间的恢复时间则取决于空间的大小
3.3 ONDBSPACEDOWN
ONDBSPACEDOWN 是一个配置参数，决定了当遇到 I/O 错误时，服务器会采用何种动作。
| 值 | 说明 |
|---|---|
| 0 = 继续 | 所有不包含rootdbs、逻辑日志或物理日志的chunk都标记为脱机。 |
| 1 = 停止 | 在任何情况下均停止(关闭)服务器。 |
| 2 = 等待 | 缺省值。所有正在更新的线程均在下一个检查点时挂起。服务器继续轮询产生 I/O 错误的chunk。 |
可通过设置 ONEDBSPACEDOWN 配置参数来定义服务器在检测到 I/O 错误时所采取的动作。
在任何情况下，若 I/O 错误是由包含一部分根 dbspace 或物理日志或逻辑日志的存储块，则停止服务器。
当接收到 I/O 错误时， ONDBSPACEDOWN 设置为 2，服务器继续轮询产生 I/O 错误的 chunk。在
下一个检查点出现时，若问题可以解决，则在不更多干预的情况下，可以继续处理。若在问题解决之前接到检查点请求，则所有线程均在服务器上挂起。若发生上述情况，管理员可做如下处理：
- 修复 chunk 设备，然后将服务器关闭再重启。服务器再次打开后，将 chunk 标记为联机。
- 标记 chunk 为脱机，允许线程继续在服务器上进行处理。需要用到的命令为 onmode -O。
当磁盘设备无法恢复时可使用该命令。当设备被替换后，执行一个 dbspace 的热复原操作。
关于恢复镜像chunk的附加信息，请参阅SinoDB管理员指南里的使用镜像一 节。
使用 ONDBSPACEDOWN 配置参数的附加信息可以在SinoDB管理员指南的数据库服务器配置一 章的 ONDBSPACEDOWN 一节中查找。