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

邮件存储故障排除

本节提供主动维护邮件存储的原则。此外，本节还介绍了当邮件存储被破坏或者意外关闭时，可以使用的其他邮件存储恢复过程。注意，有关这些附加邮件存储恢复过程的部分是修复邮箱和邮箱数据库的延伸内容。

阅读本节前，强烈建议您查阅本章以及 Sun Java System Messaging Server Administration Reference 中有关命令行实用程序和 configutil 的章节。本节涉及的主题包括：

标准邮件存储监视过程

本节概述了邮件存储的标准监视过程。这些过程有助于常规邮件存储检查、测试和标准维护。

有关其他信息，请参见监视邮件存储。

检查硬件空间

邮件存储应具有足够的附加磁盘空间和硬件资源。邮件存储接近磁盘空间和硬件空间的最大限度时，邮件存储内部可能会出现问题。

磁盘空间不足是导致邮件服务器问题和故障的最常见的原因之一。如果没有用于写入到邮件存储的空间，邮件服务器将会失败。此外，可用磁盘空间低于特定阈值时，会产生与邮件传送、日志记录等相关的问题。当 stored 进程的清除功能失败并且不从邮件存储中擦除已删除的邮件时，磁盘空间会迅速耗尽。

有关监视磁盘空间的信息，请参见监视磁盘空间和监视邮件存储。

检查日志文件

检查日志文件以确保邮件存储进程按配置运行。Messaging Server 为其支持的以下每个主要协议（或服务）都创建了一组单独的日志文件：SMTP、IMAP、POP 和 HTTP。您可以从 Console 或目录 msg_svr_base/log/ 中查看日志文件。应按例行程序监视日志文件。

请注意日志记录可能会影响服务器性能。在给定的时间内指定的日志记录越详尽日志文件所占用的磁盘空间越多。您应当为服务器定义有效且实际的日志旋转、失效和备份策略。有关为服务器定义日志记录策略的信息，请参见第 21 章，管理日志记录。

使用自动测量功能检查用户 IMAP/POP 会话

Messaging Server 提供了一种称为自动测量的功能，可以将用户的整个 IMAP、POP 或 Webmail 会话捕获到文件中。此功能对调试客户机问题很有用。例如，如果用户抱怨他们的邮件访问客户机未按预期那样工作，则此功能可用于跟踪访问客户机和 Messaging Server 之间的交互作用。

要捕获会话，只需创建以下目录：

msg_svr_base/data/telemetry/pop_or_imap/userid

Messaging Server 将在此目录中为每个会话创建一个文件。下面显示了输出示例：

LOGIN redb 2003/11/26 13:03:21
>0.017>1 OK User logged in
<0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL
>0.003>* XSERVERINFO MANAGEACCOUNTURL {67}
http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser 
MANAGELISTSURL NIL MANAGEFILTERSURL NIL
2 OK Completed
<0.046<3 select "INBOX"
>0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk)
* OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)]
* 1538 EXISTS
* 0 RECENT
* OK [UNSEEN 23]
* OK [UIDVALIDITY 1046219200]
* OK [UIDNEXT 1968]
3 OK [READ-WRITE] Completed
<0.045<4 UID fetch 1:* (FLAGS)
>0.117>* 1 FETCH (FLAGS (\Seen) UID 330)
* 2 FETCH (FLAGS (\Seen) UID 331)
* 3 FETCH (FLAGS (\Seen) UID 332)
* 4 FETCH (FLAGS (\Seen) UID 333)
* 5 FETCH (FLAGS (\Seen) UID 334)
<etc>

检查 stored 进程

stored 功能可执行各种重要任务，例如邮件数据库的死锁和事务操作、强制执行生存期策略以及擦除和删除磁盘上存储的邮件。如果 stored 停止运行，Messaging Server 最终会出现问题。如果 start-msg 运行时 stored 未启动，则其他进程也不会启动。

检查 stored 进程是否在运行。运行 stored -t -v
检查在 store_root/mboxlist 中生成的日志文件。
检查默认日志文件 msg_svr_base/log/default/default 中的 stored 邮件
检查每当 stored 进程尝试以下功能之一时，以下文件（位于目录 msg_svr_base/config/ 中）的时间戳是否已更新：

表 18–14 stored 操作


