SQL Server的“高可用性”与“灾难恢复” 之四 数据库镜像

根据前面的介绍读者会发现，故障转移群集技术和日志传送技术都不是那么“完美”。故障转移群集可以让系统在遇到故障时自动恢复，但是不能提供数据冗余，以对抗数据库损坏事故。日志传送可以提供冗余的数据拷贝，但是主数据库和辅助数据库之间的时间差可能比较长，故障切换也比较麻烦。所以仅有这两种技术，还是不能满足SQLServer用户的需求。

数据库镜像功能首次出现在SQL Server 2005 SP1中。它设计的目的是试图为SQL Server提供一个具有实时性数据同步的灾难恢复技术，即能提供数据冗余备份，切换起来也比较方便。相比较故障转移群集，数据库镜像同样也能够为客户端应用提供统一的连接方式，但同时它又具备故障转移群集所没有的抵御数据损失的能力。相对日志传送，它进行灾难切换要快很多，又基本对客户端应用透明。这些优点都使得数据库镜像成为了一项兼备高可用性和灾难恢复功能的技术。现在，数据库镜像技术在企业客户环境中，使用得越来越多了。

数据库镜像的基本概念

相对前两种技术，数据库镜像技术要相对更加复杂一些。本节先介绍数据库镜像里的基本术语和角色。

数据库镜像会为目标数据库创建一个副本数据库。这两个数据库分别运行在不同的SQLServer实例上，作为“伙伴”建立一个会话（session）。通过这个对话，两个数据库互相进行通信和协作，扮演互补的角色：“主体角色”和“镜像角色”，以实现“镜像”的效果。在任何给定的时间，都是一个伙伴扮演主体角色，而另一个伙伴扮演镜像角色。扮演主体角色的数据库就是主体数据库（principaldatabase），另一个扮演镜像角色的数据库则是镜像数据库（mirror database）。每个主体数据库只能有一个镜像数据库。镜像数据库作为主体数据库的一个副本，在主体数据库发生故障、不可访问时，能迅速恢复数据库访问，提供了灾难恢复的功能。

只有使用完整恢复模式的数据库才能使用数据库镜像功能。主体数据库可以象一个普通数据库一样，执行数据库查询、修改、数据库管理操作。只有很少的操作（比如还原数据库备份）由于数据库镜像的限制而不被允许执行。而镜像数据库是一个一直处于“恢复”状态的数据库，因此是不能被直接访问的。这点和日志传送不一样。但是，你可以为镜像数据库创建一个快照，这样就可以间接地访问镜像数据库里的数据了。那些用作报表查询的应用可以通过镜像服务器的快照来获取数据，这能减轻主体服务器的工作负载。

需要特别指出，只有用户数据库才能配置数据库镜像，所有的系统数据库都不能被镜像，对于系统数据库还是需要通过备份的方式来保障安全。

运行主体数据库的SQL Server实例被称为主体服务器（principalserver），而运行镜像数据库的SQL Server被称为镜像服务器（mirrorserver）。主体服务器和镜像服务器必须是两个不同的SQL Server实例。这两个实例上可以有多个数据库镜像的会话。这两个实例可以运行在同一台计算机上，但是一般不建议这么做。因为这种配置下，一旦服务器的磁盘发生物理损坏，那么主体数据库和镜像数据库就都无法使用了，灾难恢复也就无从谈起了。

 

配置了多个会话的数据库镜像（无见证服务器）

每个数据库镜像的会话都只针对一个用户数据库，而且是独立的。例如，一个应用程序需要同时访问一个SQL服务器实例上的两个数据库，那管理员就需要配置两个镜像会话。如果其中一个数据库发生故障，它的镜像会将数据库转移到镜像服务器上，而另一个工作正常的数据库则继续在主体服务器上运行。这时对SQLServer来讲，两个数据库都能被使用。但是对应用程序来讲，它就变得无所适从，连接哪个服务器都不能正常工作。由于镜像数据库相互独立，这些数据库不能作为一个组来进行故障转移。这是数据库镜像的一个很大限制。

