Exchange Server 2007 连续复制深度解析

 连续复制（也称为日志传送和重播）是Microsoft Exchange Server 2007 中的一个新技术。它创建和维护数据库备份来为邮箱数据库提供完全的高可用性和灾难恢复解决方案。随着Exchange Server 2007 Service Pack 1 (SP1)的发布，现在有三种形式的连续复制。

本地连续复制（LCR） LCR是单服务器解决方案，在与主动存储组所在的服务器相连接的另一个磁盘集上创建并维护存储组的副本。

群集连续复制（CCR）CCR是 一项高可用性功能，它为电子邮件服务和邮箱数据提供故障转移功能，通过群集技术使用连续复制来为服务器冗余提供数据冗余的一个备份。

备 用连续复制   (SCR)    SCR是一个灾难恢复功能，它通过连续复制来创建和维护存储组的多个备份。SCR 实现了高可用性（包含服务和数据可用性）与站点弹性的分离。例如，SCR 可以与 CCR 相结合，以在主数据中心本地复制存储组（使用 CCR 实现高可用性），并在辅助或备份数据中心远程复制存储组（使用 SCR 实现站点弹性）。辅助数据中心可以在 SCR 目标所在的故障转移群集中驻有一个被动节点。这种类型的群集称作备用群集，因为它并不包含任何群集邮箱服务器，但是可以在恢复方案中为其快速提供一个替代 群集邮箱服务器。如果主数据中心发生故障或丢失数据，可以在备用群集上快速激活该备用群集中的 SCR 目标。

连续复制基础

连 续复制利用Exchange  服务器数据库恢复支持，来提供异步更新一个邮箱数据库的一个或多个副本技术。每个邮箱服务器记录主动数据库生成的数据库更新，将它以日志的形式记录在连续 的1MB的事务日志文件中。这些文件的集合被当作日志流。日志流被用来备份和服务器崩溃后恢复。

在连续复制中，日志流也被用来异步更新一个数据库的一个或多个副本。这是通过传送日志到包含主动存储组副本的位置，然后重播它们到数据库副本中。如果来自主动数据库的所有日志都被重播到数据库的副本中，那么这两个数据库是相同的。

连续复制在存储组级别上配置和管理。然而，因为连续复制要求一个存储组只能包含一个数据库，连续复制有效地运行在数据库级别上。

该文章将深入研究连续复制的内部原理，解释使用连续复制成为可能的邮箱服务器角色的关键组件。

用简单的话来说，连续复制执行下面这些步骤：

   1. 通过指定源数据库副本为目标种子创建目标数据库。
   2. 通过订阅Windows  文件系统通知事件监视源日志目录中的新日志用于拷贝。
   3. 拷贝任何新的日志文件到目的检查日志目录。
   4. 检查拷贝的日志文件。
   5. 通过成功检查，移动拷贝的日志到存储组副本的日志路径，重播拷贝的日志到数据库的副本中。

复制组件

代表日志生成、日志传送和日志重播活动的两个关键服务是：

1.       Microsoft Exchange Information Store service   代表服务用户和应用请求，执行写前面的日志，通过Extensible Storage Engine (ESE) 更新数据库文件。
 
2.       Microsoft Exchange Replication Service   代表日志传送和重播数据库副本上的日志。

Information Store 服务功能

当数据库中的数据被检索、插入或修改的时候，ESE执行下面的步骤：

1.       一个操作发生于数据库（一个客户端发送了一个新的邮件），请求更新的页面从数据库中读出并被放到ESE的缓存（假设该页面不在内存中），而日志缓冲器被通知，它在内存中记录这个操作。

2.       这些更改被数据库引擎记录下来，但是这些更改没有被立刻写到硬盘上的数据库文件中 。实际 上，这些更改保存在ESE的缓存中，它们被称为使用过的页面，因为它们还没有被提交到数据库文件。存储版本被用来跟踪这些更改，这样可以确保被隔离，并且 保持一致性。

3.       当数据库页面发生更改，日志缓冲器被通知来提交更改，事务被记录在事务日志文件中，它也许要求或不要求关闭现有的Exx.log文件并开始生成一个新的日志。（注意ESE也代表关闭一个日志文件一旦它达到最大值（1MB）并开始生成一个新的。）

4.       最终使用过的数据库页面被写到硬盘上的数据库文件中。

5.       检查点被增加。

复制服务功能

当连续复制被激活后，Microsoft Exchange 复制服务 （简称复制服务）用来检测当现有日志文件被ESE关闭的时候，拷贝它，检查它，然后重播它到数据库副本中。该服务在缺省情况下被安装在所有的已经安装邮箱服务器角色的服务器上。

复 制服务的可执行文件是Microsoft.Exchange.Cluster.ReplayService.exe，在缺省情况下它位于<安装路 径>/bin。复制服务依赖于Microsoft Exchange Active Directory Topology Service 。复制服务能够被停止和启动使用服务控制台或命令行，它也能够被配置为自动启动万一失败或意外发生。

复制服务存储它自己的关于诊断信息在注册表中下面的位置：

HKEY_LOCAL_MACHINE/System/CurrentControlSet/Services/MSExchange Repl/Diagnostics

注 意：通过Exchange Management Shell（例如，Get-EventLogLevel -Identity "MSExchange Repl"或 Set-EventLogLevel -Identity "MSExchange Repl" -Level High），您能够查询或设置复制服务的当前的诊断级别。

复制服务组件

复制服务使用几个组件来提供活动存储组和活动存储组的一个或多个副本之间的连续复制。下面的组件参与了连续复制过程。