stored 操作	功能
`stored.ckp`	初始化数据库检查点时触及到该文件。大约每 1 分钟标记一次。
`stored.lcu`	每次清除数据库日志时触及该文件。大约每 5 分钟标记一次时间戳。
`stored.per`	每次产生精读用户数据库写出时触及该文件。每小时标记一次时间戳。

有关 stored 进程的更多信息，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的使用 stored 实用程序一章。

有关监视 stored 功能的其他信息，请参见监视邮件存储。

检查数据库日志文件

数据库日志文件是指 sleepycat 事务检查点操作日志文件（位于目录 store_root/mboxlist 中）。如果日志文件堆积，则不会出现数据库检查点操作。通常，单个时间段内存在两个或三个数据库日志文件。如果有更多文件，则可能是问题的征兆。

检查用户文件夹

如果要检查用户文件夹，可以运行命令 reconstruct -r -n（递归无修复），此命令将查看所有用户文件夹并报告错误。有关 reconstruct 命令的更多信息，请参见修复邮箱和邮箱数据库。

检查主存文件

仅当进程已经意外终止时才会存在核心转储文件。查阅这些文件很重要，特别是在邮件存储中发现问题时。在 Solaris 中，使用 coreadm 配置 core 文件位置。

邮件存储启动和恢复

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

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

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

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

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

修复邮箱和邮箱数据库

如果一个或多个邮箱已破坏，您可以使用 reconstruct 实用程序重建邮箱或邮箱数据库，并修复所有不一致性。

reconstruct 实用程序将重建一个或多个邮箱或主邮箱文件，并修复所有不一致性。您可以使用此实用程序恢复邮件存储中几乎所有形式的数据破坏。请参见表示需要 reconstruct -m 的错误消息

表 18–16 列出了 reconstruct 选项。有关详细的语法和使用要求，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“reconstruct”。

表 18–16 reconstruct 选项


选项	说明
`-e`	在重建之前删除 `store.exp` 文件。这将消除已删除但未被存储进程清除的邮件的所有内部存储记录。在使用 `-i` 或 `-e` 时使用 `-f` 选项也很有用，因为这些选项仅在文件夹被实际重建的情况下才工作。同样，如果使用 `-n` 选项（它执行检查而不是重建），则 `-i` 和 `-e` 选项将不工作。如果 `reconstruct` 无法检测到损坏，运行 `reconstruct -e` 将不能恢复已删除的邮件。`-f` 将强制执行重建。
`-i`	用于在重建之前将 store.idx 文件长度设置为零。在使用 `-i` 或 `-e` 时使用 `-f` 选项也很有用，因为这些选项仅在文件夹被实际重建的情况下才工作。同样，如果使用 `-n` 选项（它执行检查而不是重建），则 `-i` 和 `-e` 选项将不工作。
`-f`	强制 `reconstruct` 执行对邮箱的修复。
`-l`	用于重建 `lright.db`。
`-m`	用于执行一致性检查以及修复邮箱数据库（如果需要）。此选项将检查在假脱机区域中找到的每个邮箱，酌情添加条目或从邮箱数据库删除条目。无论何时添加条目或从数据库删除条目，实用程序都将消息显示到标准输出文件。特别是它修复 `folder.db`、`quota.db` 和 `lright.db`
`-n`	仅检查邮件存储，而不对邮箱执行修复。`-n` 选项不能单独使用，除非提供了邮箱名称。未提供邮箱名称时，`-n` 选项必须与 `-r` 选项一起使用。`-r` 选项可以与 `-p` 选项组合使用。例如，以下任一命令都是有效的： `reconstruct -n user/dulcinea/INBOX` `reconstruct -n -r` `reconstruct -n -r -p primary` `reconstruct -n -r user/dulcinea/`
`-o`	作废，请参见 `mboxutil -o`
`-o` `-d` `filename`	作废，请参见 `mboxutil -o`
`-p` `partition`	`-p` 选项和 `-m` 选项一起使用，用于限制指定分区的重建范围。如果未指定 `-p` 选项，`reconstruct` 将默认为对所有分区执行操作。特别是它修复 `folder.db` 和 `quota.db`，而不是 `lright.db`。这是因为修复 `lright.db` 需要对邮件存储中的每个用户进行 acl 扫描。为每个分区执行此操作效率不高。要修复 `lright.db`，运行 `reconstruct -l`。指定分区名称；不使用全路径名。
`-q`	修复配额子系统中的所有不一致性，例如带有错误配额根（其中报告了错误的配额使用情况）的邮箱。其他服务器进程正在运行时，可以运行 `-q` 选项。
`-r` [`mailbox`]	修复并对指定邮箱的分区区域执行一致性检查。`-r` 选项还修复指定邮箱内的所有子邮箱。如果不使用任何邮箱参数指定 `-r`，实用程序将修复用户分区目录内的所有邮箱的假脱机区域。
`-u` `user`	`-u` 选项与 `-m` 选项一起使用，用于限制到指定用户的重建范围。`-u` 选项必须与 `-p` 选项一起使用。如果未指定 `-u` 选项，`reconstruct` 默认为对所有分区或由 `-p` 选项指定的分区进行操作。指定用户名称；不使用全路径名。

