管理邮箱数据库副本

 

适用于: Exchange Server 2010 SP2, Exchange Server 2010 SP3

上一次修改主题: 2015-03-09

数据库移动性是从邮箱服务器中删除存储组概念并对 Exchange 2010 邮箱数据库进行解耦的 Microsoft Exchange Server 2010 中的新体系结构。因为已从 Exchange 2010 中删除存储组,所以现在连续复制在数据库级别上进行。在 Exchange 2010 中将事务日志复制到一个或多个邮箱服务器,并将其重播到在这些服务器上存储的邮箱数据库的一个或多个副本中。Exchange 2010 中保留了 Exchange Server 2007 连续复制中使用的几个概念。其中包括分歧的概念、自动数据库装入拨号的使用以及公用和专用网络的使用。

管理数据库副本

在创建数据库的多个副本之后,可以使用 Exchange 管理控制台 (EMC) 和 Exchange 命令行管理程序监视每个副本的运行状况和状态,并执行与数据库副本关联的其他管理任务。您可能需要执行的某些管理任务包括挂起或恢复数据库副本、为数据库副本设定种子、监视数据库副本、配置数据库副本设置以及删除数据库副本。

挂起和恢复数据库副本

出于多种原因(如执行计划维护),可能需要挂起和恢复对数据库副本的连接复制活动。此外,某些管理任务(如设定种子)需要先挂起数据库副本。我们还建议在更改数据库路径或其日志文件时挂起所有复制活动。可以使用 EMC 或运行命令行中的 Suspend-DatabaseCopyResume-DatabaseCopy cmdlet 挂起和恢复数据库副本活动。有关挂起或恢复数据库副本的连续复制活动的详细步骤,请参阅挂起或恢复邮箱数据库副本

当一个或多个被动副本挂起时,主动邮箱数据库副本上将不发生日志截断。如果您的计划维护活动将花很长时间(例如几天),可能会累积大量的日志文件。为了防止事务日志填满日志驱动器,可以删除受影响的被动数据库副本,而不是将其挂起。当计划维护完成时,可以重新添加被动数据库副本。

为数据库副本设定种子

设定种子也称为更新是一个过程,在此过程中可以将数据库、空白数据库或生产数据库副本添加到与生产数据库相同的数据库可用性组 (DAG) 中其他邮箱服务器上的目标副本位置。这将成为该服务器维护的副本的基线数据库。

根据实际情况,设定种子可以是自动过程,也可以是手动启动的过程。添加数据库副本时,将自动设定副本种子,但前提是正确配置了目标服务器及其存储。如果您想手动植入数据库副本的种子,而不想在创建副本时自动植入种子,可以在运行 Add-MailboxDatabaseCopy cmdlet 时使用 SeedingPostponed 参数。

在初始种子设定已经发生之后,数据库副本很少需要重新设定种子。但如果需要重新设定种子,或者要手动为数据库副本设定种子而不是系统自动为副本设定种子,则可以通过使用 EMC 中的更新数据库副本向导或者命令行中的 Update-MailboxDatabaseCopy cmdlet 执行这些任务。在为数据库副本设定种子之前,必须首先挂起邮箱数据库副本。有关为数据库副本设定种子的详细步骤,请参阅更新邮箱数据库副本

在完成手动设定种子操作之后,将自动恢复对已设定种子的邮箱数据库副本的复制。如果不希望自动恢复复制,则可以在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 ManualResume 参数。

选择要设定的种子

执行种子设定操作时,可以选择为邮箱数据库副本、邮箱数据库副本的内容索引目录设定种子,或者同时为数据库副本和内容索引目录副本设定种子。更新数据库副本向导和 Update-MailboxDatabaseCopy cmdlet 的默认行为是同时为邮箱数据库副本和内容索引目录副本设定种子。若只要为邮箱数据库副本设定种子,而不为内容索引目录设定种子,请在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 DatabaseOnly 参数。若只要为内容索引目录副本设定种子,请在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 CatalogOnly 参数。

