计划中断和未计划中断
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上一次修改主题： 2007-10-29
计划中断和未计划中断是群集连续复制 (CCR) 环境中的中断的两种形式。计划中断是管理员明确启动的，用以从故障中恢复或执行维护操作。未计划中断指可导致服务和/或数据不可用的异常事件。CCR 设计为可处理计划中断和未计划中断。
计划中断
通过 CCR，可以将特定节点计划为长时间发生系统中断，但群集邮箱服务器 (CMS) 不会长时间中断。CCR 计划中断功能可以确保主动节点上的所有日志数据成功复制到被动节点上。因此，即使发生异步复制，计划中断也始终不会有数据损失。故障及其导致的故障转移会导致被动节点在联机时无法获得非常新的日志数据。
在 CCR 环境中，一次只能使一个节点脱机。使多个节点脱机会导致服务中断。可以在任何特定时间，使为包含文件共享见证的多数节点集 (MNS) 仲裁托管文件共享的计算机脱机，或使故障转移群集中的被动节点脱机，以便进行硬件和软件的维护、更新和修复。我们建议您，在没有先检查节点是否处于活动状态或是否驻留资源的情况下，永不使该节点脱机。可以使用群集管理器来确定节点是否驻留了任何资源。可通过在 Exchange 命令行管理程序中运行 Get-ClusteredMailboxServerStatus cmdlet 来检查节点状态。有关查看 CMS 的状态的详细信息，请参阅如何查看群集邮箱服务器的状态。
.gif "note") 注意： |
|---|
| CCR 计划中断支持没有与 Windows Server 关机进程进行集成。在关闭主动节点之前，必须将 CMS 移动到其他节点。有关说明如何在节点之间移动 CMS 的详细步骤，请参阅如何在 CCR 环境中移动群集邮箱服务器。 |
管理任务
计划中断是管理员明确启动的，用以从故障中恢复或执行维护操作。计划中断允许系统将 CMS 从主动节点移动到被动节点（从而使被动节点成为新的主动节点），然后装入复制的数据库和存储组。被装入之后，数据库将成为用于任何后继复制的所有后续更新的源。两个副本会切换复制角色，即一个副本将产生数据库更改，另一个副本将接收和应用数据库更改。
由于 CCR 使用异步复制，因此，群集中节点之间的主动 CMS 的传输会要求在群集和复制支持之间进行协调。CCR 可实施这样的协调。管理员可通过在 Exchange 命令行管理程序中使用 Move-ClusteredMailboxServer cmdlet 来启动计划中断。
| 注意： |
|---|
| 执行此操作将会导致服务瞬间中断。此外，还会停止 CMS 上任何存储组的任何备份。 |
Move-ClusteredMailboxServer cmdlet 会验证被动节点是否具有有效和状况良好的副本。另外，它会进行检查以确保该副本是相对较新的。如果该副本不是相对较新的，则当完成复制时可能会发生长时间的中断。如果这些检查都是成功的，则会启动传输。如果在移动过程中没有发生故障，则当 CMS 在所选节点上运行且所有数据库都被装入时，任务即告完成。在此过程中可能发生阻止传输或影响是否可自动装入所有数据库的故障。如果发生了上述故障，则将接替进行未计划中断行为。
在某些情况下，计划中断可用于恢复部分故障的服务器，例如，一个带有损坏的数据库或日志文件的服务器。在此情况下，通过复制系统发送日志的逻辑会阻止执行 Move-ClusteredMailboxServer cmdlet。管理员可通过使用一个简单的选项来管理此方案。管理员可卸除有问题的数据库，然后发出带有一个选项的 Move-ClusteredMailboxServer 命令，该选项可尝试复制与卸除的数据库相关联的日志，但在无法复制所有日志的情况下移动不会失败。这样，使用 Move-ClusteredMailboxServer cmdlet 就可轻松完成恢复（甚至是已损坏的存储组的恢复）。
Move-ClusteredMailboxServer cmdlet 允许管理员记录启动移动的原因。此原因会放入事件日志中。该命令还强制管理员指定要驻留 CMS 的节点。这会防止管理员在 CMS 已被正确驻留的情况下错误地移动它。
Cluster.exe 命令行管理界面和群集管理员图形用户界面 (GUI) 都包含移动 CMS 的功能。使用这些方法可触发复制刷新逻辑。但是，建议您不要使用这些方法，原因如下：
这些方法不会验证被动副本的运行状况或状态。这样，使用这些方法可导致当节点执行必要的操作以使数据库可装入时，产生长时间的中断。
这些方法还可能会使数据库由于复制处于中断状况而无限期脱机。
计划中断结束之后还原复制活动
在主动节点的计划中断结束之后还原 CCR 环境的过程为重新启动节点。启动系统时会自动启动复制。请考虑下列两种情况：
计划中断是完全成功的（在与计划中断相关联的传输过程中未显示任何故障），并且所有的数据库都已自动联机。在这种情况下，管理员在确保两个节点具有一致的存储组和数据库的情况下执行计划中断。结果为节点可以启动并可立即继续进行复制。可以通过重播日志使副本内容保持最新。不需要任何特殊操作。
计划中断仅部分成功，或者一些数据库在计划中断之前已损坏。在这种情况下，计划中断无法确保目标在装入其数据库之前可以使用源上的所有日志。通常，如果在计划中断之前或在计划中断操作后期出现故障，则会发生这种情况。因此，源数据库和目标数据库将会不一致。在某些情况下，CCR 可自动从某些不一致状况中恢复过来。如果发生该情况，则复制将会启动并处理任何可用日志。如果复制无法自动进行恢复，则会将副本标记为已损坏并会生成表明该问题的事件。如果存储可用，则主要的恢复操作就是重新将副本设定为种子。有关纠正这些问题的步骤的详细信息，请参阅如何将群集连续复制副本设定为种子。
未计划中断
未计划中断是对某些类型的故障产生的自动系统响应。CCR 会将自动恢复侧重于某些情况下存在的故障，在这些情况下，提高可用性的可信程度较高，或者大多数环境都期望进行自动恢复。
未计划中断允许系统激活被动节点上的邮箱服务器，从而将其设置为主动，然后装入复制的数据库和存储组。被装入之后，数据库将成为用于任何后继复制的所有后续更新的源。两个副本会切换复制角色，即一个副本产生数据库更改，另一个副本接收和应用数据库更改。
由于 CCR 使用异步复制，因此，未计划中断意味着将发生某些数据丢失。至少，主动服务器正在主动写入的日志会不可用于恢复活动。通过提供对故障转移行为的管理控制和提供有助于回收可能受到影响的大量数据的功能，CCR 解决了此问题。
发生故障转移时，CCR 总是会激活其余被动节点上的邮箱服务器。系统控制与是否在此当前主动节点上装入数据库相关联。CCR 提供了可决定是否装入数据库的管理控制。默认位置是“Best availability”。在此情况下，系统将自动装入与以前的主动生产数据库同步的所有数据库。“Best availability”允许两个副本之间存在更加多样的不一致性。如果在生成新的日志期间，“Good availability”会使数据库联机，则会复制最后生成的日志。“Lossless”可以保证：除非可确认副本将不会有数据丢失，否则不会将其联机。如果使用了“Lossless”，则仅在原始服务器已重新正常运行、所有日志数据均可用且未损坏的情况下，才会发生自动恢复。
| 注意： |
|---|
| “Lossless”设置的使用会导致长时间的中断。管理员可使用“Lossless”设置，然后对是否要装入数据库做出明确决定。“Lossless”设置可轻易地导致针对故障的长时间的中断。 |
如果一个或多个数据库处于设置不会自动将其装入的情况下，则管理员仍可根据副本的可用内容明确决定装入副本。管理员必须检查副本的状态，然后发出两条命令。第一条命令会通知复制引擎应使此副本成为复制源（更改的来源），即该副本应可装入。第二条命令会装入数据库。
有关在启用了 CCR 的情况下从损坏或故障中恢复的其他信息，请参阅管理群集连续复制。
管理控制
提供管理控制是为了控制出现未计划中断时的行为。CCR 为邮箱服务器提供了可用于控制未计划中断恢复行为的属性。该属性 AutoDatabaseMountDial 具有三个可能的值：Lossless、Good availability 和 Best availability。
Lossless Lossless 表示丢失的日志数为 0。属性设置为“Lossless”时，大多数情况下，系统将等到故障节点重新联机后再装入数据库。尽管那样，故障的系统返回时其所有日志也都必须可访问并且未损坏。发生故障之后，被动节点会成为主动节点，并使 Microsoft Exchange Information Store 服务联机。它将通过检查来确定是否可装入数据库而不造成任何数据丢失。如果可以，则装入数据库。如果不能，则系统会定期尝试复制日志。如果服务器返回时其日志保持原样，则该尝试最终会成功，数据库将进行装入。如果服务器返回时其日志未保持原样，则其余日志将不可用，受影响的数据库将不会进行装入。
注意：在完成故障转移后的任何时刻，管理员都可以进行介入并决定使用以前被动节点上的可用数据库和日志进行装入。可使用一个简单的两步过程来完成此任务。假设决定进行介入的管理员基于对使原始服务器正常运行所需时间量的分析来做出该决定，那么，发生故障时两个节点之间的复制的一致性和客户端对其服务器进行访问的紧急性，是属于此分析的一部分的一些因素。 Good availability Good availability 表示丢失的日志数为 3。“Good availability”可在复制正在正常进行且正以日志生成的速率复制日志时进行完全的自动恢复。
Best availability Best availability 表示丢失的日志数为 6，这是默认设置。“Best availability”的功能类似于“Good availability”的功能，但“Best availability”允许在复制延迟时间稍长时进行自动恢复。这样，在故障转移之后，新的主动节点的状态可能会稍微落后于旧的主动节点的状态，因此增加了数据库出现分歧的可能性，这需要完全重新设定种子来更正。
有关中断管理行为的详细信息，请参阅如何优化群集连续复制的故障转移和装入设置。