重建邮箱

要重建邮箱，请使用 -r 选项。您应在以下情况使用此选项：

访问邮箱时返回以下错误之一：“System I/O 错误”或“邮箱格式无效”。
访问邮箱时导致服务器崩溃。
已经向假脱机目录添加文件或从其中删除文件。

reconstruct -r 首先将运行一致性检查。仅在检测到任何问题时报告所有一致性并重建。因此，reconstruct 实用程序的性能在此版本内得到了改进。

您可以使用以下示例中所述的 reconstruct：

要重建属于用户 daphne 的邮箱的假脱机区域，请使用以下命令：

reconstruct -r user/daphne

要重建邮箱数据库中列出的所有邮箱的假脱机区域，请使用以下命令：

reconstruct -r

但是，您必须谨慎使用此选项，因为对于大型邮件存储，重建邮箱数据库中列出的所有邮箱的假脱机区域将花费很长时间。（请参见reconstruct 性能。）故障恢复的更好的方法可能是将多个磁盘用于存储。如果一个磁盘出现故障，整个存储不会出现故障。如果一个磁盘破坏，只需使用 -p 选项重建一个存储的分区，如下所示：

reconstruct -r -p subpartition

要重建命令行参数中列出的邮箱，只要它们位于 primary 分区中，使用以下命令：

reconstruct -p primary mbox1 mbox2 mbox3

如果确实需要重建 primary 分区中的所有邮箱，使用以下命令：

reconstruct -r -p primary

如果要强制 reconstruct 程序重建文件夹，而不执行一致性检查，使用 -f 选项。例如，以下命令将强制执行用户文件夹 daphne 的重建：

reconstruct -f -r user/daphne

要检查所有邮箱而不对其进行修复，使用 -n 选项，如下所示：

reconstruct -r -n

检查并修复邮箱

要执行高级别一致性检查和邮箱数据库的修复，请使用以下命令：

reconstruct -m

要执行主分区的一致性检查和修复，请使用以下命令：

reconstruct -p primary -m

注 –

同时运行 reconstruct 与 -p 和 -m 标志将不能修复 lright.db。这是因为修复 lright.db 需要对邮件存储中的每个用户进行 ACL 扫描。为每个分区执行此操作效率不高。要修复 lright.db，请运行 reconstruct -l

要执行名为 john 的单个用户的邮箱的一致性检查和修复，请执行以下命令：

reconstruct -p primary -u john -m

您应在以下情况下使用 -m 选项：

从存储假脱机区域删除了一个或多个目录，因此也需要删除邮箱数据库条目。
一个或多个目录被恢复到存储假脱机区域，因此也需要添加邮箱数据库条目。
stored -d 选项不能使数据库保持一致。

如果 stored -d 选项不能使数据库保持一致，您应按指示的顺序执行以下步骤：
- 关闭所有服务器。
- 删除 store_root/mboxlist 中的所有文件。
- 重新启动服务器进程。
- 运行 reconstruct -m 以根据假脱机区域的内容建立新邮箱数据库。

reconstruct 性能

reconstruct 执行操作所花费的时间取决于以下因素：

要执行的操作和选择的选项的种类
磁盘性能
运行 reconstruct -m 时文件夹的数量
运行 reconstruct -r 时邮件的数量
邮件存储的总大小
系统运行的其他进程以及系统的繁忙程度
是否存在正在进行的 POP、IMAP、HTTP 或 SMTP 活动

reconstruct -r 选项将执行初始一致性检查；此检查将根据必须重建多少文件夹来改善 reconstruct 的性能。

一个具有大约 2400 个用户、85GB 的邮件存储和在服务器上并行的 POP、IMAP 或 SMTP 活动的系统具有如下性能：

reconstruct -m 花费大约 1 小时
reconstruct -r -f 花费大约 18 小时