选择种子设定源

在 Exchange 2007 中,通过复制数据库的活动副本,连续复制只可以为数据库副本设定种子。在 Exchange 2010 中,任何状况良好的数据库副本都可以用作该数据库其他副本的种子设定源。在具有已跨多个物理位置进行扩展的 DAG 时,这特别有用。例如,考虑一下四成员 DAG 部署的情况,其中两名成员(MBX1 和 MBX2)在俄勒冈州的波特兰、另两名成员(MBX3 和 MBX4)在纽约州的纽约市。名为 DB1 的邮箱数据库在 MBX1 上处于活动状态,并在 MBX2 和 MBX3 上有 DB1 的被动副本。将 DB1 的副本添加到 MBX4 时,您可以选择将 MBX3 上的副本用作种子设定源,这样做可以避免通过波特兰和纽约之间的广域网 (WAN) 链接来设定种子。

若要在添加新数据库副本时使用特定副本作为种子设定源,则会执行以下操作:

  • 在运行 Add-MailboxDatabaseCopy cmdlet 的同时使用 SeedingPostponed 参数添加数据库副本。如果不使用 SeedingPostponed 参数,则将使用数据库的活动副本作为源为数据库副本显式设定种子。

  • 在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 SourceServer 参数,并指定用于种子设定的所需源服务器。在前面的示例中,您会指定 MBX3 作为源服务器。如果不使用 SourceServer 参数,则将使用数据库的活动副本作为源为数据库副本显式设定种子。

种子设定和网络

除选择特定的源服务器为邮箱数据库副本设定种子外,还可以指定要使用的 DAG 网络,并且可以选择在种子设定期间覆盖 DAG 网络的压缩和加密设置。

若要指定要用于种子设定的网络,请在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 Network 参数,并指定要使用的 DAG 网络。如果不使用 Network 参数,则系统会使用以下默认行为来选择要用于种子设定操作的网络:

  • 如果源服务器和目标服务器在相同子网上并且已配置包括该子网的复制网络,则将使用该复制网络。

  • 如果源服务器和目标服务器在不同子网上,即使已配置包含这些子网的复制网络,但还是将客户端 (MAPI) 网络用于种子设定。

  • 如果源服务器和目标服务器在不同数据中心中,则客户端 (MAPI) 网络将用于种子设定。

在 DAG 级别 上,将 DAG 网络配置为加密和压缩。默认设置是仅对不同子网上的通信使用加密和压缩。如果源和目标在不同子网上并且以 NetworkCompressionNetworkEncryption 的默认值配置 DAG,则可以在运行 Update-MailboxDatabaseCopy cmdlet 的同时使用 NetworkCompressionOverrideNetworkEncryptionOverride 参数分别覆盖这些值。

种子设定过程

