通过

管理本地连续复制

  • 项目

 

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

上一次修改主题： 2007-08-20

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

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

  • 启用和禁用 LCR。

  • 监视复制活动。

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

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

  • 查看已启用 LCR 的存储组或数据库的状态和配置信息。

  • 验证 LCR 数据的主动副本或被动副本的运行状况。

  • 管理复制和重播活动。

  • 激活被动副本。

为本地连续复制配置磁盘存储

LCR 不需要专门配置的磁盘存储。建议尽可能将副本相互隔离。LCR 要求存储可以提供足够的性能和存储容量。应为已启用 LCR 的存储组和数据库的两个副本配置相当的存储解决方案。另外还建议按照存储供应商提供的配置步骤完成配置。

管理磁盘卷

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

启用本地连续复制

使用 LCR 从对存储组启用 LCR 开始。可以使用 Exchange 管理控制台或 Exchange 命令行管理程序完成此任务。

note注意：
对存储组启用 LCR 后，将在为 LCR 副本指定的位置创建和自动维护存储组中的第二个数据库副本。
important要点：
启用 LCR 之前，请确保有足够的磁盘空间存储 LCR 副本。

若要使用 LCR，需要对存储组启用 LCR。有关如何对现有存储组启用 LCR 的详细步骤，请参阅如何为现有存储组启用本地连续复制。有关如何新建启用 LCR 的存储组的详细步骤，请参阅如何为新存储组启用本地连续复制。

禁用本地连续复制

可以使用 Exchange 管理控制台或 Exchange 命令行管理程序对存储组禁用 LCR。有关如何禁用 LCR 的详细步骤，请参阅如何禁用本地连续复制。

important要点：
删除包含 LCR 副本的存储组，将删除 LCR 副本和生产副本。

调整传输转储程序的默认配置

“传输转储程序”是集线器传输服务器角色的一项功能，用于在意外中断之后提交最近传递的邮件。集线器传输服务器维护最近传递到邮箱的邮件队列：

  • 在 CCR 环境的群集邮箱服务器中

  • 在启用 LCR 的存储组中

使用群集连续复制 (CCR) 或 LCR 时，始终应打开传输转储程序。通过设置每个存储组可用的存储空间量并设置在传输转储程序中保留邮件的时间，可以在整个组织范围启用传输转储程序。

可以使用 Set-TransportConfig cmdlet 更改传输转储程序的默认配置设置，这些设置在存储组级别进行应用。

我们建议将 MaxDumpsterSizePerStorageGroup 参数（该参数指定每个存储组的传输 dumpster 队列的最大大小）配置为可以发送的最大邮件大小的 1.5 倍。例如，如果邮件的最大大小为 10 MB，应将 MaxDumpsterSizePerStorageGroup 参数的值配置为 15 MB。

我们还建议将 MaxDumpsterTime 参数（该参数指定应当将电子邮件保留在传输 dumpster 队列中的最长时间）的值配置为 7.00:00:00，即 7 天。达到 MaxDumpsterSizePerStorageGroup 指定的大小时，邮件将从传输转储程序中删除。MaxDumpsterTime 参数指定的时间已到时，邮件也将从传输转储程序中删除。此时间应足以保证在出现较长时间中断的情况下，也不会丢失电子邮件。

使用传输转储程序功能时，集线器传输服务器上需要具有额外的磁盘空间，以便承载传输转储程序队列。所需的存储空间量约等于 MaxDumpsterSizePerStorageGroup 的值乘以 CCR 环境中所有群集邮箱服务器上的存储组数加上包含集线器传输服务器的 Active Directory 目录服务站点中所有启用 LCR 的存储组数。在 CCR 环境中，站点中所有集线器传输服务器上的传输转储程序发出的重新传递请求将自动执行。在 LCR 环境中，站点中所有集线器传输服务器发出的重新传递请求将作为 Restore-StorageGroupCopy 任务的一部分进行。

