20.14 消息存储故障排除

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

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

• 20.14.1 标准消息存储监视过程

• 20.14.2 消息存储启动和恢复

• 20.14.3 修复邮箱和邮箱数据库

• 20.14.4 常见问题和解决方案

20.14.1 标准消息存储监视过程

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

有关其他信息，请参见27.7 监视消息存储。

20.14.1.1 检查硬件空间

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

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

有关监视磁盘空间的信息，请参见20.11.5 监视磁盘空间和27.7 监视消息存储。

20.14.1.2 检查日志文件

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

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

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

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

要捕获 POP 会话，请创建以下目录：

msg-svr-base/data/telemetry/ pop_or_imap_or_http/userid

要捕获 POP 会话，请创建以下目录：

msg-svr-base/data/telemetry/pop/ userid

要捕获 IMAP 会话，请创建以下目录：

msg-svr-base/data/telemetry/imap/ userid

要捕获 Webmail 会话，请创建以下目录：

msg-svr-base/data/telemetry/http/ userid

请注意，目录必须由邮件传送服务器 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>

要禁用自动测量日志记录，请移动或删除您创建的目录。

20.14.1.4 检查 stored 进程

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

• 检查 stored 进程是否在运行。运行 imcheck

• 检查在 store_root/mboxlist 中生成的日志文件。

• 检查默认日志文件 msg-svr-base/log/default/default 中的 stored 邮件。

• 检查每当 stored 进程尝试以下功能之一时，以下文件（位于目录 msg-svr-base/config/ 中）的时间戳是否已更新：

有关 stored 进程的详细信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的20.11.6 stored 守护进程 一章。

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

20.14.1.5 检查数据库日志文件

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

20.14.1.6 检查用户文件夹

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

20.14.1.7 检查主存文件

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

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.14.3 修复邮箱和邮箱数据库

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

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

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

20.14.3.1 重建邮箱

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

• 访问邮箱时返回以下错误之一：“System I/O 错误”或“邮箱格式无效”。

• 访问邮箱时导致服务器崩溃。

• 已经向假脱机目录添加文件或从其中删除文件。

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

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

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

reconstruct -r user/daphne

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

reconstruct -r

但是，您必须谨慎使用此选项，因为对于大型消息存储，重建邮箱数据库中列出的所有邮箱的假脱机区域将花费很长时间。（请参见20.14.3.3 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

20.14.3.2 检查并修复邮箱

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

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 以根据假脱机区域的内容建立新邮箱数据库。

20.14.3.3 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 操作可能会明显花费较少的时间。

20.14.4 常见问题和解决方案

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

• 20.14.4.1 Linux - Messaging Server Patch 120230-08 IMAP、POP 和 HTTP 服务器由于每个进程会话过多而未启动

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

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

• 20.14.4.4 未知/无效分区

• 20.14.4.5 用户邮箱目录问题

• 20.14.4.6 store 守护程序不启动

• 20.14.4.7 由于邮箱溢出而无法传送邮件

20.14.4.1 Linux - Messaging Server Patch 120230-08 IMAP、POP 和 HTTP 服务器由于每个进程会话过多而未启动

安装该修补程序后，当您尝试启动 Messaging Server 时，IMAP、POP 和 HTTP 服务器无法启动，并可能发送以下示例错误日志：

http server - log:
[29/May/2006:17:44:37 +051800] usg197 httpd[6751]: General Critical: Not enough file 
descriptors to support 6000 sessions per process; Recommend ulimit -n 12851 or 87 
sessions per process.

pop server - log:
[29/May/2006:17:44:37 +051800] usg197 popd[6749]: General Critical: Not enough file 
descriptors to support 600 sessions per process; Recommend ulimit -n 2651 or 58 
sessions per process.

Once these values setting in /opt/sun/messaging/sbin/configutil then imap server 
failed to start

imap server - log: 
[29/May/2006:17:44:37 +051800] usg197 imapd[6747]: General Critical: Not enough 
file descriptors to support 4000 sessions per process; Recommend ulimit -n 12851 
or 58 sessions per process.