使用 Add-MailboxDatabaseCopyUpdate-MailboxDatabaseCopy cmdlet 启动种子设定过程时,将执行以下任务:

  1. 从 Active Directory 读取数据库属性以验证指定的数据库和服务器,并且验证源和目标服务器正在运行 Exchange 2010、它们都是同一 DAG 的成员以及指定的数据库不是恢复数据库。还读取数据库文件路径。

  2. 从目标服务器上的 Microsoft Exchange 复制服务准备重新设定种子检查。

  3. 目标服务器上的 Microsoft Exchange 复制服务会检查数据库和事务日志文件在步骤 1 中由 Active Directory 检查读取的文件目录中是否存在。

  4. Microsoft Exchange 复制服务将状态信息从目标服务器返回到从其运行 cmdlet 的管理界面。

  5. 如果所有初级检查已经完成,则会继续之前提示您确认操作。如果您确认操作,则继续执行该过程。如果在初级检查期间遇到错误,则报告错误,并且操作失败。

  6. 从目标服务器上的 Microsoft Exchange 复制服务启动种子设定操作。

  7. Microsoft Exchange 复制服务挂起活动数据库副本的数据库复制。

  8. 由 Microsoft Exchange 复制服务会更新数据库的状态信息,以反映种子设定的状态。

  9. 如果目标服务器已经没有目标数据库和日志文件的目录,则创建它们。

  10. 将为数据库设定种子的请求从目标服务器上的 Microsoft Exchange 复制服务传递使用 TCP 的源服务器上的 Microsoft Exchange 复制服务。这个为数据库设定种子的请求和后续通信将在已配置为复制网络的 DAG 网络上进行。

  11. 源服务器上的 Microsoft Exchange 复制服务通过 Microsoft Exchange 信息存储服务界面启动可扩展存储引擎 (ESE) 流式备份。

  12. Microsoft Exchange 信息存储服务将数据库数据流式传输到 Microsoft Exchange 复制服务。

  13. 数据库数据从源服务器的 Microsoft Exchange 复制服务移动到目标服务器的 Microsoft Exchange 复制服务。

  14. 目标服务器上的 Microsoft Exchange 复制服务将数据库副本写入位于名为“temp-seeding”的主数据库目录中的临时目录。

  15. 源服务器上的流式备份操作随着到达数据库最后一行而结束。

  16. 目标服务器上的写入操作完成,并且数据库从 temp-seeding 目录移动到最后位置。将删除 temp-seeding 目录。

  17. 在目标服务器上,Microsoft Exchange 复制服务代理向 Microsoft Exchange 搜索服务代理发出请求,要求装入数据库副本的内容索引编录(如果有)。如果数据库副本的以前实例中有已过时的编录文件,则装入操作失败,这将激发从源服务器复制编录的需求。同样,如果编录不存在,并且不在目标服务器上的数据库副本的新实例上,则编录的副本是必需的。从源复制新编录时,Microsoft Exchange 复制服务会指示 Microsoft Exchange 搜索服务挂起对数据库副本的索引编制操作。

  18. 目标服务器上的 Microsoft Exchange 复制服务向源服务器上的 Microsoft Exchange 复制服务发送为编录设定种子的请求。

  19. 在源服务器上,Microsoft Exchange 复制服务请求来自 Microsoft Exchange 搜索服务的目录信息,并且请求挂起索引编制操作。

  20. 源服务器上的 Microsoft Exchange 搜索服务将搜索编录目录信息返回到 Microsoft Exchange 复制服务。

  21. 源服务器上的 Microsoft Exchange 复制服务从目录读取编录文件。

  22. 源服务器上的 Microsoft Exchange 复制服务使用跨复制网络的连接将编录数据移动到目录服务器上的 Microsoft Exchange 复制服务。在读取完成之后,Microsoft Exchange 复制服务将请求发送给 Microsoft Exchange 搜索服务以恢复源数据库的索引编制操作。

  23. 如果目录中出现任何目标服务器上的现有编录文件,则目标服务器上的 Microsoft Exchange 复制服务会删除它们。

  24. 目标服务器上的 Microsoft Exchange 复制服务将编录数据写入名为“CiSeed.Temp”的临时目录,直到完整传输数据为止。

  25. Microsoft Exchange 复制服务将完成的编录数据移动到最终位置。

  26. 目标服务器上的 Microsoft Exchange 复制服务恢复对目标数据库上的索引搜索。

  27. 目标服务器上的 Microsoft Exchange 复制服务返回完成状态。

  28. 操作的最后结果将传递到从其调用 cmdlet 的管理界面。

配置数据库副本

在创建数据库副本之后,可以在需要时查看和修改其配置设置。通过在 EMC 中检查数据库副本的“属性”页,可以查看某些配置信息。还可以使用命令行中的 Get-MailboxDatabaseSet-MailboxDatabaseCopy cmdlet 来查看和配置数据库副本设置,如重播延迟时间、截断延迟时间和激活首选项顺序。有关查看和配置数据库副本设置的详细步骤,请参阅配置邮箱数据库副本属性

