管理群集连续复制

 

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

上一次修改主题: 2009-06-10

除了 Exchange 组织的日常管理任务之外,还有一些是针对管理群集连续复制 (CCR) 环境的任务。通常情况下,CCR 的管理任务分为以下两个类别:

  • 与群集邮箱服务器相关的任务

  • 与群集邮箱服务器中的存储组和数据库相关的任务

与群集邮箱服务器相关的任务

CCR 环境中与群集邮箱服务器关联的管理任务如下:

  • 管理磁盘卷

  • 查看配置设置

  • 监视复制活动

  • 查看和收集性能数据

  • 管理群集邮箱服务器,包括使其联机、使其脱机以及在节点之间移动群集邮箱服务器

  • 管理日志文件的复制和重播

管理磁盘卷

在管理 CCR 环境时,可能需要管理与 CCR 群集关联的磁盘卷。例如,可能由于维护或其他原因而需要使该卷临时与系统分离。如果需要在主动存储组或数据库上执行该操作,则应卸除存储组中的数据库。如果要对存储组或数据库的被动副本执行此类操作,则应通过暂停复制来停止卷的所有复制输入/输出 (I/O)。

有关管理磁盘卷的详细信息,请参阅如何准备 CCR 副本的磁盘卷管理活动

查看配置设置

为服务器启用 CCR 之后,可以使用 Exchange 管理控制台和 Exchange 命令行管理程序查看服务器上的存储组和数据库的配置设置。

配置信息包括存储组和数据库文件的位置。另外,可以通过使用 Exchange 命令行管理程序复查与群集邮箱服务器有关的配置。

有关如何查看 CCR 故障转移控制配置信息的详细步骤,请参阅如何查看故障转移控制配置

监视复制活动

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

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

  • 被动副本处于“Failed”状态。

  • 被动副本处于“Healthy”状态,但日志复制或重播明显滞后。

另外,建议向 Microsoft Operations Manager 添加一个自定义事件规则,未检测到被动节点在运行且其属于包含主动节点的群集时触发该规则。出现这种情况时,群集服务将一个事件记录到系统事件日志中。建议对事件规则使用以下标准,其将属于由群集服务记录的事件:

事件源:ClusSvc

事件 ID: 1135

有关在 Microsoft Operations Manager 中创建事件规则的详细信息,请参阅 使用 MOM 监视安全事件(英文)。

应尽快查明并解决由 Exchange 2007 管理包或自定义事件规则生成的以上任何警报。

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

查看和收集性能数据

可以使用性能计数器确定复制的进度。有关使用 CCR 的性能计数器的详细信息,请参阅如何查看群集连续复制的性能计数器

管理群集邮箱服务器

管理群集邮箱服务器的三个主要管理任务是:使群集邮箱服务器联机、使其脱机以及在群集内的各节点间移动群集邮箱服务器。另外,作为更新管理或其他维护操作的一部分,还涉及到关闭或重新启动群集中的某个节点。

启动和停止群集邮箱服务器

故障转移群集管理工具 (Windows Server 2008)、群集管理器 (Windows Server 2003) 和 Cluster.exe 命令行工具(在两个操作系统中)可以使资源联机以及使资源脱机。使群集邮箱服务器脱机称为“停止”,而使群集邮箱服务器联机称为“启动”。建议使用 Start-ClusteredMailboxServer cmdlet 来启动群集邮箱服务器。停止群集邮箱服务器的建议方法是使用 Stop-ClusteredMailboxServer cmdlet。在 Exchange 2007 Service Pack 1 (SP1) 中,还可以在 Exchange 管理控制台中使用管理群集邮箱服务器向导启动或停止群集邮箱服务器。

有关如何使群集邮箱服务器联机的详细步骤,请参阅如何启动群集邮箱服务器。有关如何使群集邮箱服务器脱机的详细步骤,请参阅如何停止群集邮箱服务器

