管理备用连续复制

适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

上一次修改主题： 2008-11-19

除了 Microsoft Exchange 组织的日常管理任务之外，还有一些针对备用连续复制 (SCR) 的任务。通常，SCR 的管理任务包括：

• 为 SCR 配置磁盘存储以及管理磁盘卷。

• 启用和禁用 SCR。

• 监视复制活动。

• 装入、卸除、创建和删除数据库。

• 存储组启用 SCR 时移动存储组或数据库文件的存储位置。

• 验证 SCR 目标的运行状况

• 管理复制和重播活动。

• 从损坏状态中恢复。

本主题的后续部分介绍了这些任务。

只能通过使用 Exchange 命令行管理程序来启用和管理 SCR。Exchange 管理控制台无法用于启用或禁用 SCR、查看 SCR 状态或管理 SCR 的各个方面。

为备用连续复制配置磁盘存储

SCR 不需要专门配置的磁盘存储。SCR 要求存储可以提供足够的容量。应为针对同一存储组配置的所有 SCR 目标配置相当的存储解决方案。建议按照存储供应商提供的配置步骤完成配置。

在 SCR 环境中管理磁盘卷

在管理 SCR 环境时，可能需要管理连接到 Exchange 服务器的磁盘卷。例如，可能由于维护或其他原因而需要使该卷临时与系统分离。如果需要维护包含存储组主动副本的磁盘卷，应卸除存储组主动副本中的数据库。如果需要维护包含存储组被动副本的磁盘卷，应通过暂停复制来停止相应卷的所有输入/输出 (I/O)。有关管理磁盘卷的详细信息，请参阅使用 SCR 时如何准备磁盘管理活动。

启用备用连续复制

SCR 只能通过使用 Exchange 命令行管理程序以及运行 New-StorageGroup cmdlet 或 Enable-StorageGroupCopy cmdlet 进行启用。这两个 cmdlet 包括 Microsoft Exchange Server 2007 Service Pack 1 (SP1) 引入的一些新参数：

• -StandbyMachine 此参数用于指定将包含 SCR 目标的计算机的名称。此参数值作为 SCR 启用的存储组的 msExchStandbyCopyMachines 属性值的一部分设置。msExchStandbyCopyMachines 属性是一个多值 Unicode 字符串，在将 Exchange 2007 SP1 引入到 Exchange 组织时该字符串被添加到 Active Directory 目录服务架构中。

• -ReplayLagTime   此参数用于指定在重播已复制到 SCR 目标计算机的日志文件之前，Microsoft Exchange 复制服务应等待的时间。此参数的格式为（天数.小时数:分钟数:秒数）。此参数的默认设置是 24 小时。此参数允许的最大设置是 7 天。允许的最小设置是 0 秒，将此值设置为 0 秒不影响 50 个日志文件重播活动的默认延迟。设置完成后，此参数值在没有禁用和再启用 SCR 的情况下无法更改。

• -TruncationLagTime   此参数用于指定在截断已复制到 SCR 目标计算机并已重播到数据库副本的日志文件之前，Microsoft Exchange 复制服务应等待的时间。此时段是从日志成功地在数据库副本中重新显示后开始的。此参数的格式为（天数.小时数:分钟数:秒数）。此参数允许的最大设置是 7 天。允许的最小设置是 0 秒，将此值设置为 0 秒可有效地消除日志截断活动的任何延迟。设置完成后，此参数值在没有禁用和再启用 SCR 的情况下无法更改。

• -SeedingPostponed 使用此参数可以跳过 SCR 目标的初始种子设定。如果使用此参数，管理员必须使用 Update-StorageGroupCopy cmdlet 为 SCR 目标手动设定种子。此参数只能与 Enable-StorageGroupCopy cmdlet 一起使用。它无法与 New-StorageGroup cmdlet 一起使用，因为此时不存在源数据库。

  要点：
  若要更改重播或截断延迟设置，必须先禁用 SCR，然后使用这些设置的新值启用 SCR。

除了使用 ReplayLagTime 参数指定的管理员配置重播延迟之外，Exchange 还阻止一定数量的日志文件在 SCR 目标上重播，无论 ReplayLagTime 的值是否使用以下公式：

Maximum of ("value of ReplayLagTime" or "X log files")