LogCopier   代表拷贝关闭的日志从源存储组到包含副本存储组的目的服务器上。这是一个异步的操作，复制服务连续监视源存储组的日志文件目录。它通过订阅Windows 文件系统通知事件来完成该监视。当源服务器上一个新的日志文件被关闭，触发一个事件来通知复制服务一个新的文件存在。LogCopier将接着拷贝该日志 文件到目标服务器上的检查位置。

 

LogInspector   代表验证日志文件是有效的。它周期性地检查目的检查目录。如果发现一个日志文件损坏或不能被重播，复制服务将请求重新拷贝该文件。

LogReplayer   代表重播被检查过的日志文件到数据库副本中。

LogTruncater   代表删除那些已经被成功重播到数据库副本中的日志文件。这相当重要，因为通常在一次完整或增量备份后，位于检查点以下的日志文件将被删除因为包含在这些日 志文件中的日志记录已经被写入到数据库中。当连续复制被使用的话，LogTruncator 只删除那些不需要用于恢复和重播的日志文件。任何主动副本上还没有被复制和重播到数据库副本的日志文件不会被主动副本的在线备份删除。

Incremental Reseeder   代表确保主动数据库和数据库副本没有分歧在执行一次数据库恢复之后，或在CCR环境中发生一次切换之后。

Seeder   代表创建存储组的基线内容用于启动重播过程。复制服务为新的存储组执行自动种子设定，也为包含所有可用日志（包括第一个日志文件，它包含了CreateDB记录）的任何已经存在的存储组自动设定种子。

Replay Manager   代表跟踪所有复制的实例。它根据需要创建和销毁实例，基于存储组的在线状态。复制实例的配置是静态的。因此，当一个复制实例配置被更改，该复制将被重启同 时更新配置。此外，在关闭复制服务的期间，复制实例配置是不被保存的。结果是，每次复制服务启动的时候有一个空的复制实例列表。在启动期间，重播管理器发 现那些目前在线的存储组，并创建一个运行的实例列表。

重播管理器周期性运行一个名称为configupdater的线程来扫描新配置 的复制实例。configupdater 线程运行在复制服务进程中，对于LCR或CCR每隔30秒，对于SCR每隔3分钟。它将基于当前的数据库状态创建和销毁复制实例（不管数据库是否在线）。 configupdater 线程使用下面这些算法：

   1. 从活动目录中读取实例配置。

   2. 参照运行的存储组/数据库比较活动目录中找到的配置列表。实例的活动目录配置也被检查来确认是否发生更改，如果发生更改的话，该实例被放置到重启列表中。

   3. 产生一个要停止运行的实例列表和一个要启动的配置的列表。

   4. 在停止列表上停止运行的实例。

   5. 在启动列表上启动实例。

因此，重播管理器总是拥有复制实例的动态列表。

复制服务配置信息

每个激活了LCR的存储组和数据库有msExchHasLocalCopy 属性。复制服务使用下面的算法来查找活动目录中复制信息。

   1. 使用计算机名称来查找Exchange 服务器对象。如果没有服务器对象的话就返回。

   2. 枚举这台Exchange 服务器上所有的存储组。

a)      对msExchHasLocalCopy 设置为true的每个存储组，检索系统文件、日志文件和数据库文件的源和目的路径。

在一个CCR的环境中，复制服务执行下面的任务来检索群集邮箱服务器的配置。

1.       建立到群集数据库的连接。

2.       判断哪个节点拥有群集邮箱服务器。

3.       枚举源和目的节点上所有的存储组，用于复制的不同设置有下面这些：

a)      系统文件、日志文件和数据库文件的源和目的路径。

b)      返回存储组的最后的拥有者（假设该存储组以前已经被加载）。

c)       用于日志发送的网络共享。

d)      AutoDatabaseMountDial 设置。

e)      ForcedDatabaseMountAfter 设置。

f)       决定正确的日志发送网络路径。

4.       验证源节点上的配置和目的节点一样。

对于SCR环境，复制服务使用msExchStandbyCopyMachines 属性来识别哪个存储组激活和复制，然后它执行下面的任务：
 

1.       使用计算机名称来查找Exchange 服务器对象。如果没有服务器对象的话就返回。

2.       枚举这台Exchange 服务器上所有的存储组。对含有msExchStandbyCopyMachines 设置的每个存储组，执行下面的操作：

a)      为每个目的服务器检索ReplayLagTime 和TruncationLagTime 参数。

b)      检索系统文件、日志文件和数据库文件的源和目的路径。

 

复制服务通信协调

主动实例和被动实例之间的复制服务通信通过下面三种机制来实现：

日志文件  特定的信息，像备份状态和数据库头变化，被记录在主动实例的日志文件中，并被复制到副本，从而更新数据库副本。

群集数据库或注册表   在群集数据库（CCR）或注册表（LCR/SCR）中，复制服务基于每个存储组存储重播状态数据。被写到这些地方和从这些地方读取的数据是永久状态信息，例如：

   1. 转储程序变量，当传输转储程序被调用的时候它被使用。

   2. 激活变量像数据库是否能够被加载如果它被配置为允许没有丢失。
 
   3. 存储组的复制状态，例如，挂起或失败。

在Exchange 2007的RTM版本中，注册表和群集数据库被用来存储运行时间状态（准确地说我们处于复制过程中）。然而，在SP1中这个发生了变化以便管理任务直接通 过RPC和复制服务通信来获得该信息。运行时间状态数据仍被写到注册表和群集数据库，然而管理任务不在从这些地方读取这些数据。

存储过程   复制服务将生成RPC 调用给活动实例上的存储过程用于配合日志截断。