在节点之间移动群集邮箱服务器

在节点之间手动移动群集邮箱服务器称为“转交”或“计划中断”。要移动群集邮箱服务器,请使用 Move-ClusteredMailboxServer cmdlet。在 Exchange 2007 SP1 中,还可以在 Exchange 管理控制台中使用管理群集邮箱服务器向导来执行群集邮箱服务器的转交。尽管故障转移群集管理工具 (Windows Server 2008)、群集管理器 (Windows Server 2003) 以及 Cluster.exe 命令行工具(在两个操作系统中)可以用来在节点之间移动群集邮箱服务器,但是,建议使用某个 Exchange 管理工具将群集邮箱服务器从主动节点移动到被动节点,因为这些工具允许指定转交原因。此外:

  • 使用群集工具跳过 Exchange 管理工具对被动副本的运行状况或状态执行的检查。这样,使用这些方法可导致当节点执行必要的操作以使数据库可装入时,产生长时间的中断。

  • 使用群集工具还可能会使数据库无限期脱机,因为复制未正常运行,并且群集工具与 Exchange 管理工具不同,无法在移动资源组之前确定复制的状态。

    note注意:
    在节点之间移动群集邮箱服务器将导致服务的短暂中断。此外,将取消群集邮箱服务器上任何存储组的任何备份。

如果复制未正常运行或这些检查确定被动节点未处于转交可接受的状态,Exchange 管理工具不会执行转交。如果发生这种情况,但仍需要将 CMS 移动到被动节点,可以使用群集管理工具执行该任务。

故障转移群集中移动群集邮箱服务器时(此时节点间存在网络延迟),建议从被动节点执行移动操作。

有关如何在节点之间移动群集邮箱服务器的详细步骤,请参阅如何在 CCR 环境中移动群集邮箱服务器

维护群集

维护应始终在群集中的被动节点上执行。更新、修补程序以及其他应用程序通常不应安装在主动节点(当前拥有群集邮箱服务器的节点)上。有关如何在 CCR 环境中安装 Exchange 更新汇总的详细步骤,请参阅将 Exchange 2007 更新汇总应用于群集邮箱服务器

如果需要在主动节点上执行维护操作,则应首先使用 Move-ClusteredMailboxServer cmdlet 将群集邮箱服务器移到被动节点上。移动群集邮箱服务器后,以前的主动节点变为被动节点,而以前的被动节点变为主动节点。然后即可执行维护操作,还可执行向相反方向移动群集邮箱服务器的转交。

CCR 环境允许计划特定节点的系统中断,而群集邮箱服务器不会中断。在 CCR 环境中,一次只能使一个节点脱机。使多个节点脱机会导致服务中断。

计划中断通过 Exchange 命令行管理程序 Move-ClusteredMailboxServer cmdlet 启动。如何在 CCR 环境中移动群集邮箱服务器主题提供执行计划中断的步骤。

在 CCR 环境中关闭或重新启动任何节点之前,建议您验证当前驻留群集邮箱服务器的节点。可以使用 Get-ClusteredMailboxServerStatus cmdlet 获取此信息。

维护群集

维护应始终在群集中的被动节点上执行。更新、修补程序以及其他应用程序通常不应安装在主动节点(当前拥有群集邮箱服务器的节点)上。有关如何在 CCR 环境中安装 Exchange 更新汇总的详细步骤,请参阅将 Exchange 2007 更新汇总应用于群集邮箱服务器

如果需要在主动节点上执行维护操作,则应首先使用 Move-ClusteredMailboxServer cmdlet 将群集邮箱服务器移到被动节点上。移动群集邮箱服务器后,以前的主动节点变为被动节点,而以前的被动节点变为主动节点。然后即可执行维护操作,还可执行向相反方向移动群集邮箱服务器的转交。

关闭群集中的节点