其中 X=50。这是对需要重新设定存储组种子情况的额外保护，这种情况产生于 SCR 源处于连续复制环境（例如，本地连续复制 (LCR) 或群集连续复制 (CCR)）遭遇丢失数据故障转移，并使用 Restore-StorageGroupCopy cmdlet 进入联机时。通过在 SCR 目标上延迟重播活动，当发生 SCR 源丢失数据故障转移时，需要重新设定 SCR 副本种子的可能性降到了最低，因为 SCR 源数据丢失的实质是没有及时将两个副本更紧密地放在一起。

要点：
50 个日志文件的的内置滞后时间，以及 ReplayLagTime 参数的值都会影响初始 SCR 目标数据库的创建。在 50 个事务日志文件被复制到 SCR 目标计算机，并且超过 ReplayLagTime 指定的时间（或 ReplayLagTime 默认的 24 小时）时，才会创建 SCR 目标数据库。

对存储组启用 SCR 时，将使用与 SCR 源上存储组相同的路径在 SCR 目标计算机上自动创建和维护存储组（系统文件、日志文件和数据库文件）的副本。

启用 SCR 之后，建议使用 Test-ReplicationHealth cmdlet 监视每个存储组的运行情况和状态。有关如何启用 SCR 的详细步骤，请参阅如何为现有存储组启用备用连续复制和如何为新存储组启用备用连续复制。

SCR 和日志截断

由于无法对目标数据库进行备份，因此，SCR 日志截断并不基于备份时间而执行，而是由 SCR 源的检查点和 TruncationLagTime 的值确定。

如果 SCR 源是 CCR 环境中的群集邮箱服务器 (CMS)，则日志截断逻辑包括由所有 SCR 目标成功复制和检查的日志文件。这意味着如果 SCR 目标不可用，则即使进行备份，SCR 源上也不发生日志截断。

在 SCR 环境中，如果所需的日志文件都可用，则根据下列情况，禁用后再启用的目标可能不需要重新设定种子：

• 如果对存储组启用循环日志记录，则日志删除将导致因日志序列间隙而使启用的 SCR 目标需要重新设定种子。

• 如果进行备份时包括日志文件截断，则日志删除将导致因日志序列间隙而使启用的 SCR 目标需要重新设定种子。

如果没有通过上述任一方法截断日志文件，则禁用后再启用的 SCR 就不需要重新设定种子。这种情况下，需要删除 SCR 目标处的日志文件，但它们将会从 SCR 源重新复制。

如果计划启用以前禁用的 SCR 目标，建议的最佳做法是，在启用 SCR 目标和在整个 Active Directory 中复制需要该启用的配置更改之前，不执行任何日志截断操作（例如，启用循环日志记录或执行日志截断备份）。

禁用备用连续复制

只能通过使用 Disable-StorageGroupCopy cmdlet 和 StandbyMachine 参数来禁用 SCR。禁用 SCR 时，包含 StandbyMachine 参数的适当值很重要。如果 SCR 源存储组还启用了 LCR，但您没有将 StandbyMachine 参数包含进此命令，将对该存储组禁用 LCR。

必须禁用 SCR 才能更改 ReplayLagTime 或 TruncationLogDelay 参数的值。启用 SCR 时无法修改这些值。因此，若要更改重播或截断延迟设置，必须先禁用 SCR，然后使用这些设置的新值重新启用 SCR。

有关如何为存储组禁用 SCR 的详细步骤，请参阅如何禁用存储组的备用连续复制。

监视复制活动

虽然 SCR 不要求任何特殊的监视，但是仍建议定期监视每个存储组以验证其是否正确地复制日志文件。Microsoft Exchange Server 2007 Management Pack for Microsoft Operations Manager 2005 包含与 SCR 环境相关的多个关键问题的警报：

• Microsoft Exchange 复制服务未运行。请注意，在服务停止后，生成此警报的事件不会重复出现，因此如果将其清除，任何与其关联的警报都将丢失。

• SCR 目标副本处于“Failed”状态。

• SCR 目标副本处于“Healthy”状态，但日志复制滞后。

应尽快查明并解决 Exchange 2007 Management Pack 生成的以上任何警报。

Test-ReplicationHealth Cmdlet

