如何解决群集连续复制问题
适用于： Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
上一次修改主题： 2008-01-14
本主题讨论如何解决与群集连续复制 (CCR) 相关的问题。有关可能有助于解决 CCR 问题的工具的详细信息，请参阅解决高可用性部署问题的工具。
本主题中的步骤可解决 CCR 环境中的下列问题：
Get-StorageGroupCopyStatus 报告数据库“失败”且未设置为种子。
Get-StorageGroupCopyStatus 报告数据库“失败”。FailedMessage 值指示存储组副本已发生变化。
Get-StorageGroupCopyStatus 报告数据库“失败”。FailedMessage 值将提供有关故障来源的特定信息。
警报、性能计数器或 Get-StorageGroupCopyStatus 指明存储组副本的复制或重播队列发生积压。
Get-StorageGroupCopyStatus 报告 LastInspectedLogTime 过时。
故障转移或 Move-ClusteredMailboxServer 成功，但数据库未安装。
故障转移成功，但某些数据库未自动或手动装入。或者，Get-ClusteredMailboxServerStatus 报告一个或多个失败的数据库。
在 CCR 环境中，数据库无法在启动时装入。
记录了 MSExchangeRepl 事件 2073，提醒 Microsoft Exchange 复制服务无法找到目录。
由于复制问题，Move-ClusteredMailboxServer 不会启动计划中断。
在一个或多个存储组上进行故障转移之后，复制不会重新同步。
设定种子失败。
失败后，除了此处列出的事件日志之外，还要查看这两个节点上的事件日志以确定导致失败的原因，并使用日志中的信息来确定必须采取哪些恢复操作。如果您已确定失败发生的时间，其他事件日志可能会帮助您更好地理解问题所在。如果此信息还不够，那么知道问题的发生时间可以缩小分析范围以及 cluster.log 中复查窗口的大小。群集日志提供群集管理系统所采取的操作的跟踪级别信息。
开始之前
若要执行以下步骤，必须为您使用的帐户委派 Exchange Server 管理员角色以及目标服务器的本地管理员组成员身份。有关管理 Microsoft Exchange Server 2007 所需的权限、角色委派以及权利的详细信息，请参阅权限注意事项。
步骤
Get-StorageGroupCopyStatus 报告数据库“已失败”且未被设定为种子
可能的原因 出现配置问题，或者复制副本的基准数据库无效。添加被动节点时没有为存储组副本设定种子可能会引起此问题。
解决方法
请验证该副本的存储是否已正确配置并可操作。如果发现错误，则可以通过挂起并继续存储组来触发新的副本检查。
请验证存储组和数据库路径相对于被动服务器上的存储是否已正确进行配置。这可以通过在 Exchange 管理控制台中使用 Get-StorageGroup cmdlet 来实现。
使用 Update-StorageGroupCopy cmdlet 可以将存储组副本设定为种子。
Get-StorageGroupCopyStatus 报告数据库“已失败”，FailedMessage 值指示存储组副本已出现变化
可能的原因 出现下列情形时发生：存在故障转移，并且丢失了足够多的日志，使得如果不完全重新设定种子，以前的活动服务器上的数据库就无法与当前的活动数据库重新进行同步。在 LCR 中不会发生这种情形。
解决方法 使用 Update-StorageGroupCopy cmdlet 可以为存储组副本设定种子。
Get-StorageGroupCopyStatus 报告数据库“已失败”，FailedMessage 值提供有关失败原因的特定信息
可能的原因 导致存储组副本被视为已失败的可能原因有多种。例如，先前的两种情形，即未被设定为种子和未出现变化。FailedMessage 值专门用于标识检测到的问题。
解决方法 运行 Get-StorageGroupCopyStatus cmdlet 来获取完整的 FailedMessage 值，该值标识检测到的特定问题。分析由 FailedMessage 值提供的信息，并解决所报告的情况。如果所报告的情况是日志损坏或丢失，请尝试找一个具有正确生成编号的未损坏的日志。如果无法找到正确的日志，请使用 Update-StorageGroupCopy cmdlet 重新设定种子。如果邮件指示来源中的日志不可用，请删除来源日志目录中的共享并重新启动该节点上的复制服务。
警报、性能计数器或 Get-StorageGroupCopyStatus 指示存储组副本的复制或重播队列发生积压
可能的原因 日志复制或重播太多可能表明恢复过程中存在问题或恢复过程中存在临时情形。当以前脱机的被动节点被联机时，或当存储组副本被挂起一段显著的时间之后最近继续挂起时会发生临时情形。停止被动节点上的 Microsoft Exchange 复制服务与挂起该节点上的所有存储组副本具有相似的效果。如果该情形不是临时的，则可能是由于下列问题之一所引起的：
配置问题。
存储副本已挂起。
重播服务已停止。
存储已失败或处于脱机状态。
被动节点脱机。
解决方法 确定是存在实际问题还是临时发生的情况：
确定 Microsoft Exchange 复制服务是否在两个节点上同时运行。使用“服务”管理单元可以完成此任务。如果任一节点上停止了该服务，则必须启动该服务。
运行带有 fl（格式化列表）选项的 Exchange 命令行管理程序 cmdlet Get-StorageGroupCopyStatus，并确定被动副本是否被挂起。如果被挂起，请验证被动副本的文件是否正确存在，然后使用 Resume-StorageGroupCopy cmdlet 恢复存储组副本。
运行带有 fl 选项的 Get-StorageGroupCopyStatus cmdlet，并确定副本是否“正常”。如果副本“已失败”，请复查状态字段列表来确定必要的更正操作。
对复制性能计数器持续观察数分钟，以确定进程是否正在执行中。应特别关注重播生成编号与检查生成编号。如果副本队列长度不断增加，但重播队列长度很短或在缩短，则可能是活动服务器上的网络文件共享存在问题，或者是活动服务器本身存在问题。使用 Windows Explorer 或“计算机管理”管理单元，执行“net share”命令验证是否对主动存储组副本的日志目录定义了网络文件共享。在 Exchange 命令行管理程序中使用带有 fl 选项的 Get-StorageGroup cmdlet 可以确定存储组的 GUID。
Get-StorageGroupCopyStatus 为 LastInspectedLogTime 报告一个旧时间
可能的原因此症状有以下三种可能的原因：
主动存储组副本的数据库已卸除。
主动存储组副本已装入，但没有以很快的速率进行更改。因此，该主动存储组副本未产生日志。
Microsoft Exchange 复制服务未在被动节点上运行。
解决方法 通过执行下列操作可以确定是这三个原因中的哪个原因引起的：
确定数据库是否已卸除，方法是使用 Exchange 管理控制台或者在 Exchange 命令行管理程序中运行 Get-StorageGroupStatus cmdlet。如果已卸除，则必须装入该数据库，并且必须在 LastInspectedLogTime 更改之前更改数据库（例如数据库内的活动）。
验证 Microsoft Exchange 复制服务是否在被动节点上运行。如果该服务已停止，则必须启动该服务。
验证数据库已装入之后，请检查数据库是否生成日志。查看活动数据库的日志目录，并使用最高生成编号标识日志文件。检查该日志上的时间戳；该时间戳应与 LastInspectedLogTime 中的相应值匹配。
故障转移或 Move-ClusteredMailboxServer 成功，但数据库未装入
可能的原因 此问题的典型原因是群集服务帐户没有装入数据库所需的授权。或者，故障转移导致所丢失的日志数量超过了自动装入配置设置所允许的日志数量。故障转移情形中另一个典型的原因是被动副本在发生故障时状态不正常。
解决方法 群集服务帐户的权限问题通常是在安装过程中发生的。如果在安装结束时还没有装入数据库，通常表明没有为群集服务帐户授予相应的权限。要解决此问题，请为群集服务帐户授予相应的权限，然后顺序关闭并重新启动整个群集。可以按如下顺序完成此操作：(1) 使群集邮箱服务器脱机；(2) 关闭被动节点；(3) 关闭主动节点；(4) 启动主动节点；(5) 启动被动节点；(6) 使群集邮箱服务器联机。
- 检查事件日志以确定故障转移丢失的日志数量是否超过了自动装入配置设置所允许的日志数量。在确定存储组副本的数据库状态之后，可以通过在 Exchange 命令行管理程序中运行 Restore-StorageGroupCopy cmdlet 显式装入该数据库。最后，运行 Get-StorageGroupCopy cmdlet，并查看 SummaryCopyStatus 值来确定是否还存在以前的主动副本阻止数据库装入的问题。如果存在任何问题，请检查事件日志以确定导致问题的原因，然后采取相关步骤来解决问题。
故障转移成功，但某些数据库未自动或手动装入。或者，Get-ClusteredMailboxServerStatus 报告一个或多个失败的数据库
可能的原因 最近的一次故障转移导致丢失的日志数量超过了自动装入配置设置所允许的日志数量。在故障转移情形中另一个典型的原因是被动副本在发生故障时状态不正常。
.gif "note")
注意：在计划中断或未计划中断期间，数据库可能被短暂地标记为失败或脱机。此状态是临时的，且这种状态在复制服务尝试制作任何可用日志的最终副本时发生。 解决方法 检查事件日志以确定数据库装入失败的原因。数据库装入失败可能是由于日志或数据库文件发生损坏引起的。如果事件指示是此原因，请通过将活动服务器移动到另一个节点来还原对数据库的访问。可以通过检查事件日志来确定数据库是否装入失败。在确定存储组副本的数据库状态之后，可以通过在 Exchange 命令行管理程序中运行 Restore-StorageGroupCopy cmdlet 显式装入该数据库。然后，运行 Get-StorageGroupCopyStatus cmdlet，并查看 SummaryCopyStatus 值来确定是否还存在以前的主动副本阻止数据库装入的问题。如果状态显示存储组副本因太旧而无法激活，则可以在失败的节点返回服务且更多日志可用时还原数据库。系统会自动复制日志，不需要您进行任何操作。
在 CCR 环境中，数据库无法在启动时装入
可能的原因 数据库无法装入可能是某个显式管理员操作的结果。如果数据库是显式卸除的，且接着使群集邮箱服务器脱机，则在下次启动时，数据库将不会联机。另一个可能的原因是，在故障转移过程中丢失的日志数量超出了可接受的丢失日志数量。
解决方法 可以在 Exchange 命令行管理程序中运行 Get-ClusteredMailboxServerStatus cmdlet 来验证该存储在此节点上可操作。使用 Exchange 管理控制台或 Exchange 命令行管理程序尝试装入受影响的数据库副本。有关装入该数据库副本的详细信息，请参阅如何在群集连续复制环境中装入数据库。在装入操作之后检查事件日志以确定是否报告了所有错误。
记录了群集事件 MSExchangeRepl 2073，提醒 Microsoft Exchange 复制服务无法找到指定的目录。
可能的原因 该错误事件表明 Microsoft Exchange 复制服务无法创建事件所指定的目录。Microsoft Exchange 复制服务尝试创建多个必需的目录（如果尚未存在）。其中包括源日志文件、目标日志文件和目标系统文件的目录路径以及日志文件检查程序的路径。
Microsoft Exchange 复制服务可能由于权限问题、硬件故障或配置失败而无法创建指定的目录。
解决方法 检查事件所返回的错误代码。验证目录位置可用并且可以访问。检查文件系统权限。确保正确地配置了存储，并且硬件正常运行。
由于复制问题，Move-ClusteredMailboxServer 不会启动计划中断
可能的原因 Exchange 命令行管理程序 Move-ClusteredMailboxServer cmdlet 包含验证检查，当复制在所有存储组副本上并非完全正常时可阻止被动节点的计划中断。此行为可确保计划中断的延长时间适宜。
解决方法 确定有问题的特定存储组，并更正所有问题。来自 Move-ClusteredMailboxServer cmdlet 的错误消息可确定有问题的存储组副本。如果要移动并忽略验证检查，请确保仅失败的存储组副本数据库被卸除。请重试移动操作并使用 -IgnoreDismounted 参数。IgnoreDismounted 参数指示为了复制正常检查将忽略卸除的存储组。
在一个或多个存储组上进行故障转移之后，复制不会重新同步
可能的原因** Get-StorageGroupCopyStatus** cmdlet 返回的失败消息指示数据库已出现变化。如果在进行故障转移前旧的活动服务器没有复制足够的日志，则在进行故障转移时会发生此情况。
解决方法 通过在 Exchange 命令行管理程序中使用 Update-StorageGroupCopy cmdlet 重新为数据库设定种子。
设定种子失败
可能的原因 在活动服务器上正在进行备份，或存在通信问题。
解决方法 验证当前没有执行对受影响的存储组副本或数据库的备份。请确保主动节点联机。
详细信息
有关本主题中所涉及的 Exchange 命令行管理程序 cmdlet 的详细信息，请参阅下列主题：
有关解决本地连续复制问题的信息，请参阅如何解决本地连续复制问题。