有关如何启用并配置传输转储程序的详细步骤，请参阅如何配置传输 Dumpster。有关 Restore-StorageGroupCopy cmdlet 的详细信息，请参阅 Restore-StorageGroupCopy。

监视复制活动

数据库的被动副本只有保持最新才有用。虽然 LCR 不要求任何特殊的监视，仍建议定期监视每个存储组，以验证它是否正确地复制日志文件。Microsoft Exchange Server 2007 Management Pack for Microsoft Operations Manager 2005 包含与 LCR 环境相关的多个关键问题的警报：

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

  • 被动副本处于失败状态。

  • 被动副本处于正常状态，但日志复制或重播明显滞后。

对于由 Exchange 2007 Management Pack 生成的以上任何警报，都应尽快查明并予以解决。

另一种使用 Exchange 2007 Management Pack for Microsoft Operations Manager 2005 的方法是在 Exchange 命令行管理程序中定期运行执行 Get-StorageGroupCopyStatus cmdlet 的脚本。Get-StorageGroupCopyStatus cmdlet 提供包含由主动副本生成的日志数的队列长度。出于性能考虑，队列长度性能计数器仅报告 Microsoft Exchange 复制服务所知的信息。在极少数情况下，这可能与主动副本上的状态不一致。有关 Get-StorageGroupCopyStatus cmdlet 的详细信息，请参见本主题后面部分的“查看状态信息”。

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

在 LCR 环境中，有时可能需要装入或卸除数据库。如果需要重新配置或维护存储组或数据库，必须在活动期间阻止服务与两者交互。如果要执行重新配置或纠正服务器或数据库问题，则可能需要执行此操作。卸除数据库时，将禁止进行进一步的更改。卸除数据库期间，数据库和日志文件都不会发生更改。

您可能希望向已启用 LCR 的存储组添加数据库。该过程与在独立配置中添加数据库所使用的过程类似，只是必须提供附加路径。

您可能希望从已启用 LCR 的存储组删除数据库。该过程与用于在独立配置中删除数据库的过程相同，只是要删除的数据存在两个副本：数据库的主动副本和数据库的被动副本。有关如何从已启用 LCR 的存储组删除数据库的详细步骤，请参阅如何将数据库从已启用本地连续复制的存储组中删除。

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

可以使用 Exchange 命令行管理程序和 Exchange 管理控制台在已启用 LCR 的存储组中更改数据库的位置。在 LCR 配置中存在两个数据库文件，每个副本存在一个数据库文件。两个副本的位置可以单独更改，也可以一前一后更改。

note注意：
主动副本和被动副本的数据库文件名称和文件路径必须相同。

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

important要点：
不能将数据库放在卷的根目录下。

查看状态信息

对存储组启用 LCR 之后，可以使用 Exchange 管理控制台或 Exchange 命令行管理程序来查看存储组及其数据库的 LCR 特定的配置设置。

LCR 状态信息

Exchange 2007 会发布 LCR 副本的多种状态信息。下表说明对启用 LCR 的存储组可用的状态信息。有关说明如何获取状态信息的详细步骤，请参阅如何查看本地连续复制副本的状态。下表按属性在 Get-StorageGroupCopyStatus Exchange 命令行管理程序 cmdlet 完整输出中的出现顺序列出了这些属性。

对启用 LCR 的存储组可用的状态信息

属性 说明

Identity

被查询的存储组的服务器名称。

存储组名称

被查询的存储组的名称。

SummaryCopyStatus

LCR 副本的当前总体状态。可能的值是：

  • Not Supported   当前配置不支持连续复制。

  • Disabled   存储组及其数据库对象的 HasLocalCopy 设置为 0。

  • Failed   验证失败（数据库或日志相互不兼容），或存储组未正确配置 LCR。

  • Seeding   数据库正在设定种子。

  • Suspended   事务日志复制和重播已停止。

  • Healthy   状态正常，没有任何堵塞现象。