Exchange 2007 SP1 引入了一个名为 Test-ReplicationHealth 的新 cmdlet。此 cmdlet 旨在对连续复制（LCR、CCR 和 SCR）和连续复制管道进行主动监视。Test-ReplicationHealth cmdlet 检查复制、群集服务、存储组复制和重播状态的各个方面，以此来提供整个复制系统的总体情况。具体来说，Test-ReplicationHealth cmdlet 执行下表所述的各项测试。

由 Test-ReplicationHealth cmdlet 执行的测试

装入和卸除数据库

在 SCR 环境中，有时可能需要装入或卸除数据库。如果需要重新配置或维护 SCR 源存储组或数据库，必须在活动发生期间阻止两者间交互的服务。如果要执行重新配置或纠正服务器或数据库问题，则可能需要执行此操作。卸除数据库后，所用户都无法访问该数据库。

移动存储组文件和数据库文件的位置

可以更改启用了 SCR 存储组中的数据库的位置。在 SCR 环境中有两个数据库文件，各有一个副本。移动存储组文件或数据库文件时，两个副本的位置必须一起更改。

注意：
在 SCR 源和所有 SCR 目标上，存储组文件或数据库文件的完整路径必须一致。

可以使用类似的步骤重新配置 SCR 环境中存储组日志文件和系统文件的位置以及数据库文件的位置。 有关如何更改启用了 SCR 的存储组的日志文件和系统文件位置的详细步骤，请参阅如何在备用连续复制环境中移动存储组。有关如何更改 SCR 环境中数据库文件位置的详细步骤，请参阅如何在备用连续复制环境下移动数据库。

要点：
无法将数据库放在卷的根目录。

查看状态信息

使用 Exchange 命令行管理程序执行所有监视和状态。Exchange 管理控制台不显示 SCR 的副本状态或和任何其他信息。对存储组启用 SCR 之后，可以使用 Exchange 命令行管理程序来查看存储组及其数据库的 SCR 特定的配置设置。

备用连续复制的状态信息

Exchange 2007 会发布 SCR 副本的多种状态信息。下表介绍启用了 SCR 的存储组的相关状态信息。有关说明如何获取状态信息的详细步骤，请参阅如何查看备用连续复制的状态。

注意：
下表按属性在 Get-StorageGroupCopyStatus cmdlet 完整输出中的显示顺序列出了这些属性。

启用 SCR 的存储组的可用状态信息

通过查看 SummaryCopyStatus、CopyQueueLength、ReplayQueueLength 和 LastInspectedLogTime 的值，可以快速估计 SCR 副本的运行状况。这些属性显示 SCR 副本是否正常运行以及 SCR 副本在复制日志和重播日志中是否相对最新。如果发生下列情况，应当确定原因并纠正问题：

• 副本长时间处于非正常状态。

• 复制队列长度大于 5。

• 重播队列长度大于 20。

• 上一个检查日志时间不是当前时间。有两种原因可能导致出现该问题：存储组没有太大变化或复制服务已停止。

重播队列长度值和副本队列长度值可用作性能计数器。它们是 MSExchange Replication 性能对象下的 CopyQueueLength 和 ReplayQueueLength 性能计数器。

在某些极少出现的情况下，复制状态可能使人产生误解。以下是这些情况的列表：

• 非活动（即没有正在发生变化）存储组可能会在不正常时报告正常。由于直到重播日志时才能检测到不正常的情况，因此可能会发生这种情况。

• 在复制的初始化期间，由于要评估复制状态，因此复制状态可能不准确。初始化完成后，状态得以更新。

• 卸除数据库后，LastLogGenerated 字段的值可能是错误的。但是，如果存储组副本正在复制，则会复制所有记录了最终用户内容的日志。

• 当日志流中缺少一个或多个日志时，被动副本仍继续尝试恢复。执行此操作时，复制状态会在失败状态和正常状态之间切换。重播队列和复制队列将继续增长。

• 在某些极少出现的情况下，日志可以被成功验证但可能仍然无法重播。在这种情况下，系统在尝试恢复时将在失败状态和正常状态之间交替切换。重播队列和复制队列将继续增长。

验证 SCR 目标的完整性

使用 SCR 时，建议您通过对数据库和事务日志文件运行物理一致性检查，定期验证每个 SCR 目标副本的完整性。物理一致性检查会检查事务日志文件和数据库文件是否损坏。可以通过使用命令行版本的 Microsoft 卷影复制服务工具 (VSSAdmin.exe) 和 Exchange Server 数据库实用程序 (Eseutil.exe) 来执行该检查。有关如何使用 VSSAdmin 和 Eseutil 来检查事务日志和数据库文件是否有物理损坏的详细步骤，请参阅如何验证备用连续复制副本。