注 –

如果服务器不执行正在进行的 POP、IMAP、HTTP 或 SMTP 活动，reconstruct 操作可能会明显花费较少的时间。

常见问题和解决方案

本节列出了常见的邮件存储问题和解决方案：

Messenger Express 或 Communications Express 未装入邮件页面

如果用户无法装入任何 Messenger Express 页面或 Communications Express 邮件页面，则问题可能是数据压缩后被破坏。如果系统部署了过时的代理服务器，则有时可能会出现这种情况。要解决此问题，请尝试将 local.service.http.gzip.static 和 local.service.http.gzip.dynamic 设置为 0 以禁用数据压缩。如果这样能够解决问题，您可能需要更新代理服务器。

使用通配符模式的命令不起作用

某些 UNIX shell 可能需要用引号引起通配符参数，某些则不需要。例如，C shell 尝试将包含通配符（*、?）的参数扩展为文件，如果未找到任何匹配项，则将失败。这些模式匹配参数可能需要包含在引号中，以传递给命令（如 mboxutil）。

例如：

mboxutil -l -p user/usr44*

将在 Bourne shell 中运行，但在 tsch 和 C shell 中将失败。这些 shell 可能需要以下命令：

mboxutil -l -p "user/usr44*"

如果使用通配符模式的命令不起作用请验证是否需要为该 shell 的通配符使用引号。

未知/无效分区

如果用户邮箱被移动到刚创建的新分区并且尚未刷新或重新启动 Messaging Server，则用户将会从 Messenger Express 获得消息“未知/无效分区”。此问题仅在新分区中发生。如果现在向此新分区添加其他用户邮箱，则不必刷新/重新启动 Messaging Server。

用户邮箱目录问题

当邮件存储的损坏仅限于少数用户且没有对系统造成全局损坏时，将出现用户邮箱问题。以下指导建议了识别、分析和解决用户邮箱目录问题的进程：

查看日志文件、错误消息或用户观察到的任何异常性能。
要保存调试信息和历史记录，请将整个 store_root/mboxlist/ 用户目录复制到邮件存储以外的其他位置。
要查找可能导致问题的用户文件夹，请运行命令 reconstruct -r -n。如果使用 reconstruct 找不到该文件夹，则该文件夹可能不在 folder.db 中。

如果使用 reconstruct -r -n 命令找不到该文件夹，使用 hashdir 命令以确定位置。有关 hashdir 的更多信息，请参见hashdir 实用程序，以及《Sun Java System Messaging Server 6 2005Q4 Administration Reference》的 "Messaging Server Command-line Utilities" 一章中的 hashdir 实用程序部分。
找到文件夹后，请检查文件、检查权限并验证正确的文件大小。
使用 reconstruct -r（不使用 -n 选项）重建邮箱。
如果 reconstruct 未检测到您观察到的问题，您可以使用 reconstruct -r -f 命令强制执行对邮件文件夹的重建。
如果文件夹不在 mboxlist 目录 (store_root/mboxlist) 中，而是在 partition 目录 (store_root/partition) 中，则可能存在全局不一致性。在此情况下，应运行 reconstruct -m 命令。
如果前面的步骤不起作用，可以删除 store.idx 文件并再次运行 reconstruct 命令。

注意 –
如果确定是在 reconstruct 命令无法找到的文件中有问题，则应仅删除 store.idx 文件。
如果问题限制为有问题的邮件，则应将邮件文件复制到邮件存储以外的其他位置，并对 mailbox/ 目录运行命令 reconstruct -r。
如果确定文件夹存在于磁盘（store_root/partition/ 目录）上，但是显然不在数据库（store_root/mboxlist/ 目录）中，则运行命令 reconstruct -m 以确保邮件存储的一致性。

有关 reconstruct 命令的更多信息，请参见修复邮箱和邮箱数据库。

store 守护程序不启动

如果 stored 不启动，并显示以下错误消息：

# msg_svr_base/sbin/start-msg

msg_svr_base: 正在启动 STORE 守护进程...致命错误: 无法找到名称服务中的组

这表示找不到 local.servergid 中配置的 UNIX 组。Stored 和其他命令需要将其 gid 设置到该组。有时 local.servergid 定义的组可能会被无意删除。在此情况下，请创建已删除的组，将 inetuser 添加到该组，将 instance_root 及其文件的拥有权更改为 inetuser 和该组。