20.11 执行消息存储维护过程

本节提供有关用于执行消息存储的维护和恢复任务的实用程序的信息。您应该始终阅读服务器可能发送的用于警告和警报的邮寄主管邮件。您还应监视日志文件以获取有关服务器如何执行操作的信息。有关日志文件的详细信息，请参见第 25 章，管理日志记录。

本节包含以下内容：

• 20.11.1 给消息存储添加更多的物理磁盘

• 20.11.2 管理邮箱

• 20.11.3 邮箱最大大小

• 20.11.4 监视配额限制

• 20.11.5 监视磁盘空间

• 20.11.6 stored 守护进程

• 20.11.7 由于重复存储相同的邮件而减少消息存储大小

20.11.1 给消息存储添加更多的物理磁盘

Messaging Server 消息存储包含特定 Messaging Server 实例的用户邮箱。消息存储的大小随邮箱、文件夹和日志文件的数量的增加而增加。

向系统添加更多用户时，磁盘存储要求会相应增加。根据服务器支持的用户的数量，消息存储可能需要一个物理磁盘或多个物理磁盘。Messaging Server 使您可以根据需要添加更多存储。添加更多存储的一种方法是使用存储设备。有关如何使用 Messaging Server 配置 Network Appliance 存储设备的信息，请参见《Using NetApp Filers with Sun Java System Messaging Server Message Store》。

20.11.2 管理邮箱

本节介绍了以下用于管理和监视邮箱的实用程序：mboxutil、hashdir、readership。

20.11.2.1 mboxutil 实用程序

使用 mboxutil 命令执行典型的邮箱维护任务。mboxutil 任务包括以下内容：

• 列出邮箱

• 列出并删除孤立的和非活动的邮箱

• 创建邮箱

• 重命名邮箱

• 将邮箱从一个分区移动到另一个分区

• 擦除邮箱

• 恢复已擦除但尚未被清除的邮件

• 列出个人邮箱订阅和不再存在的取消订阅的邮箱

• 您还可以使用 mboxutil 命令查看有关配额的信息。有关详细信息，请参见20.11.4 监视配额限制。

请注意，不应在执行过程中中止 mboxutil 进程。如果使用 SIGKILL (kill -9) 中止了该进程，则可能潜在地需要每个服务器重新启动并完成恢复。

有关语法和使用要求的详细信息，请参见《Sun Java System Messaging Server 6.3 Administration Reference》中的“mboxutil”。

示例

要列出所有用户的所有邮箱，请运行以下命令：

mboxutil -l

要列出所有邮箱并且包含路径和 ACL 信息，请运行以下命令：

mboxutil -l -x

要为用户 daphne 创建名为 INBOX 的默认邮箱，请运行以下命令：

mboxutil -c user/daphne/INBOX

要为用户 delilah 删除名为 projx 的邮件文件夹，请运行以下命令：

mboxutil -d user/delilah/projx

要为用户 druscilla 删除名为 INBOX 的默认邮箱及所有邮件文件夹，请运行以下命令：

mboxutil -d user/druscilla/INBOX

要将用户 desdemona 的邮件文件夹 memos 重命名为 memos-april，请运行以下命令：

mboxutil -r user/desdemona/memos user/desdemona/memos-april

要将用户 dimitria 的邮件帐户移动到新分区，请运行以下命令：

mboxutil -r user/dimitria/INBOX user/dimitria/INBOX partition

其中 partition 用于指定新分区的名称。

要将用户 dimitria 的名为 personal 的邮件文件夹移动到新分区，请运行以下命令：

mboxutil -r user/dimitria/personal user/dimitria/personal partition

20.11.2.2 删除孤立帐户

要搜索孤立帐户（孤立帐户是在 LDAP 中没有相应条目的邮箱），请使用以下命令：

mboxutil -o

命令输出如下所示：

  mboxutil: Start checking for orphaned mailboxes
  user/annie/INBOX
  user/oliver/INBOX
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

使用以下命令创建列出可转换为脚本文件的孤立邮箱的文件，用于删除孤立邮箱（示例文件名为 orphans.cmd）：

mboxutil -o -w orphans.cmd

命令输出如下所示：

  mboxutil: Start checking for orphaned mailboxes
  mboxutil: Found 2 orphaned mailbox(es)
  mboxutil: Done checking for orphaned mailboxes

使用以下命令删除孤立文件：

mboxutil -d -f orphans.cmd

20.11.2.3 hashdir 实用程序

消息存储中的邮箱以散列结构存储以便进行快速搜索。因此，要查找包含特定用户的邮箱的目录，请使用 hashdir 实用程序。

此实用程序可以识别包含特定帐户的消息存储的目录。此实用程序将报告消息存储的相对路径，例如 d1/a7/。该路径相对于基于用户 ID 的级别之前的目录级别。实用程序会将路径信息发送到标准输出。

例如，要查找用户 crowe 的邮箱的相对路径，请运行以下命令：

hashdir crowe

20.11.2.4 readership 实用程序

readership 实用程序将报告有多少用户（而不是邮箱拥有者）已经阅读了共享 IMAP 文件夹中的邮件。