注意：
对数据库运行物理一致性检查之前，必须暂时挂起对存储组执行的所有复制活动。可以在 Exchange 命令行管理程序中使用 Suspend-StorageGroupCopy cmdlet 来挂起复制活动。完成一致性检查后，可以使用 Resume-StorageGroupCopy cmdlet 恢复事务日志重播活动。建议在非工作时间执行验证，并最大限度减少挂起重播活动的时间长度。这是因为挂起存储组复制会暂停对 SCR 副本的所有更新，因此，会导致某些内容容易出现故障。

管理复制和重播

在 SCR 环境中管理日志文件的复制和重播主要涉及下列活动：

• 暂停向存储组副本的复制

• 重新启动向存储组副本的复制

• 重新设定存储组种子

暂停和重新启动对存储组副本及其数据库的更改

由于各种原因，可能需要暂停和重新启动事务日志复制活动。如果 Microsoft Exchange 复制服务正在运行、已对存储组启用了 SCR 并且 SCR 源和 SCR 目标均正常，这时会进行事务日志复制。如果 SCR 源或 SCR 目标不可用，则必须停止复制。此外，某些管理任务（例如种子设定）要求为启用了 SCR 的存储组挂起复制。如果需要停止对目标的数据文件的所有访问，必须挂起复制。

有时可能需要控制 SCR 目标的活动。在执行重新配置或解决服务器或数据库出现的问题时，可能需要执行此操作。若要对 SCR 目标执行物理一致性检查，还需要暂停日志重播。如果需要控制数据库副本更新，必须暂停对 SCR 目标的复制。出于任何原因要处理 SCR 目标的日志时，可能也需要暂停复制。

有关暂停对 SCR 副本的复制更改的详细信息，请参阅如何挂起对备用连续复制目标的更改。有关重新启动对 SCR 副本的复制更改的详细信息，请参阅如何恢复备用连续复制目标的复制。有关对被动副本的事务日志文件和数据库文件执行完整性检查的详细信息，请参阅如何验证备用连续复制副本。

为存储组副本设定和重新设定种子

在 SCR 环境中，使用 Update-StorageGroupCopy cmdlet 和 StandbyMachine 参数（该参数是 Exchange 2007 SP1 中新添加的参数）为存储组副本设定和重新设定种子。

有关如何设定或重新设定 SCR 目标种子的详细步骤，请参阅如何将备用连续复制目标设定为种子。

通过在损坏时评估复制状态从损坏状态中恢复

数据库副本出现故障或损坏之后，需要评估是否要立即使用 SCR 目标继续操作。SCR 提供一些关键信息来帮助做出此决定：

• 副本在出现故障时的运行状况

• 出现故障时的重播队列和复制队列

• 出现故障时上次检查日志的时间

可以使用 Get-StorageGroupCopyStatus cmdlet 获取此信息。有关如何获取此信息的详细步骤，请参阅如何查看备用连续复制的状态。

注意：
上一个检查日志时间提供有关 SCR 源最新更改的信息。这有助于检测在未启动 Microsoft Exchange 复制服务时发生的故障，因为 Microsoft Exchange 复制服务停止时，队列长度不准确。

复制队列长度包含出现故障时最适合使用的 SCR 源信息。必须根据该信息以及估计的故障数据库恢复时间，决定是否要激活可用 SCR 目标：

• 如果重播队列很长，可能需要一定时间恢复，但是并不表示会丢失大量数据。

• 如果复制队列很长，则会丢失大量日志。如果数据库已激活，将还原到上一个复制的日志的大致时间段（也通过 Get-StorageGroupCopyStatus cmdlet 提供）。

• 如果上一个检查日志时间明显早于出现故障的时间，则很可能 Microsoft Exchange 复制服务已停止，并且其他队列信息是不准确的。

  注意：
  由于 SCR 的性质，以及外部延迟和通信故障，复制队列长度可能是不准确的，因为主动副本的当前状态是异步更新的。通常，仅在出现故障前后的大概一分钟内会出现不准确的情况。

  注意：
  故障数据库无法用于设定 SCR 目标的种子。