20.14.2 消息存储启动和恢复

消息存储数据由邮件、索引数据和消息存储数据库组成。虽然此数据相当可靠，在极少时候系统中也可能出现消息存储数据问题。这些问题将在默认日志文件中指出，并且几乎始终透明地被修复。在极少情况下，日志文件中的错误消息可能会指出您需要运行 reconstruct 实用程序。 此外，作为最后的手段，邮件将由20.12 备份并恢复消息存储中所述的备份和恢复进程保护。本节将着重说明 stored 的自动启动和恢复进程。

消息存储自动执行许多恢复操作，这以前是管理员的职责。启动期间，消息存储守护进程 stored 将执行这些操作，包括数据库快照和必要时的自动快速恢复。stored 将彻底检查消息存储的数据库并在检测到问题时自动启动修复。

stored 还通过默认日志的状态消息提供数据库状态的综合分析，报告对消息存储完成的修复和使其运行的自动尝试。

20.14.2.1 自动启动和恢复—操作原理

stored 守护进程在其他消息存储进程之前启动。如果有必要，它将初始化并恢复消息存储数据库。消息存储数据库可保存文件夹、配额、订阅和邮件标志信息。数据库可以进行日志记录和处理事务，因此已经内置了恢复。此外，某些数据库信息将在每个文件夹的邮件索引区域中大量地被复制。

尽管数据库相当可靠，但在极少情况下也会中断。在大多数情况下，stored 可以透明地恢复和修复数据库。但是，无论何时重新启动 stored，都应检查默认日志文件以确保不需要其他管理介入。如果数据库需要进一步重建，日志文件中的状态消息将提醒您运行 reconstruct。

打开消息存储数据库前，stored 将分析其完整性，并将状态消息发送到警告类别下的默认日志。某些邮件将对管理员很有用，某些邮件将由用于内部分析的编码数据组成。如果 stored 检测到任何问题，则将尝试修复数据库并尝试再次启动数据库。

打开数据库时，stored 将以信号表明其余服务可以启动。如果自动修复失败，默认日志中的消息将指定要采取的措施。请参见表示需要 reconstruct 的错误消息。

在以前的版本中，stored 可能会花费很长时间启动恢复进程，致使管理员怀疑 stored 是否已被“阻塞”。这种长时间的恢复现在已不存在，stored 将在一分钟内确定最终状态。但是，如果 stored 需要使用恢复技术（例如从快照恢复），则进程可能会花费几分钟时间。

大多数恢复之后，数据库通常会更新，并且不需要进行任何其他操作。但是，某些恢复需要 reconstruct -m 以便与消息存储中的冗余数据同步。同样，这会在默认日志中说明，因此启动后监视默认日志非常重要。即使消息存储看起来启动和运行正常，运行任何要求的操作（例如 reconstruct）都是很重要的。

阅读日志文件的另一个原因是可以首先确定导致数据库损坏的原因。尽管 stored 用于调出消息存储，而不管系统中的任何问题，但是您仍要尝试确定导致数据库损坏的原因，因为这可能是更大的隐藏问题的征兆。

表示需要 reconstruct 的错误消息

本节介绍需要运行 reconstruct 的错误消息类型。

错误消息指示邮箱错误时，运行 reconstruct <mailbox>。示例：

“邮箱 user/joe/INBOX 中的邮件 102 的高速缓存数据无效。需要重建”

“邮箱已破坏，缺少固定标题: user/joe/INBOX”

“邮箱已破坏，start_offset 在 EOF: user/joe/INBOX 之外”

当错误消息指示数据库错误时，请运行 reconstruct -m。示例：

“正在删除附加数据库日志。请在启动后立即运行 reconstruct -m 以再同步冗余数据”

“正在从快照恢复数据库。请在启动后立即运行 reconstruct -m 以再同步冗余数据”

数据库快照

快照是数据库的热备份，由 stored 使用以在几分钟内透明地恢复已损坏的数据库。这比使用 reconstruct 要快得多，后者依赖于其他区域中存储的冗余信息。

消息存储数据库快照—操作原理

默认情况下，每 24 小时自动获取一次数据库（位于 mboxlist 目录中）的快照。默认情况下，快照将被复制到 store 目录的子目录中。默认情况下，在任意给定时间有五个快照：一个实时数据库、三个快照和一个数据库/已删除副本。数据库/已删除副本比较新，并且是放入 mboxlist 数据库目录的子目录 removed 中的数据库的紧急副本。

如果恢复进程由于确定数据库已损坏而决定删除当前数据库，stored 会将其移入 removed 目录（如果可以）。此操作允许在需要时对数据库进行分析。

数据移动一周仅发生一次。如果已存在数据库的副本，stored 将不会在每次进行存储时替换副本。仅当 removed 目录中的数据是一星期以前的数据时，才会替换副本。这将防止有问题的原始数据库由于连续启动而被替换得太快。

指定消息存储数据库快照的时间间隔和位置

应有五倍的空间用于组合的数据库和快照。强烈建议管理员重新配置快照以在单独的磁盘上运行，并调节快照以满足系统需求。

如果 stored 在启动时检测到数据库的问题，最好的快照将自动被恢复。有三个快照变量，可以设置以下参数：快照文件的位置、获取快照的时间间隔、保存的快照数量。表 20–13 显示了这些 configutil 参数。

获取快照时间间隔太小将会导致给系统带来频繁的负担，并更有可能会将数据库中的问题复制为快照。获取快照时间间隔太大意味着获取快照时数据库要保持过去的状态。

建议采用一天的快照时间间隔，如果问题将在系统中保存若干天，并且您希望返回问题存在的时间点以前的时段，则一周或更长的快照时间间隔会很有用。

stored 可以监视数据库并且非常智能，如果检测到数据库不够完好，则拒绝最新快照。而将检索最新、最可靠的快照。尽管快照可能是从一天以前检索的，系统将使用更新的冗余数据并覆盖较早的快照数据（如果可用）。

因此，快照所起的最终作用是使系统接近最新，并尝试在运行中重建数据来减轻系统剩余部分的负担。

表 20–13 消息存储数据库快照参数

参数	说明
local.store.snapshotpath	消息存储数据库快照文件的位置。或者是现有绝对路径，或者是 store 目录的相对路径。 默认值：dbdata/snapshots
local.store.snapshotinterval	快照之间的分钟数。有效值：1 - 46080  默认值：1440（1440 分钟 = 1 天）
local.store.snapshotdirs	保存的不同快照的数量。有效值：2 -367  默认值：3