为所有三个服务器会话设置相应数目的文件描述符。通过向 /etc/sysctl.conf 添加类似以下代码的行并使用 sysctl -p 重读该文件，即可使用附加的文件描述符：

fs.file-max = 65536

还必须向 /etc/security/limits.conf 添加类似以下代码的行：

*   soft  nofile  65536  
*   hard  nofile  65536

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

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

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

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

例如：

mboxutil -l -p user/usr44*

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

mboxutil -l -p "user/usr44*"

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

20.14.4.4 未知/无效分区

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

20.14.4.5 用户邮箱目录问题

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

1. 查看日志文件、错误消息或用户观察到的任何异常性能。

2. 要保存调试信息和历史记录，请将整个 store_root/mboxlist/ 用户目录复制到消息存储以外的其他位置。

3. 要查找可能导致问题的用户文件夹，请运行命令 reconstruct -r -n。如果使用 reconstruct 找不到该文件夹，则该文件夹可能不在 folder.db 中。

   如果使用 reconstruct -r -n 命令找不到该文件夹，请使用 hashdir 命令确定位置。有关 hashdir 的详细信息，请参见20.11.2.3 hashdir 实用程序，以及《Sun Java System Messaging Server 6.3 Administration Reference》的 "Messaging Server Command-line Utilities" 一章中的 hashdir 实用程序部分。

4. 找到文件夹后，请检查文件、检查权限并验证正确的文件大小。

5. 使用 reconstruct -r（不使用 -n 选项）重建邮箱。

6. 如果 reconstruct 未检测到您观察到的问题，您可以使用 reconstruct -r -f 命令强制执行对邮件文件夹的重建。

7. 如果文件夹不在 mboxlist 目录 (store_root/mboxlist) 中，而是在 partition 目录 (store_root/partition) 中，则可能存在全局不一致性。在此情况下，应运行 reconstruct -m 命令。

8. 如果前面的步骤不起作用，可以删除 store.idx 文件并再次运行 reconstruct 命令。

   ---

   注意 –

   如果确定是在 reconstruct 命令无法找到的文件中有问题，则应仅删除 store.idx 文件。

   ---

9. 如果问题限制为有问题的邮件，则应将邮件文件复制到消息存储以外的其他位置，并对 mailbox/ 目录运行命令 reconstruct -r。

10. 如果确定文件夹存在于磁盘（store_root/partition/ 目录）上，但是显然不在数据库（store_root/mboxlist/ 目录）中，则运行命令 reconstruct -m 以确保消息存储的一致性。

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

20.14.4.6 store 守护程序不启动

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

# msg-svr-base/sbin/start-msg

msg-svr-base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

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

20.14.4.7 由于邮箱溢出而无法传送邮件

消息存储对 store.idx 文件设置了 2 千兆字节的硬性限制，这等效于在一个邮箱（文件夹）中可以存放一百万封邮件。当邮箱增长到 store.idx 文件将超过 2 千兆字节的那一点时，用户将停止接收任何新的电子邮件。此外，处理该邮箱的其他进程（如 mapd、popd、mshttpd）的性能也会降低。

如果出现该问题，您将在 mail.log_current 中看到如下错误：

05-Oct-2005 16:09:09.63 ims-ms Q 7 ...System I/O error.Administrator, check server log for details.System I/O error.

此外，MTA 日志文件将出现如下错误：

[05/Oct/2005:16:09:09 +0900] jmail ims_master[20745]:Store Error:Unable to append cache for user/admin:File too large

通过查看用户消息存储目录中的文件，或者在 imta 查看更详细的信息，您可以准确地确定该问题。

应立即着手减小文件的大小。可以删除一些邮件，或者将一些邮件移动到另一个邮箱。要解决此问题，您也可以使用 mboxutil -r 重命名该文件夹，或者使用 mboxutil -d 删除该文件夹（请参见20.11.2.1 mboxutil 实用程序）。

从长远来看，您应该向用户通知邮箱大小限制、实现生存期策略（请参见20.9 设置自动删除邮件（过期和清除）功能）和配额策略（请参见20.8 关于消息存储配额）、通过设置 local.store.maxmessages 来设置邮箱限制（请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“configutil Parameters”）、建立归档系统，或者执行某些操作来控制邮箱大小。