如果需要关闭群集中的所有节点(包括主动节点),必须首先停止群集邮箱服务器。Windows 关闭进程无法感知 Exchange。因此,建议您只关闭被动节点。如果需要关闭或重新启动主动节点,建议您将群集邮箱服务器移到另一个可用的节点。有关介绍如何将群集邮箱服务器移到另一个节点的详细步骤,请参阅如何在 CCR 环境中移动群集邮箱服务器

如果不能将群集邮箱服务器移到被动节点(可能是由于已关闭被动节点),则必须在关闭主动节点之前停止群集邮箱服务器。

如果需要重新启动或关闭主动节点,但是无法将群集邮箱服务器移到被动节点,建议您使用组策略,以确保在重新启动或关闭主动节点之前停止群集邮箱服务器。Windows Server 提供一组策略驱动型计算机关闭脚本,可以使用组策略管理单元进行管理。组策略管理单元包含的扩展程序可以用于指定在关闭计算机时运行的脚本。

例如,可以使用相应的参数来创建运行 Move-ClusteredMailboxServer cmdlet 或 Stop-ClusteredMailboxServer cmdlet 的关闭脚本。我们还建议使用关闭脚本,因为这种方式可以尽可能避免没有意识到需要在关闭主动节点之前移动或停止群集邮箱服务器的管理员关闭或重新启动系统。

important要点:
这些脚本在 Local System 帐户下运行。在这些脚本可以成功运行之前,必须授予本地系统帐户(本地节点的计算机帐户)权限来管理群集邮箱服务器。

管理日志文件的复制和重播

在 CCR 环境中管理复制涉及下列主要活动:

  • 暂停复制时处理故障转移

  • 暂停和重新启动存储组副本的复制

  • 配置一个或多个冗余网络以进行复制

暂停复制时处理故障转移

如果暂停复制,则会在挂起期间停止从主动存储组到副本的所有更改传播。如果在此期间发生故障转移,则存储组副本将没有最新的更改。根据在主动节点上已发生的更改量的不同,缺少最新更改很可能会使系统无法在被动计算机上装入副本。因此,您可以使用被动节点上可用的存储组版本,也可以等到原始服务器恢复。尽可能缩短暂停复制的时间以最小化此危险性,这十分重要。

如果原始计算机变为可用时,未在被动节点上装入此数据版本,则复制系统将复制已丢失的日志,并在新主动节点上自动装入数据库副本。

如果被动副本仍然有丢失的日志,或者被动副本拥有全部日志但是尚未重播,恢复复制之后可能会发生故障转移。如果日志已复制但未重播,则故障转移将触发使未处理的日志重播到数据库的操作。因此,尽管其他存储组不会受影响,但作为故障转移的一部分,此存储组的恢复时间将延长。但是,如果有足够的日志,可以满足所配置的自动装入条件,系统将最终在数据库中装入最新的可用数据。此过程存在以下风险:要重播的某个日志可能已损坏,无法成功重播。在这种情况下,重播将导致出错,并阻止所有进一步的重播活动。发生此情况时,存储组副本将转入错误状态,称为“Failed”。在此错误状态下,您可以使用最接近此点的数据库版本进行恢复。否则,将需要等到原始服务器可用,然后重新复制未损坏的日志。

暂停和重新启动存储组副本的复制

有时可能需要控制被动副本的活动。可能需要暂停和重新启动复制活动。复制是在存储组级别进行控制的。由于存储组只能包含一个数据库,因此复制仅局限于一个数据库。

当群集中的两个节点都在运行,Microsoft Exchange 复制服务正在目标节点上运行,且存储组副本已启用复制时,将进行复制。如果 CCR 的源位置或目标位置不可用,则必须停止复制。此外,一些 CCR 管理任务(如种子设定、执行完整性检查或重新配置存储)要求存储组副本暂停复制。如果需要停止所有对目标日志文件和日志目录的访问,必须暂停复制。

Exchange 2007 需要在存储组或数据库的位置发生更改时暂停所有复制活动。