使用重播延迟和截断延迟选项

邮箱数据库副本支持使用“重播延迟时间”和“截断延迟时间”,这两个选项都是按分钟配置的。通过设置重播延迟时间,可以取回特定时间点的数据库副本。通过设置截断延迟时间,可以使用被动数据库副本上的日志来恢复在活动数据库副本上丢失的日志文件。因为这两个功能都会导致临时积累日志文件,所以使用其中任一功能都会影响存储设计。

重播延迟时间

重播延迟时间是邮箱数据库副本的属性,它以分钟为单位指定延迟数据库副本的日志重播。在日志文件复制到被动副本并成功通过检查之后,启动重播延迟计时器。通过延迟数据库副本日志重播,可以将数据库恢复到过去的某特定时间点。重播延迟时间配置为大于 0 的邮箱数据库副本称为滞后邮箱数据库副本,或简称为滞后副本

在 Exchange 2010 中使用数据库副本和诉讼保留功能的策略可以针对通常会导致数据丢失的故障范围提供保护。但是,这些功能无法在发生逻辑损坏的情况下为数据丢失提供保护,尽管逻辑损坏的情况很少见,但它会导致数据丢失。滞后副本旨在发生逻辑损坏的情况下防止数据丢失。通常,有两种类型的逻辑损坏:

  • 数据库逻辑损坏 数据库页校验和匹配,但页上的数据逻辑错误。当 ESE 尝试写入数据库页时,这种情况可能会发生,而且即使操作系统返回成功消息,也不能将数据写入磁盘或错误位置。这称为“丢失刷新”。若要防止丢失刷新丢失数据,ESE 在数据库中包括丢失刷新检测机制和页面修补功能(单页还原)。

  • 存储逻辑损坏 以用户不希望的方式添加、删除或操作数据。这些情况通常都是由第三方应用程序引起的。通常在用户将其看作损坏时才认为是损坏的。Exchange 存储会考虑产生一系列有效 MAPI 操作的逻辑损坏的事务。Exchange 2010 中的诉讼保留功能提供针对存储逻辑损坏的保护(因为它会阻止用户或应用程序永久地删除内容)。但也可能出现用户邮箱的损坏程度很严重的情况,此时更简单的操作是将数据库还原到损坏之前的某时间点,然后导出用户邮箱以检索未损坏的数据。

数据库副本、保留策略及 ESE 单页还原的组合可以仅留下少见但灾难性的存储逻辑损坏情况。是否使用具备重播延迟的数据库副本(滞后副本)将取决于所使用的第三方应用程序及组织的存储逻辑损坏的历史记录。

如果选择使用滞后副本,请注意有关其应用的含义:

  • 与 Exchange 2007 中的备用连续复制 (SCR)(设有 50 个日志文件的硬编码重播延迟)不同,滞后日志文件中没有硬编码编号。相反,重播延迟时间是管理员配置的值,默认情况下它是禁用的。

  • 重播延迟时间设置的默认设置为 0 天,最大设置为 14 天。

  • 不应将滞后副本视为高可用副本。它们旨在从灾难中恢复,以防止出现存储逻辑损坏情况。

  • 重播延迟时间越长,数据库恢复过程就越长。根据恢复期间需要重播的日志文件数以及硬件可以重播这些文件的速度,恢复数据库可能需要几小时或更长时间。

  • 我们建议您确定滞后副本是否对总体灾难恢复策略至关重要。如果它们的使用对您的策略至关重要,则我们建议使用多个滞后副本,或者使用独立磁盘 (RAID) 的冗余阵列保护单个滞后副本(如果没有多个滞后副本)。如果失去磁盘或出现损坏情况,则不会丢失滞后的时间点。

  • 使用 ESE 单页还原功能无法修补滞后副本。如果滞后副本发生数据库页损坏(例如 -1018 错误),则必须为其重新设定种子(这将丢失该副本的滞后内容)。

