Sun Java System Messaging Server 6 2005Q4 管理指南

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

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

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

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

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

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

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

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

表示需要 reconstruct -m 的错误消息

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

错误消息指示邮箱错误时,运行 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 在启动时检测到数据库的问题,最好的快照将自动被恢复。有三个快照变量,可以设置以下参数:快照文件的位置、获取快照的时间间隔、保存的快照数量。表 18–15 显示了这些 configutil 参数。

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

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

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

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

表 18–15 邮件存储数据库快照参数

参数 

说明 

local.store.snapshotpath

邮件存储数据库快照文件的位置。或者是现有绝对路径,或者是 store 目录的相对路径。

默认值:dbdata/snapshots

local.store.snapshotinterval

快照之间的分钟数。有效值:1 - 46080 

默认值:1440(1440 分钟 = 1 天) 

local.store.snapshotdirs

保存的不同快照的数量。有效值:2 -367 

默认值:3