有关暂停数据库副本更新的详细信息,请参阅如何暂停群集连续复制副本的复制。有关重新启动数据库副本更新的详细信息,请参阅如何重新启动群集连续复制副本的复制

有关对 CCR 事务日志和数据库文件执行完整性检查的详细信息,请参阅如何使用 Eseutil 验证群集连续复制副本

配置一个或多个冗余网络以进行复制

Exchange 2007 SP1 允许您配置可用于在 CCR 环境中进行日志传送和种子设定的冗余群集网络。冗余网络必须配置为混合群集网络。混合群集网络是已为群集(检测信号)访问通信和客户端访问通信配置的任何群集网络。

为混合群集网络配置了连续复制主机名和 IP 地址后,Exchange 2007 将使用该网络传送日志。此外,可以使用配置的网络来执行管理员使用 Update-StorageGroupCopy cmdlet 启动的种子设定。可以指定多个混合网络,并且如果有多个网络,Exchange 2007 将随机选择其中一个网络。如果当前使用的网络不可用,Exchange 2007 将自动选择其他可用网络。

使用 Enable-ContinuousReplicationHostName cmdlet 可以配置通过混合网络的日志传送支持。与此类似,关闭此功能使用 Disable-ContinuousReplicationHostName cmdlet 来完成。当 CCR 环境中拥有群集邮箱服务器后,管理员就可以在群集的两个节点上运行 Enable-ContinuousReplicationHostName 并指定两个 IP 地址和主机名了。此后,如果配置成功且确认混合网络运行正常,系统会随机选择一个混合网络进行日志复制。

种子设定和重新设定种子是使用 Update-StorageGroupCopy cmdlet 在 CCR 环境中执行的。在 Exchange 2007 SP1 中,该 cmdlet 已经过扩展,包含新参数 DataHostNames。该参数用于指定应使用哪个网络进行种子设定或重新设定种子。该参数的值是包含以下任何一种名称的多值列表:完全限定的域名 (FQDN) 或主机名。任一种名称都必须标识被动节点。

有关配置冗余网络以进行日志传送和种子设定的详细信息,请参阅下列主题:

与群集邮箱服务器中的存储组和数据库相关的任务

与 CCR 环境中群集邮箱服务器的存储组和数据库相关联的管理任务如下:

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

  • 查看存储组副本的状态

  • 装入和卸除数据库

  • 验证存储组副本的完整性

  • 从生产存储组或存储组副本的损坏中恢复

  • 在遇到故障或某些形式的数据损坏后恢复 CCR

除了恢复存储组(它是一种特殊类型的存储组)之外,会为 CCR 环境中的所有存储组和数据库自动启用连续复制。尽管复制和重播可以挂起,但在 CCR 环境中不可能禁用一个或多个存储组的连续复制,因为这样可能会发生中断,从而无法访问特定数据库。

在 CCR 环境中新建存储组时,应会在被动节点上自动进行数据库副本的种子设定。如果由于某种原因,没有自动进行种子设定,则必须手动为数据库副本设定种子。有关如何为数据库副本设定种子的详细步骤,请参阅如何将群集连续复制副本设定为种子

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

可能需要在 CCR 环境中移动存储组文件的位置或数据库的位置。移动文件位置所用时间长度取决于所移动数据库的大小、所移动的事务日志文件数以及存储的性能特征。在任何移动期间均将卸除数据库。

在 CCR 环境中,因为文件在主动节点和被动节点上的位置必须相同,所以,重定位存储组时需要通过一致的方式重定位两个副本。必须先卸除数据库并挂起复制,才能移动存储组或其数据库。对于主动副本,可以通过在 Exchange 命令行管理程序中使用 Dismount-Database cmdlet 完成此操作。对于 Microsoft Exchange 复制服务,则使用 Suspend-StorageGroupCopy cmdlet 和 Resume-StorageGroupCopy cmdlet。