除了主体服务器和镜像服务器之外，数据库镜像还可以配置一个叫做“见证服务器”（witnessserver）的SQL Server实例。见证服务器不是必须的。有了见证服务器，主体数据库和镜像数据库除了保持和伙伴的会话，也会和见证服务器进行对话。见证服务器上没有数据库的副本，它只是做为一个中立的仲裁，和主体/镜像服务器建立会话，判定数据库的健康状况，并在主体数据库发生异常的时候，触发自动的故障转移，让镜像数据库和主体数据库转换角色。见证服务器必须是一个独立于主体服务器和镜像服务器的实例。多个数据库镜像伙伴（无论它们是否使用相同的主体服务器和镜像服务器）可以共用一个见证服务器。最佳情况下，见证服务器实例应该配置在一台单独的计算机上，这样见证服务器的工作不会受到主体或镜像服务器异常的干扰。如果必须将见证服务器和镜像伙伴中某个实例运行在同一台机器上的话，要确保该机器具有足够资源以减少两个实例的资源争用。

可以说，配置了见证数据库的数据库镜像兼备了高可用性和灾难恢复的功能。如果数据库镜像没有配置见证服务器，就无法实现自动的故障转移。一旦主体数据库发生异常，数据库管理员需要手动进行故障转移。

配置了一个会话的数据库镜像（有见证服务器）

主体服务器，镜像服务器和见证服务器实例上都会建有一个叫做“端点”（endpoint）的对象，每个端点都侦听在一个TCP的端口上，默认的端口是5022。主体服务器，镜像服务器和见证服务器三者就是通过建立在实例上的端点，向另两个服务器发送TCP数据包来进行“会话”。一个SQL Server实例上，无论配置有多少个数据库镜像会话，它们都只使用唯一的端点。如果这三个实例中的某两个运行在同一台机器上，要确保这两个实例上的端点侦听在不同的TCP端口上。

到这里，数据库镜像的基本概念讲得差不多了。那主体数据库和镜像数据库是如何同步数据的呢？

SQL Server数据库中任何的数据变化都会先记录到事务日志中去，然后才会真正更新数据页面。而事务日志是先保存在该数据库的日志缓存（logbuffer）里，然后将缓存中的日志块固化到磁盘上的LDF文件中去。在数据库镜像中，主体服务器在将主体数据库的日志从日志缓存固化到磁盘的同时，还会使用另一个线程来将日志块发送到镜像服务器的端点。当镜像服务器通过端点接收到日志块之后，它先将日志块放到镜像数据库的日志缓存里，然后将缓存里的日志块固化到磁盘上。一旦日志块被固化之后，镜像服务器会根据日志来对镜像数据库执行“重做”（redo），最终更新数据页面。当镜像服务器重做日志时，镜像数据库实际就是在执行日志的前滚操作。如果重做失败，则镜像服务器通过将数据库置于SUSPENDED 状态来暂停会话。数据库管理员必须找到问题的原因并解决问题才能继续会话。当主体服务器截断或收缩主体数据库的日志时，镜像服务器也将在日志的同一点收缩日志。

可以看到，数据库镜像其实就是通过发送日志来保持伙伴之间的同步。从SQLServer 2008开始，日志块在被主体服务器发送到网络之前会做压缩处理。这么做的目的是为了提升日志发送和接受的效率，降低日志块传输对网络链路和网络设备所带来的负载。对于那些异常繁忙的生产系统，这项功能不但降低了由于网络不胜负荷导致的镜像对话异常中断，也降低由于网络延迟导致的数据库镜像性能问题，可谓一举两得。

无论日志块压缩与否，主体数据库上新日志生成的速率都可能会快于日志发送的速率，有些日志记录会来不及发送，而在主服务器上暂时“积累”起来。这部分累积未发送的日志产生了一个队列，叫做发送队列（sendqueue）。发送队列不会占用主服务器上额外的存储空间或者是内存，它是存在于主体数据库的事务日志文件(LDF)上。事务日志里会有一个标记，指向所有没被发送到镜像服务器的日志记录中最早的那个。那么从这个标记开始到最新的日志为止就是“发送队列”。主体服务器就不断地从这个队列中取出最早的日志，并发送给镜像数据库。

在镜像数据库里，如果日志重做的速度如果赶不上日志在镜像端固化的速度，那么也在镜像数据库的LDF文件中等待重做的事务也会产生一个队列，叫做重做队列（redo queue）。和发送队列类似，重做队列也不使用额外的存储空间和内存。它仅是使用一个标记，指向镜像数据库的事务日志文件中最早的那个还未重做的日志。镜像服务器从这个标记开始按顺序重做日志，更新数据。重做队列中等待的未重做日志数量决定了故障转移到镜像数据库所要花费的时间。

通过上面的介绍可以发现，数据库镜像技术和日志传送一样，其同步的信息也是日志记录，而不是数据操作命令。它们不同的是，日志传送是通过数据库日志备份和恢复。而数据库镜像更“直接”，