查找分歧点
在我们的场景中，NodeA上的复制服务将比较第5个日志，发现它与NodeB 上的不匹配。接着它发现第4个日志是相同的，但是它将判断第3个日志是否匹配。
现在复制服务知道对于这个存储组来说分歧发生在哪个地方，我们需要决定任何纠正它。对NodeA 上的副本重设种子将纠正分歧。然而，这是很昂贵的对于大型数据库从网络的角度、存储I/0和吞吐量以及从SLA角度。为了减少执行数据库重设种子的需要，Exchange 团队集中在通用的案例：当一个有损耗故障发生的时候，每个存储组只有少量的日志文件被丢失，同时有故障的节点将很快被修复。
对于通用的案例来说该团队的Exchange 2007解决方案分两个部分：
1. 事务日志文件从5MB减少到1MB。日志大小的减少确保对于每个日志文件来说只有很少量的数据丢失。
2. LLR 被增加到ESE中。
如果分歧点大于或等于waypoint （意味着分歧的日志高于列在数据库头中的“Logs Required” 部分），那么日志文件会被丢弃由于日志分歧只在日志文件中不在数据库中。记住被丢弃的日志确实包含数据，那些数据可能会丢失在这种情况下。如果分歧点小于waypoint （意味着分歧的日志位于列在数据库头中的“Logs Required” 部分中），那么会发生数据库分歧并需要重设种子。
如果我们在回到我们的NodeA，NodeB场景中，日志1、2和3已经被提交到NodeA上的数据库。这些日志也已经被复制到NodeB，并已经被重播到它自己的数据库。接着，NodeA 发生故障，日志4和5都没有复制到NodeB。NodeB接管了群集邮箱服务器，并将存储组加载上线，开始生成它自己的日志4和5，除了生成日志6以外。NodeA 重新上线，它自己的复制检查了分歧发生在第4个日志文件。NodeA上的复制服务咨询数据库头并判断日志4和5不在需要，它丢弃它们因为它们高于waypoint 标记。如果我们检查数据库头的话，我们将看到下面这些：
Initiating FILE DUMP mode...
Database: priv1.edb
...
State: Dirty Shutdown
Log Required: 2-3 (0x2-0x3)
Log Committed: 0-5 (0x0-0x5)
...
1. 提交的是第5个日志 (最后生成的日志列在 “Log Committed”).
2. 检查点是第2个日志 (第一个生成的日志列在 “Log Required”).
3. Waypoint 是第3个日志 （最后一个生成的日志列在 “Log required”).
4. 第4个和第5个日志在waypoint 之外。
复制服务接着从NodeB（参考日志发送和重播部分）拷贝新的日志文件（第4个和第5个）并将它自己的数据库副本更新到最新。
复制服务检查分歧点、删除对于数据库重播来说不需要的日志、并从主动实例拷贝需要的日志文件的过程被称为增量式重新设定种子。
数据库重新设定种子场景
在讨论哪些场景要求数据库重新设定种子之前，注意下面的场景不需要数据库重新设定种子。
1. 在计划中断场景中，主动日志文件被关闭所有要求的日志文件被发送到目标数据库副本确保副本激活是无损耗的。
2. 非计划中断，日志发送是健康的同时与主动节点上的日志生成是一致的，数据库副本没有产生分歧。这种情况能够被纠正通过增量式重新设定种子作为LLR 的结果强制数据库落后以更新的日志流能够刚好被应用和向前回滚。对于利用连续复制的环境来说，确保日志发送是健康的是很关键的。
3. 网络中断不需要数据库重新设定种子只要源节点上的日志流没有被截断。日志截断不会自动发生当连续复制处于不健康的状态或其他不可操作的状态。
4. 有多个群集复制主机名称被定义的网络中断不需要数据库重新设定种子，因为在定义的网络中将发生自动切换，这样会确保日志流被成功地拷贝到被动节点。
下面的场景需要重新设定种子：
1. 管理员执行脱机维护 (ESEUTIL 碎片整理, ISINTEG, ESEUTIL 硬修复) 对生产数据库。脱机维护操作像脱机碎片整理更改了数据库的结构并且这些更改不会被记录，因此，数据库需要重新设定种子。
2. 日志流中的一个日志文件损坏或被意外删除在它被拷贝到被动节点之前。在这种情况下，为副本传递该日志的唯一的方法就是执行数据库重新设定种子。
3. 数据库副本产生显著的分歧的时候发生切换。对于这种情况，数据库必须被加载上线要么通过管理员手动设置要么通过设置ForcedDatabaseMountAfter 值在群集邮箱服务器上。回忆当有损耗切换发生的时候，复制服务计算损失根据日志文件和将它和AutoDatabaseMountDial 值做比较。如果这个损失大于LLR 深度，那么节点之间的数据库分歧已经发生，并且这只能通过执行数据库重新设定种子来纠正。
4. CCR安装会自动指派群集邮箱服务器的拥有者对于主动和被动节点来说。然而，如果被动节点发生故障或其他原因不可用，被动节点能够从群集邮箱服务器的RedundantMachines 列表中删除来允许主动实例上的日志截断发生。然而，一旦被动节点被修复或重新加载上线，并被添加到RedundantMachines 列表，被动节点上的数据库将需要重新设定种子因为在日志序列中有一个间隙。
5. 使用 Failover Cluster Management 工具、 Cluster Administrator或 Cluster.exe 来管理CCR环境中的储存组资源能导致数据库分歧。Cluster Administrator 不包含在有损耗故障期间Exchange cmdlets 必须阻止和警告管理员注意的数据库分歧问题的任何逻辑。
6. 在RTM中，如果您启用页面清零功能，这只在联机流备份期间执行。作为结果，页面清零是不会记录操作，因此您将必须执行数据库重新设定种子来传播这些更改。这个问题在SP1中已经被纠正，通过允许页面清零成为联机维护任务的一个内置的选项。
备用连续复制
备用连续复制是一个灾难恢复特性它通过连续复制来创建和维护一个存储组的多个副本。它提供了管理站点弹性的功能。SCR利用与CCR和LCR一样的连续复制技术。下面是SCR和LCR或CCR几个关键的不同之处：
1. SCR目标上的有损耗激活将从不会调用传输转储程序。
2. LCR和CCR只支持1:1的复制模型。SCR支持多: 多（1:1、多:1和1:多）的复制模型。（一个源存储组能够被复制到多个SCR目标，尽管我们建议不要超过4个副本）
a) 当计划多:1的复制模型的时候，记住SCR有像CCR或LCR一样的相同路径要求。每个数据库必须被复制到对应的相同的驱动器和路径。当设计源服务器的时候，确保每个文件夹路径是唯一的。
3. 日志拷贝到SRC目标是连续的，然而SCR支持日志重播滞后和日志截断滞后。
a) 重播滞后被设计用来减少需要重设种子的机会当源也使用连续复制并且经历了有损耗故障。在缺省情况下，重播之后被设置为1天。
b) 截断滞后被设计以便目标上的日志能够从源上的损失中恢复。在缺省情况下，截断滞后被禁用。
c) 尽管有重播滞后选项存在，在恢复/激活期间，所有的日志文件都被重播（除非这些日志文件被手动从日志路径中删除）。
4. 对SCR目标初始化数据库重设种子不是立即发生的。在缺省情况下，数据库将不会被重设种子直到50个日志文件被复制后和重播滞后时间已经超过。然而，这个能够被覆盖通过执行Update-StorageGroupCopy 。
5. 没有Exchange 感知的备份机制来备份SCR目标存储组。那就是说，您能够挂起复制，然后对SCR目标上的数据库和日志文件执行平坦的文件备份。
6. 日志截断是SCR感知的。
连续复制和备份
使用连续复制的一个好处就是减少从活动存储组到被动存储组基于卷影复制服务的备份。在主动和被动存储组和数据库上Exchange 感知的VSS备份是支持的。微软提供的被动副本备份解决方法只是VSS。流备份只在主动存储组上被支持。您不能使用流备份API 来备份被动节点上的数据库。您也需要使用支持Exchange VSS的第三方备份应用程序，因为Windows Server 备份不是Exchange VSS感知的。
当您对被动副本执行VSS备份的时候，事务日志会发生什么情况呢？在Exchange 感知的备份期间一个通用的任务就是截断事务日志文件在备份被成功执行后。连续复制功能保证还没有复制的日志不会被删除。
在被动副本上执行备份的挑战是备份修改了数据库的头。例如，它们增加关于数据库上次备份的时间的信息。VSS备份通过复制服务中的Exchange Replica VSS Writer是可能的，复制服务有数据的副本，但是它只能得到它自己的数据和从存储中修改。它不能独立地修改数据库的副本，那将产生分歧。因此，它不能修改它自己数据库副本的头。
方法是让复制服务通过存储协调它自己的备份。只要您在被动节点上的开始备份，复制服务联系主动节点上存储并告诉它备份将要开始。通过执行它来阻止在主动和被动节点上相同的存储组被同时备份。一旦备份完成，复制服务将联系存储并告知备份已经完成。
从备份导致的数据库头修改接着在主动节点上的存储被修改。这个动作生成一个日志记录，它通过连续复制被拷贝到被动节点。当它被重播的时候，被动节点上的数据库头接着被更新。
这比传统的备份有疑点复杂，并且它还有一些有趣的影响。例如，如果您备份被动节点并在备份完成之后立即检查被动节点上的数据库，它将不会反映备份。然而主动节点上的数据库将反映它。
因此，如果您在连续复制的环境中备份数据库，判断上一次备份的最准确的方法是检查主动节点上的数据库。
另一个影响是，如果信息存储没有运行的话，您不能备份被动节点。运行信息存储是必须的以便备份能够被相互联系起来，并且数据库头能够被更新。
日志截断
日志截断如何发生，尤其当涉及到连续复制？在Exchange 中，信息存储服务有义务在主动数据库上截断日志文件要么通过ESE.DLL 要么通过ESEBACK.DLL 。使用哪个DLL取决于是否启用连续复制和是否启用循环日志。如果连续复制没有被启用，ESE.DLL有责任执行日志截断当循环日志被启用。否则，ESEBACK.DLL用于日志截断。
当连续复制被启用，ESE以“不执行循环日志”标记被初始化，不管存储组的循环日志设定。执行这个是因为基于ESE的循环日志是不知道连续复制的。为了让连续复制生效，日志连续性是必须的。因此，日志不能被覆盖直到它们不在被复制引擎所需要了。然而，您
可以将循环日志记录和连续复制组合使用。在此配置中，将获得称为连续复制循环日志记录 (CRCL) 的新型循环日志记录，它不同于 ESE 循环日志记录。ESE 循环日志记录由 Microsoft Exchange Information Store 服务执行和管理，而 CRCL 由 Microsoft Exchange 复制服务执行和管理。
复制服务（目的节点上如果CCR或SCR部署的话）和信息存储服务通过RPC通信关于哪些日志文件能够被删除在源节点上，ESEBACK.DLL 接着执行日志截断。复制服务负责为数据库副本截断日志。
在LCR或CCR环境中，为了让日志能够被截断，下面的条件必须满足：
1. 日志文件已经被备份（如果循环日志被启用的话忽略）。
2. 日志文件生成序列位于存储组的检查点日志文件之下。
3. 存储组的被动副本允许日志文件被截断（换句话说，被动副本必须已经重播过这些日志文件）。
此外，如果LCR或CCR是SCR目标的源，下面的额外条件必须满足：
1. 所有的SCR目标已经检查过日志文件。
在SCR环境中，如果下面的条件满足的话，SCR目标上的日志文件将被截断。
a) 日志文件生成序列位于存储组的日志文件检查点之下。
b) 日志文件比 ReplayLagTime + TruncationLagTime 旧。
c) 日志文件必须在源上已经被删除。
注意：有一个已知的问题，日志截断不会发生在SCR目标上如果TruncationLagTime大于ReplayLagTime （即使TruncationLagTime过去之后）。这将影响SCR目标机器的日志驱动器的容量分配。只有两种规避的方法。要么删除不需要的日志文件（这有一点复杂因为您必须确保它们在ReplayLagTime和 TruncationLagTime之外），要么确保TruncationLagTime小于ReplayLagTime（或禁用它）。为了改变这两个参数中的任何一个您需要先禁用SCR然后接着重新启用它使用新的值。该问题期望在将来的SP1的汇总更新中被修复。
将连续复制和其他复制方法做比较
微软建议为邮箱数据库可用性使用连续复制而不是其他的复制方法。对于第三芳复制方法要仔细考虑下面这些问题。
1. 因为第三方复制方法不是Exchange 感知的，它们不知道如何在应用层去验证被拷贝的数据来确保它们是可用的。此外，因为该方法不是Exchange 感知的，它们要求更复杂的特别的步骤来激活。
2. 为了被Exchange 支持第三方复制方法必须是同步的。同步方案要求活动和被动副本之间有好的延迟。
3. 第三方复制方法也许要维护两个并不是相互独立的副本。这意味着在硬件（Exchange 、操作系统、存储组件等）上执行的许多层中有一层出现损坏的话将被复制到第二个副本中，导致很高的恢复点目标（RPO）因为两个副本最终都损坏了。
通过对比，连续复制提供了下面这些方案。
1. 连续复制被集成到Exchange 服务器中提供了一个完整的Exchange 感知的副本通过集成的cmdlets和过程来激活、管理和监视副本。例如，当将复制和群集技术结合起来，CCR提供了集成的服务器和数据冗余，提供了自动服务器和数据同时切换。
2. 使用异步复制来发送关闭的事务日志到第二个副本，使它非常有效率同时对延迟问题有很好地弹性。
3. 使用的是相互独立的副本，因此像第三方解决方法复制的故障问题不会被连续复制复制。例如，如果主动数据库上产生-1018错误，被动副本将不会遇到相同的问题（假设独立的存储解决方案）。
4. 数据库副本的日志被单独验证在它们被重播到数据库副本中之前。
5. 数据库副本的激活是相当地快。例如，在CCR环境中，数据库副本切换到被动节点被集成到Exchange 中，大约只要花两分钟。
6. 对于LCR和CCR场景来说，当发生有损耗故障，唯一丢失能够被丢失的数据是没有经过中心传输服务器的数据。这些数据的小集合只包含联系人、任务、私人邀请、便签和草稿。任何已经经过中心传输的数据被保存在传输转储程序中以一段可配置的时间，并被重新提交到邮箱服务器。
结论
连续复制通过异步复制或日志发送维护数据的副本来为Exchange 2007 提供数据可用性。复制是基于ESE日志，关闭的日志文件被复制、验证然后接着被重播到数据库的副本中。
由于连续复制是异步日志复制模型，Exchange 2007 中的ESE被增强用于减少要求数据库重新设定种子的可能性在非计划中断事件中。丢失的日志弹回延迟提交更改到数据库直到一个或多个日志文件被复制后，因此减少了需要执行数据库重新设定种子的需要如果两个副本出现分歧。
此外，连续复制也通过传输转储程序来重新传递那些最近被提交给邮箱服务器在故障事件之前的邮件。这允许邮箱服务器恢复那些可能被记录但还没有复制到被动副本的电子邮件数据。
分页: [1] [2] [3] [4]
TAG: Exchange 2007 连续复制 功能