note注意:
Microsoft Exchange 复制服务将持续监视复制位置中的文件和主动节点上的日志。因此,如果以任何方式操作活动日志,都必须使用 Suspend-StorageGroupCopy cmdlet(暂停复制)使该存储组的活动挂起。

有关如何移动 CCR 环境中存储组文件的位置的详细步骤,请参阅如何在 CCR 环境中移动存储组。有关如何移动 CCR 环境中数据库的位置的详细步骤,请参阅如何在 CCR 环境中移动数据库

查看存储组副本的状态

在正式发布 (RTM) 版的 Microsoft Exchange 2007 中,只能使用 Exchange 命令行管理程序查看 CCR 状态信息。在 Exchange 2007 SP1 中,下表中列出的某些状态信息可以在 Exchange 管理控制台中查看。

Exchange 2007 会发布存储组副本的多种状态信息。下表列出了可用的状态信息。在下表中,属性按其在 Get-StorageGroupCopyStatus cmdlet 的完整输出中的出现顺序一一列出。有关查看状态信息的详细步骤,请参阅如何使用 Exchange 管理外壳查看群集连续复制副本的状态

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

属性 说明

Identity

被查询的存储组的标识。该属性提供 <服务器名称>\<存储组名称>。

存储组名称

被查询的存储组的名称。该属性提供存储组的名称。

SummaryCopyStatus

被动副本的当前总体状态。可能的值是:

  • Not Supported 当前配置不支持本地连续复制 (LCR)。

  • Disabled 存储组没有配置的副本。没有为此群集邮箱服务器配置任何被动节点。

  • Failed  验证失败或只是为 CCR 部分配置了存储组。

  • Seeding  正在进行完整数据库做种。

  • Stopped  事务日志复制已停止。

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

  • Healthy   被动副本正常,没有任何堵塞现象。

Exchange 2007 SP1 增加了下列状态值:

  • Initializing   未关闭任何日志文件,Microsoft Exchange 复制服务正在等待复制已关闭的日志文件。在 Microsoft Exchange 复制服务刚启动时,通常会出现该状态。

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

  • Resynchronizing   Microsoft Exchange 复制服务正在对存储组副本执行增量种子重新设定。

Failed

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

FailedMessage

标识导致复制失败的情况的文本消息。也可能不只是复制问题。

Seeding

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

Suspend

表示被动副本的复制已暂停。该状态阻止更新数据库和复制日志。可能的值是 True 和 False。

SuspendComment

可选的注释部分,管理员可在其中提供暂停复制活动的原因或注释。

CopySuspend

表示被动副本的日志复制已暂停。此状态阻止更改日志副本目录。可能的值是 True 和 False。

CopySuspendComment

可选的管理员注释,用于提供暂停日志副本活动的原因或注释。

CopyQueueLength

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

ReplayQueueLength

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

LatestAvailableLogTime

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

LastCopyNotificationedLogTime

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

LastCopiedLogTime

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

LastInspectedLogTime

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

LastReplayedLogTime

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

LastLogGenerated

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

LastLogCopied

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

LastLogNotified

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

LastLogInspected

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

LastLogReplayed

上一个被成功重播到数据库被动副本中的日志生成编号。

LatestFullBackupTime

上次完全备份的时间。

LastestIncrementalBackupTime

上次增量备份的时间。

SnapshotBackup

表示最后一次完整备份是旧版流式备份还是卷影复制服务 (VSS) 快照备份。

SnapshotLatestFullBackup

上次快照完全备份的时间。

SnapshotLatestIncrementalBackup

上次快照增量备份的时间。

SnapshotLatestDifferentialBackup

上次快照差异备份的时间。

SnapshotLatestCopyBackup

上次快照副本备份的时间。

OutstandingDumpsterRequests

未处理请求与未处理请求的时间范围(由低到高)。

DumpsterStatistics