IMAP 文件夹的拥有者可以授予其他用户阅读文件夹中的邮件的权限。允许其他用户访问的文件夹称为共享文件夹。管理员可以使用 readership 实用程序查看有多少用户（而不是拥有者）正在访问共享文件夹。

此实用程序将扫描所有邮箱并为每个共享文件夹生成一行输出，报告阅读者的数量，接着是一个空格和邮箱的名称。

每个阅读者都是在过去的指定天数内选择了共享文件夹的独特验证身份。用户阅读自己的个人邮箱时系统不进行计数。系统不报告个人邮箱，除非至少有一个文件夹拥有者以外的阅读者。

例如，以下命令行将在过去 15 天内选择了共享 IMAP 文件夹的任何身份都作为阅读者进行计数：

readership -d 15

20.11.3 邮箱最大大小

一个邮箱的最大大小可以容纳约一百万封邮件。超过此限制将导致邮件无法传送给用户，并且可能会导致消息存储库性能问题。有关详细信息，请参见20.14.4.7 由于邮箱溢出而无法传送邮件。

20.11.4 监视配额限制

通过使用 imquotacheck 监视配额使用情况和限制，此实用程序生成一个报告，其中列出了已定义的配额和限制，并提供有关配额使用情况的信息。以千字节为单位报告配额和使用情况数字。此实用程序也可以将邮箱大小与用户分配的配额进行比较。此外，您可以选择通过电子邮件向已超出的配额量达到所设置的百分比的用户发送通知。

在 imquotacheck 中某些功能已更改。（在 Messaging Server 6.x 中，imquotacheck 实用程序已取代了 quotacheck 实用程序。）在 Messaging Server 5.x 中，当您使用 quotacheck 实用程序检索用户列表时，quotacheck 搜索本地 mboxlist 数据库。此功能重复 mboxutil 实用程序中的搜索功能。

在 Messaging Server 6.x 中，此重复功能已从 imquotacheck 实用程序中删除。如果您使用 imquotacheck 执行用户搜索，将针对 LDAP 目录执行搜索，而不是针对本地 mboxlist 数据库。要从本地 mboxlist 数据库检索用户列表，请使用 mboxutil 实用程序。

要列出配额超出规则文件中的最小阈值的所有用户的使用情况，请运行以下命令：

imquotacheck

列出域 siroe.com 的配额信息：

imquotacheck -d siroe.com

要依据默认规则文件向所有用户发送通知，请运行以下命令：

imquotacheck -n

要根据指定的 rulefile、myrulefile 和邮件模板文件 mytemplate.file 向所有用户发送通知，请运行以下命令（有关详细信息，请参阅《Sun Java System Messaging Server 6.3 Administration Reference》中的“imquotacheck”）：

imquotacheck -n -r myrulefile -t mytemplate.file

要列出所有用户的使用情况（将忽略规则文件），请运行以下命令：

imquotacheck -i

要列出用户 user1 的每个文件夹的使用情况（将忽略规则文件），请运行以下命令：

imquotacheck -u user1 -e

20.11.5 监视磁盘空间

您可以指定系统监视磁盘空间和分区使用情况的频率，以及系统应在什么情况下发送警告。有关详细信息，请参见27.3.2 监视磁盘空间。

20.11.6 stored 守护进程

stored 守护进程为消息存储执行以下维护任务：

• 执行检查点数据库事务.

• 死锁检测和死锁数据库事务的回滚。

• 启动时清除临时文件和锁定文件。

• 创建数据库快照归档。

• 根据需要恢复数据库（请参见20.14.2 消息存储启动和恢复）。

如果任一服务器守护进程崩溃，则必须停止所有守护进程并重新启动所有守护进程，包括 stored。

20.11.7 由于重复存储相同的邮件而减少消息存储大小

将某邮件发送给多个收件人时，该邮件将被置于每个收件人的邮箱中。某些邮件服务系统将同一邮件的副本分别存储在每个收件人的邮箱中。相反地，Sun Java System Messaging Server 力求保留一个邮件副本，而不考虑该邮件所在的邮箱数。通过在包含该邮件的邮箱中创建指向该邮件的硬链接即可实现此目的。

在将其他邮件服务系统迁移到 Sun Java Messaging Server 时，可能会在迁移过程中将这些多个邮件副本复制到 Sun Java Messaging Server 中。消息存储会很大，这意味着不必要地重复了很多邮件。此外，在正常的服务器操作中也可能会积累同一邮件的多个副本，例如，从 IMAP append操作或其他来源中。

Messaging Server 提供了一个名为 relinker 的新命令，该命令用于删除过量的邮件副本，并使用指向单个副本的硬链接替换这些邮件副本。

20.11.7.1 relinker 操作原理

重链接功能可在命令模式或实时模式下运行。当 relinker 命令运行时，它将扫描整个消息存储分区，创建或更新 MD5 邮件摘要系统信息库（以硬链接形式），删除过量的邮件文件，并创建必要的硬链接。