如果要数据库重播所有日志文件并使数据库副本当前可用,则很容易激活和恢复滞后的邮箱数据库副本。如果要重播截止到特定时间点的日志文件,操作将更加困难,因为您必须手动操作日志文件并运行 Eseutil 工具。

有关激活滞后的邮箱数据库副本的详细步骤,请参阅激活滞后的邮箱数据库副本

截断延迟时间

截断延迟时间是邮箱数据库副本的属性,它以分钟为单位指定在将日志文件重播到数据库副本后延迟删除数据库副本日志的时间量。在日志文件复制到被动副本、成功通过检查并成功重播到数据库副本之后,启动截断延迟计时器。通过从数据库副本延迟日志文件的截断,可以从影响数据库活动副本的日志文件的故障中恢复。

数据库副本和日志截断

日志截断在 Exchange 2010 中的功能与在 Exchange 2007 中一样。截断行为由副本的重播延迟时间和截断延迟时间决定。

当延迟设置保留其默认值 0(已禁用)时,必须满足以下条件才能截断数据库副本的日志文件。

  • 必须已成功备份日志文件,或者必须启用循环日志记录。

  • 日志文件必须在数据库检查点(恢复需要的最小日志文件)的下面。

  • 所有其他滞后副本必须检查该日志文件。

  • 所有其他副本(非滞后副本)必须重播在日志文件。

必须满足以下条件,才能对滞后数据库副本执行截断:

  • 在日志文件必须在数据库检查点的下面。

  • 日志文件必须早于 ReplayLagTime + TruncationLagTime。

  • 必须截断活动副本上的日志文件。

数据库激活策略

在某些情况下,您可能希望创建邮箱数据库副本,并阻止系统在出现故障的情况下自动激活该副本。例如:

  • 将一个或多个邮箱数据库副本部署到第二个或备用数据中心时。

  • 为恢复将数据库副本配置为滞后副本时。

  • 正在执行服务器的维护或升级时。

在上述每种情况下,您都具有不希望系统自动激活的数据库副本。若要阻止系统自动激活邮箱数据库副本,您可以将该副本配置为阻止激活(挂起)。这允许系统通过日志传送和重播维护数据库的货币,但会阻止系统自动激活并使用该副本。阻止激活的副本必须由管理员手动激活。使用 Set-MailboxServer cmdlet 将 DatabaseCopyAutoActivationPolicy 参数设置为“已阻止” ,可以配置数据库激活策略。

有关配置数据库激活策略的详细信息,请参阅配置邮箱数据库副本的激活策略

平衡数据库副本

由于 DAG 的固有性质,数据库切换和故障转移会导致活动邮箱数据库副本在 DAG 的生存期内多次更改主机。因此,DAG 在活动邮箱数据库副本分布方面可能变得不平衡。下表显示了一个主动数据库副本分布不平衡的 DAG 示例,该 DAG 具有四个数据库,每个数据库有四个副本(每个服务器上总共有 16 个数据库)。

主动副本分布不平衡的 DAG

服务器 活动数据库数 被动数据库数 装入的数据库数 卸除的数据库数 首选项计数列表

EX1

5

11

5

0

4, 4, 3, 5

EX2

1

15

1

0

1, 8, 6, 1

EX3

12

4

12

0

13, 2, 1, 0

EX4

1

15

1

0

1, 1, 5, 9

在上面的示例中,每个数据库有四个副本,因此激活首选项只有四个可能值(1、2、3 或 4)。“首选项计数列表”列显示与其中的每个值对应的数据库计数。例如,在 EX3 上,对于激活首选项 1 有 13 个数据库副本,对于激活首选项 2 有 2 个副本,对于激活首选项 3 有 1 个副本,对于激活首选项 4 没有副本。

