Microsoft Exchange Server 2007已经发布一段时间了，和以前的exchange版本相比在高可用性方面有了很大的改进。最主要的体现莫过于LCR(Local Continuous Replication)和CCR(Cluster Continuous Replication)技术了。我们主要看一下LCR技术的实现。
LCR技术是一种单服务器解决方案，它可以在单服务器的环境下实现邮件
数据库的高可用。它是通过内置的异步日志传送技术在同一服务器的不同区域维护
Exchange存储组的副本。当存储组的主动副本出现问题后，我们可以在最短的时间内切换到被动副本，显著降低
数据库的还原时间。原理如下图：
注意：
LCR不是备份技术，部署了
LCR并不代表不再需要备份。
LCR的作用是显著降低
exchange数据库的还原时间，而不能代替备份。但是我们可以延长平时的备份周期。
实验环境：
Exchange Server 2007 + Windows server 2003 R2
在开始之前已经有了一个存储组：
SG3。存放位置为：
c:\SG3。而且此存储组中已经有了一个邮箱
数据库。
C:\下新建一个文件夹
SG3LCR用来存放此存储组的副本。如下图：
网管下载dl.bitscn.com 在此试验中，我们将另一块硬盘用来存放存储组的副本。为了还原
数据库时的方便，我们把分区设置成
NTFS卷装入点。如下图：
在这一步中，我们将第二块磁盘做成
NTFS卷装入到
c:\SG3LCR中。完成后的效果图如下：
接下来开始
LCR 的配置：
首先选中
SG3存储组，然后在右边的动作面板中选择“启用本地连续复制”，弹出如下图窗口：
网管联盟bitsCN_com
在此我们选择
LCR目标系统路径和日志路径，就是刚才的卷装入点位置。
填入本地连续复制
数据库的路径，也是在
NTFS卷装入点
c:\SG3下。在实际生产环境下我们建议将
数据库文件和日志文件放在不同的磁盘上。
经过两步，
LCR配置完成。其实在这个过程中
Exchange运行了很多任务，主要经历了以下步骤：
1. 检查当前的检查点文件
(E02.chk)，记录下当前检查点文件中关于日志的指针位置。并将邮箱
数据库文件从
c:\SG3\db\sg3data.edb 拷贝到
c:\SG3LCR\db下
2. 将检查点以后的事务日志文件copy到c:\SG3LCR\logs下，（我们可以看到在c:\SG3LCR\logs中，日志文件并不是从E0200000001开始的）
3. 把copy过来的事务日志文件重播到c:\SG3LCR\db\sg3data.edb中
此时我们打开存储组SG3的“属性”可以看到如下信息：
网管论坛bbs_bitsCN_com 在此窗口中，我们可以监视
LCR的状态，可以看到种子是否已经设定，复制状态如何，是否正在复制或重播日志等信息。当“重播队列长度”变成
0时表示当前的日志文件都已经重播到了
数据库中。此时在目录下会生成新的
E02.chk检查点文件。
整个过程可能需要一段时间，只有我们在此看到“重播队列长度”变成0，或被动副本日志文件夹中产生E02.chk才说明LCR配置完成。此时：
我们比较原存储组日志文件和LCR副本日志文件，会发现有几点不同：
1. LCR副本日志中没有E02.log文件
2. LCR副本日志文件不是从E0200000001开始的，而是从一个较高的数值开始。
3. LCR副本日志文件夹中新增了Ignoredlogs和inspector文件夹
4.
网管下载dl.bitscn.com
然后禁用“本地连续复制”，如下图：
此时我们可以把
c:\SG3\db\sg3data.edb这个邮箱
数据库文件删除以模拟原
数据库文件损坏。此时再对此
数据库无法挂载了。还原过程如下：
1． 把E02.log文件由c:\SG3\logs 拷贝到 c:\SG3LCR\logs中
2． 删除c:\SG3下的所有文件
3． 删除磁盘1在c:\SG3LCR的挂接点，然后把磁盘1挂接到c:\SG3下
4． 在
ESM中，对
sg3data.edb数据库进行重新加载。
网管网www.bitscn.com
对了,还原之后 要记得对此存储组再次配置LCR,保证其高可用性 .
评论加载中…