摘要系统信息库由指向消息存储中的邮件的硬链接组成。它存储在目录分层结构 partition_path/=md5 中。此目录与用户邮箱分层结构 partition_path/=user 并行（请参见图 20–1）。摘要系统信息库中的邮件可由其 MD5 摘要唯一标识。例如，如果 fredb/00/1.msg 的摘要为 4F92E5673E091B43415FFFA05D2E47，则 partition/=user/hashdir/hashdir/=fredb/00/1.msg 将被链接到 partition/=md5/hashdir/hashdir/4F92E5673E091B43415FFFA05D2E47EA.msg。如果另一个邮箱中也有这封相同邮件（例如 partition_path/=user/hashdir/hashdir/gregk/00/17.msg），则该邮件也将被硬链接到 partition_path/=md5/4F/92/4F92E5673E091B43415FFFA05D2E47EA.msg。如图 20–4 中所示。

图 20–4 消息存储摘要系统信息库

对于这封邮件，链接计数为三。如果从 fredb 和 gregk 邮箱中删除了这两封相同邮件，则链接计数为一并且可以清除此邮件。

还可以在实时模式下运行 relinker 进程以实现类似的功能。有关详细信息，请参见20.11.7.3 在实时模式下使用 relinker。

20.11.7.2 在命令行模式中使用 relinker

relinker 将扫描整个消息存储分区，创建或更新 MD5 邮件系统信息库（以硬链接形式）并删除过量的邮件文件。relinker 扫描完存储分区后，它将输出唯一邮件数和重链接前后分区大小的统计信息。为了在已散列的存储上更快速地运行，relinker 将只计算尚未存在于 =md5 中的邮件摘要。它还具有可以删除整个摘要系统信息库（此操作不会影响用户邮箱）的选项。

命令的语法如下所示：

relinker [-P. partitionname] [-d]

其中 partitionname 指定要处理的分区（默认值：所有分区），-d 指定将删除摘要系统信息库。以下显示了输出样例：

# relinker

Processing partition: primary
Scanning digest repository...
Processing user directories..............................
---------------------------------------------------------
Partition statistics           Before            After 
---------------------------------------------------------
Total messages                 4531898         4531898
Unique messages                4327531         3847029
Message digests in repository        0         3847029
Space used                       99210Mb         90481Mb
Space savings from single-copy    3911Mb         12640Mb
---------------------------------------------------------


# relinker -d 
Processing partition: primary
Purging digest repository...
---------------------------------------------------------
Partition statistics                 Before         After
---------------------------------------------------------
Message digests in repository       3847029             0
---------------------------------------------------------

运行 relinker 可能需要花费很长时间，尤其是在系统信息库中没有邮件的情况下首次运行。这是因为如果将 relinker 条件配置为包含所有邮件，则 relinker 必须计算每封邮件的摘要—有关配置 relinker 条件的信息，请参见20.11.7.4 配置 relinker。例如，处理 100 千兆字节的消息存储可能需要花费六个小时。但是，如果启用了运行时重链接，请参见20.11.7.3 在实时模式下使用 relinker。

如果单独使用 relinker 命令行模式，而不使用运行时选项，则必须清除摘要系统信息库 (=md5)，否则存储 (=user) 中清除的邮件所占用的空间将不能成为可用磁盘空间，因为在摘要系统信息库中仍有这些邮件的链接（它们将成为孤立邮件）。如果只执行存储的一次性优化（例如，在迁移后），您可以运行一次 relinker，然后使用 relinker -d 删除整个系统信息库。对于迁移过程中进行的重复清除，只要重复运行 relinker 命令就可以了，因为每次运行该命令时，还会从系统信息库中清除过期的或孤立的邮件。

并行运行 relinker 的多个实例来使每个实例分别处理不同分区（使用 -p 选项），这样做是最安全的。仅在同一分区内重链接邮件。

20.11.7.3 在实时模式下使用 relinker

通过将 configutil 参数 local.store.relinker.enabled 设置为 yes 可以在实时模式下启用 relinker 函数。在实时模式下使用 relinker 将计算符合配置的 relinker 条件（20.11.7.4 配置 relinker）的每封已传送（或已恢复、IMAP 已附加等）邮件的摘要，然后查找系统信息库以查看该摘要是否已存在。如果摘要存在，relinker 将在目标邮箱中创建一个指向该摘要的链接而不创建该邮件的新副本。如果摘要不存在，relinker 将创建该邮件，然后在系统信息库中添加指向该邮件的链接。

stored 将扫描每个分区的摘要系统信息库，并清除链接计数为 1 或不符合 relinker 条件的邮件。在可配置的时间段内，扫描一次将扫描完一个目录。这样可以平均分布 I/O 负载而不会对其他服务器操作造成明显影响。默认情况下，清除周期为 24 小时，这意味着从存储中删除了邮件或者邮件超过了配置的最大生存期后，这些邮件最多还可在磁盘上保存 24 小时。如果启用了 relinker 实时模式，将启用此任务。

20.11.7.4 配置 relinker

表 20–11 显示了用于设置 relinker 条件的参数。