如您所见,此 DAG 在每个 DAG 成员托管的活动数据库数、每个 DAG 成员托管的被动数据库数或托管数据库的激活首选项计数方面并不平衡。

可以使用 RedistributeActiveDatabases.ps1 脚本在 DAG 中平衡活动邮箱数据库副本。此脚本会使数据库在其副本之间进行移动,以尝试使 DAG 中每个服务器上装入的数据库数量相等。如有必要,该脚本还尝试在站点间平衡活动数据库。

该脚本为在 DAG 中平衡主动数据库副本提供了两种选项:

  • BalanceDbsByActivationPreference   指定此选项时,该脚本会尝试将数据库移动到其第一首选副本(基于激活首选项),而不考虑 Active Directory 站点。

  • BalanceDbsBySiteAndActivationPreference   指定此选项时,该脚本会尝试将活动数据库移动到其第一首选副本,同时还尝试在每个 Active Directory 站点中平衡活动数据库。

使用第一个选项运行该脚本之后,先前不平衡的 DAG 会达到平衡,如下表所示。

主动副本分布平衡的 DAG

服务器 活动数据库数 被动数据库数 装入的数据库数 卸除的数据库数 首选项计数列表

EX1

4

12

4

0

4, 4, 4, 4

EX2

4

12

4

0

4, 4, 4, 4

EX3

4

12

4

0

4, 4, 4, 4

EX4

4

12

4

0

4, 4, 4, 4

如上表所示,现在此 DAG 在每个服务器上的活动数据库数和被动数据库数以及服务器间的激活首选项方面达到平衡。

下表列出了 RedistributeActiveDatabases.ps1 脚本的可用参数。

RedistributeActiveDatabases.ps1 脚本参数

参数 描述

DagName

指定要重新平衡的 DAG 的名称。如果省略此参数,则会使用本地服务器所属的 DAG。

BalanceDbsByActivationPreference

指定该脚本应将数据库移动到其第一首选副本,而不考虑 Active Directory 站点。

BalanceDbsBySiteAndActivationPreference

指定该脚本应尝试将活动数据库移动到其第一首选副本,同时还尝试在每个 Active Directory 站点中平衡活动数据库。

ShowFinalDatabaseDistribution

指定在重新分布完成后显示当前数据库分布的报告。

AllowedDeviationFromMeanPercentage

指定站点间活动数据库的允许变化率,以百分比形式表示。默认为 20%。例如,如果三个站点之间分布了 99 个数据库,则理想分布应是每个站点中包含 33 个数据库。如果允许变化率为 20%,则该脚本会尝试平衡数据库,以便每个站点包含的数据库数与此数字相比,上下不超过 10%。33 的 10% 是 3.3,向上舍入为 4。因此,该脚本会尝试使每个站点包含 29 至 37 个数据库。

ShowDatabaseCurrentActives

指定该脚本为每个数据库生成一个报告,该报告详细说明数据库的移动方式以及它在其第一首选副本上现在是否处于活动状态。

ShowDatabaseDistributionByServer

指定该脚本为每个服务器生成一个报告,该报告显示服务器的数据库分布。

RunOnlyOnPAM

指定该脚本仅在当前具有 PAM 角色的 DAG 成员上运行。该脚本验证其是否从 PAM 运行。如果它不是从 PAM 运行,则该脚本会退出。

LogEvents

指定该脚本记录事件(MsExchangeRepl 事件 4115),其中包含操作摘要。

IncludeNonReplicatedDatabases

指定该脚本在确定如何重新分布活动数据库时应包括非复制数据库(没有副本的数据库)。虽然无法移动非复制数据库,但是这些数据库可能会影响复制数据库的分布。

RedistributeActiveDatabases.ps1 示例

此示例演示某个 DAG 的当前数据库分布,包括首选项计数列表。

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