Microsoft Exchange Server 2007 Service Pack 1 (SP1) 又增加了两个状态值：

  • Initializing   未关闭任何日志文件，Microsoft Exchange 复制服务正在等待复制已关闭的日志文件。

  • Service Down   Microsoft Exchange 复制服务未在运行或无法联系。

Failed

验证数据库或日志时发现阻止复制的不一致情况。或者是主动副本或被动副本存在配置问题或访问问题。可能值是 True 和 False。

FailedMessage

表明导致复制失败的状况的文字消息。也可能不只是复制问题。

Seeding

正在设定种子。可能的值是 True 和 False。

Suspend

被动副本的复制（和重播）已暂停。此状态阻止更新数据库和复制日志。可能值是 Ture 和 False。

SuspendComment

可选的管理员注释，用于提供复制活动暂停的原因或注释。

CopyQueueLength

等待被复制到被动副本的日志文件文件夹中的事务日志文件数。只有在已检查复制是否损坏后，才会认为复制已完成。

ReplayQueueLength

等待重播到被动副本的事务日志文件数。

LatestAvailableLogTime

最近检测到的新事务日志文件的源存储组上的时间戳。

LastCopyNotificationedLogTime

与主动存储组生成的、副本已知的上一个新日志关联的时间。

LastCopiedLogTime

上次成功复制事务日志文件的源存储组上的时间戳。

LastInspectedLogTime

上次成功检查事务日志文件的目标存储组上的时间戳。

LastReplayedLogTime

上次成功重播事务日志文件的目标存储组上的时间戳。

LastLogGenerated

已知在存储组主动副本上生成的上一个日志生成编号。

LastLogCopied

上一个成功复制到被动副本日志文件夹的日志生成编号。

LastLogNotified

主动存储组生成的、副本已知的上一个日志生成编号。

LastLogInspected

上一个检查一致性和是否损坏的日志生成编号。

LastLogReplayed

上一个成功重播到存储组被动副本的日志生成编号。

LatestFullBackupTime

上次完全备份的时间。

LatestIncrementalBackupTime

上次增量备份的时间。

SnapshotBackup

使用了旧版流式 API 或卷影复制服务 (VSS) 进行备份。可能值是 True 和 False。

通过查看 SummaryCopyStatus、CopyQueueLength、ReplayQueueLength 和 LastInspectedLogTime 的值，可以快速评估 LCR 副本的运行状况。这些属性表明 LCR 副本是否正常以及 LCR 副本在复制日志和重播日志时是否是相对最新的。如果出现下列情况，应找出原因并解决问题：

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

  • 复制队列长度大于 5。

  • 重播队列长度大于 20。

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

重播队列长度和复制队列长度的值可以作为性能计数器使用，分别为 MSExchange Replication 性能对象下的 CopyQueueLength 和 ReplayQueueLength 性能计数器。有关监视 LCR 的性能计数器的详细信息，请参阅如何查看本地连续复制的性能计数器。

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

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

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

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

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

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

note注意：
在 Exchange 2007 SP1 中，还可以使用称为 Test-ReplicationHealth 的新 cmdlet 来验证启用了连续复制的存储组的运行状况和状态。有关 Test-ReplicationHealth cmdlet 的详细信息，请参阅 Test-ReplicationHealth 以及监视连续复制中的“Test-ReplicationHealth Cmdlet”一节。

查看配置信息

通过使用 Exchange 管理控制台和 Exchange 命令行管理程序，可以查看启用 LCR 的存储组和数据库的配置信息。配置信息包括：

  • 存储组   LCR 事务日志文件和 LCR 系统文件的位置。

  • 数据库   LCR 数据库副本的位置。

此外，还可以确定存储组或数据库是否配置为包含 LCR 副本。有关查看 LCR 配置设置的详细步骤，请参阅如何查看本地连续复制配置设置。

验证被动副本的完整性

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

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

管理复制和重播

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

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

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

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