来自所有可访问集线器传输服务器的传输转储程序统计信息。只有一起使用 Get-StorageGroupCopyStatus 命令与 DumpsterStatistics 参数时,才会显示该值。

DumpsterStatisticsNotAvailable

无法访问的集线器传输服务器的列表。

通过查看 SummaryCopyStatusCopyQueueLengthReplayQueueLengthLastInspectedLogTime 的值,可以快速估计存储组副本的运行状况。这些属性显示了存储组副本是否正常运行,以及存储组副本在复制日志和重播日志中是否都是相对最新的。如果发生下列情况,应当确定原因并纠正问题:

  • 副本未处于正常状态。

  • 复制队列长度大于 5。

  • 重播队列长度大于 20。

  • 上次检查日志的时间不是最近的时间。存储组没有活动可能会造成这种情况,但也可能表示 Microsoft Exchange 复制服务已停止。

可以使用如下所示的时间单位来计算两个队列的长度数值:

  • 复制队列时间 = LatestAvailableLogTimeLastCopiedLogTime

  • 重播队列时间 = LatestCopiedLogTimeLastInspectedLogTime

重播队列长度值和复制队列长度值可用作性能计数器。它们是 Microsoft Exchange 复制服务性能对象下的 CopyQueueLengthReplayQueueLength 性能计数器。

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

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

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

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

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

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

    note注意:
    在 Exchange 2007 SP1 中,您还可以使用一个名为 Test-ReplicationHealth 的新 cmdlet 来验证启用了连续复制的存储组的运行状况和状态。有关 Test-ReplicationHealth cmdlet 的详细信息,请参阅 Test-ReplicationHealth

装入和卸除数据库

有时可能需要在 CCR 环境中装入或卸除数据库。如果要执行重新配置或纠正服务器或数据库问题,则可能需要执行此操作。卸除数据库时,将禁止进行进一步的更改。卸除数据库期间,数据库和日志文件都不会发生更改。

有关在 CCR 环境中装入数据库的详细信息,请参阅如何在群集连续复制环境中装入数据库。有关在 CCR 环境中卸除数据库的详细信息,请参阅如何在群集连续复制环境下卸除数据库

验证存储组副本的完整性

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

note注意:
对数据库运行物理一致性检查之前,必须暂时挂起对存储组副本执行的复制活动。可以在 Exchange 命令行管理程序中使用 Suspend-StorageGroupCopy cmdlet 挂起事务日志重播活动。完成一致性检查后,可以使用 Resume-StorageGroupCopy cmdlet 恢复事务日志重播活动。

在 CCR 环境中从损坏中恢复

CCR 可以通过启动计划中断从生产存储组的损坏或故障中恢复。如果日志文件未损坏,则不会因为恢复而丢失任何数据。但是,如果日志文件不可用,恢复则只能使存储组还原到与副本收到的未损坏且最新的更改集一致的时间点。另外一个约束条件是不能丢失或损坏任何早于该时间点的更改数据。

有关介绍如何在 CCR 环境下从损坏或故障中恢复的详细步骤,请参阅下列主题:

发生故障或损坏后恢复 CCR

CCR 提供了在故障后自动恢复的功能。但是,仍然存在需要手动恢复的情况,包括:

  • 被动副本上的数据库文件损坏   有关介绍如何在发生数据库损坏后恢复 CCR 的详细步骤,请参阅如何在数据库损坏之后进行还原

  • 被动副本上的数据库或日志卷发生故障   有关介绍如何在发生卷故障后恢复 CCR 的详细步骤,请参阅如何在卷失败后恢复

  • 数据库出现故障或发生变化   CCR 检测到并报告数据库因出现故障而发生变化。通常情况下,当数据库副本可用且出现故障的数据库副本的更改超过可接受的自动装入条件所允许的更改时,会出现这种情况。有关如何在数据库出现故障或发生变化后恢复 CCR 的详细步骤,请参阅如何在发生故障或更改后还原 CCR 功能