此示例使用激活首选项在 DAG 中重新分布和平衡活动邮箱数据库副本。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

此示例使用激活首选项在 DAG 中重新分布和平衡活动邮箱数据库副本,并生成分布摘要。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

监视数据库副本

如果发生影响数据库活动副本的故障,数据库副本是第一个防御措施。因此,若要确保数据库副本在需要时可用,则监视其运行状况和状态至关重要。通过在 EMC 中检查数据库副本的“属性”页,可以查看某些运行状况和状态信息。还可以使用命令行中的 Get-MailboxDatabaseCopyStatus cmdlet 来查看数据库副本的各种状态信息。

有关监视数据库副本的详细信息,请参阅监视高可用性和站点恢复

删除数据库副本

使用 EMC 或命令行中的 Remove-MailboxDatabaseCopy cmdlet 可以随时删除数据库副本。删除数据库副本之后,必须手动从删除数据库副本的服务器上删除任何数据库和事务日志文件。有关删除数据库副本的详细步骤,请参阅删除邮箱数据库副本

数据库切换

承载数据库活动副本的邮箱服务器称为“邮箱数据库主机”。激活被动数据库副本的过程会更改数据库的邮箱数据库主机,并将被动副本转换为新的主动副本。此过程称为数据库“切换”。在数据库切换,在一个邮箱服务器上卸除数据库的活动副本,并该数据库的被动副本装入另一个邮箱服务器上的新活动邮箱数据库。执行切换时,可以选择覆盖新邮箱数据库主机上的数据库装入拨号设置。

通过检查 EMC 中的“数据库副本”选项卡下的“复制状态”列,可以快速标识哪个邮箱服务器是当前邮箱数据库主机。只有活动副本的状态才是“已装入”。所有其他数据库副本将显示数据库副本的当前复制状态。使用 EMC 中的移动邮箱数据库主机向导或命令行中的 Move-ActiveMailboxDatabase cmdlet 可以执行切换。

在激活被动副本之前,需执行几个内部检查:

  • 检查数据库副本的状态。如果数据库副本处于失败状态,则阻止切换。使用 Move-ActiveMailboxDatabase cmdlet 的 SkipHealthChecks 参数可以覆盖此行为并绕过运行状况检查。此参数允许在失败状态中将活动副本移动到数据库副本。

  • 检查数据库副本的复制队列和重播队列长度,以确保它们的值符合已配置的条件。此外,还验证数据库副本,以确保当前未将其用作种子设定源。如果队列长度的值超出已配置的条件,或者数据库当前用作种子设定源,则阻止切换。使用 Move-ActiveMailboxDatabase cmdlet 的 SkipLagChecks 参数可以覆盖此行为并绕过这些检查。此参数允许要激活的副本具有超出已配置条件的重播队列和复制队列。

  • 检查数据库副本的搜索目录(内容索引)的状态。如果搜索目录不是最新的且运行状况不正常或已损坏,则阻止切换。使用 Move-ActiveMailboxDatabase cmdlet 的 SkipClientExperienceChecks 参数可以覆盖此行为并绕过搜索目录检查。此参数将导致搜索跳过目录运行状况检查。如果正在激活的数据库副本的搜索目录处于不正常运行状况或不可用状态,并且使用此参数跳过目录运行状况检查和激活数据库副本,则需要重新对搜索目录进行爬网或设定种子。

执行数据库切换时,还可以覆盖装入拨号设置,这些设置是为承载正在激活的被动数据库副本的服务器而配置的。使用 Move-ActiveMailboxDatabase cmdlet 的 MountDialOverride 参数指示目标服务器覆盖自己的装入拨号设置,并且使用这些由 MountDialOverride 参数指定的设置。

有关执行数据库副本切换的详细步骤,请参阅激活邮箱数据库副本。有关数据库切换的详细信息,请参阅切换和故障转移

 © 2010 Microsoft Corporation。保留所有权利。