可能需要暂停和重新启动事务日志复制活动。事务日志复制（包括重播）是在存储组级别进行控制的。由于存储组只能包含一个数据库，因此复制局限于一个数据库。如果 Microsoft Exchange 复制服务正在运行、已对存储组启用了 LCR 并且主动副本和被动副本均正常，这时会进行事务日志复制。如果主动副本或被动副本不可用，则必须停止复制。此外，某些管理任务（例如种子设定）要求已启用了 LCR 的存储组挂起复制。如果需要停止对被动副本数据文件的所有访问，必须挂起复制。

有时可能需要控制被动副本的活动。若要执行重新配置或解决服务器或数据库出现的问题，可能需要这样。若要对被动副本执行物理一致性检查，还需要暂停日志重播。如果需要控制数据库副本更新，必须暂停对存储组副本的复制。要处理被动副本的日志时，可能也需要暂停复制。由于存储组只能包含一个数据库，因此影响重播行为的操作在存储组级别进行控制。

建议在更改存储组或数据库的位置时暂停所有复制活动。

有关暂停对 LCR 副本的复制更改的详细信息，请参阅如何暂停为本地连续复制启用的存储组的复制。有关重新启动对 LCR 副本的复制更改的详细信息，请参阅如何为已启用本地连续复制的存储组重新启动复制。有关对被动副本的事务日志文件和数据库文件执行完整性检查的详细信息，请参阅如何使用 Eseutil 验证本地连续复制副本。

激活被动副本

LCR 使您可以通过激活存储组的被动副本，从存储组主动副本的损坏中恢复。如果存储组主动副本中的事务日志未损坏，则不会丢失任何数据。如果存储组主动副本中的事务日志不可用，恢复只能使存储组返回到与副本收到的最后一组未损坏更改一致的时间点。另一个约束条件是，早于该时间点的任何生产事务日志文件不得有任何丢失或损坏。

使用 NTFS 文件系统卷装入点存储 LCR 副本时，最容易从生产存储组的损坏中恢复。使用卷装入点可以将目标分区接到（或装入）另一个物理磁盘的某个文件夹中。卷装入点对程序（包括 Exchange 2007）是透明的。

通过利用重播操作或一致性检查所得到的错误，可以检测作为 LCR 副本一部分的事务日志或数据库文件的损坏情况。要采取的纠正操作（如果有）取决于损坏的性质：

  • 如果损坏发生在已重播的日志文件中，则可以安全忽略损坏的日志文件。但是，如果正在对 LCR 副本创建基于文件系统的备份，则应当首先删除已重播的所有日志文件。

  • 如果是尚未重播的主动副本日志文件中出现损坏，则必须重新设定 LCR 存储组的种子。Exchange 检测到损坏时会尝试重新复制日志文件。如果自动复制无法解决损坏问题，则必须重新设定存储组的种子。此外，建议验证源事务日志文件和数据库文件的完整性。验证 Exchange 数据文件时，要求文件脱机且用户无法对其进行访问。

  • 如果数据库已损坏，则必须重新设定存储组的种子。

有关说明如何激活数据库被动副本的详细步骤，请参阅如何切换到数据库的被动副本。

在损坏时评估复制状态

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

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

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

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

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

note注意：
上次检查日志的时间提供有关主动副本最新更改的信息。此信息可以帮助您检测在未启动 Microsoft Exchange 复制服务时发生的故障，因为 Microsoft Exchange 复制服务停止时，队列长度是不准确的。

复制队列长度包含出现故障时最适合使用的主动副本信息。必须根据该信息以及对故障数据库恢复时间的评估，决定是否要装入可用副本：

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

  • 如果复制队列很长，意味着丢失了大量日志。如果数据库已装入，将还原到上次复制日志的大致时间段（也通过 Get-StorageGroupCopyStatus cmdlet 提供）。

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

note注意：
由于延迟和通信故障，复制队列长度可能是不准确的，因为主动副本的当前状态是异步更新的。通常，仅在出现故障前后的大概一分钟内会出现不准确的情况。
note注意：
故障数据库不能用于设定被动副本的种子。