利用SQL SERVER 2005数据库镜像实现可用性分析

我们首先来看一下什么是数据镜像：

现在几乎所有的应用系统都是基于数据库的，那么数据库的负荷是比较大的，在一天24小时中，任何时间都有可能会有数据要保存到数据库，或是从数据库中读出数据。任意时刻都会有用户连接到我们的数据库服务器上，几十，几百甚至成千上万个用户来连接使用我们的数据库，那么不论是计划内的宕机还是计划外的故障都会造成一定的损失。给我们的用户或是企业带很大的损失，特别是随着数据时代的到来，用户对数据的使用提出了更高的要求，那么作为一个DBA，就要想怎么做才能将这个损失减少到最低，正是因为基于这种需求，数据库镜像技术出现了！SQL SERVER2005中首次提出了数据库镜像概念。特点：

基于软件的高可用性解决方案 那是完全基于软件的高可用性解决方案。不需要增加硬件成本，也就是低硬件成本

快速的故障转移恢复， 最主要的一个亮点，就是快速的故障转移恢复。3秒（对于用户或是DBA是特别有吸引力的） 数据量大的情况一般10秒.

在这个数据库镜像技术中有一个数据库服务器我们称为主数据库。它负责用户的连接和数据的处理。还有一个是从服务器，确切来说，这里应该叫镜像服务器，上面也有一个数据库，叫镜像数据库，这个数据库用于存放我们主数据库的一个热备份。也就是说它虽然不连接用户机，但是它对于主服务器上的数据更改呀，变化呀，都能做一个热备份，也就是说如果用户更新了主数据库中的内容，那么主数据库会根据镜像技术将更新传送给镜像服务器，这样就能保证主服务器和从服务器之间的数据是一致的，那么假如说由于某种原因，我们的主服务器或是主数据库不可用了，例如，网络中断，系统故障等等，那么客户端会重新定向到镜像服务器，那么客户端仍然能读取数据，写入数据，他感觉不到主数据库服务已经宕机了。所以采用数据库镜像技术以后，对于用户来说这个可用性就增强了，而且对于故障恢复时间也缩短了。那么客户仍然可以向镜像数据库上写数据。读数据，更新相关的事务，这是我们应用数据库镜像的一个过程。 想实现这个过程，必须要涉及到这么几个角色：

数据库镜像中的服务器角色：这几个角色刚才通过图形介绍了一点，那么在2005中有三种服务器角色，分别是

主体服务器：承载主体数据库

接受用户连接和事务处理请求 也就是说主体服务器正常的情况下就是主体服务器来提供服务

镜像服务器：承载镜像数据库

作为主体数据库的执备份 所谓热备份是说，主体数据库上的变化会立即反应硬驱镜像数据库上。

仅在故障转移后接受用户连接，处理事务请求

见证服务器：监视服务器状态和连接性，实现自动故障转移 也就是说见证服务器会时刻监视两个服务器的状态和连接性，当主体服务器发生宕机或者不可用以后，见证服务器会立即启用故障转移，将镜像服务器切换为主体服务器。继续为用户提供服务器

这是数据库镜像中的三个服务器角色，但是要注意一下就是这三个角色不是固定下来的，是可以变化的：

主体数据库和镜像数据库互为伙伴：

主体和镜像是可以相互转换的

故障转移后伙伴角色发生变化

当主体服务器正常的情况下，用户所有的连接及数据的更新都是直接送到主体服务器的，只不过是主体服务器再将数据备份到镜像服务器上，但是主体服务器不可用时，此时角色就发生了改变。镜像服务器就变成了主体服务器。那么如果原来的主体服务器恢复正常了，那么怎么办，它就会成为镜像服务器。所以它们的角色就彻底变化了。那如果这个服务器又不可用了。那么又是一个转换的过程。

那大家可能又要问一个问题就是这三个角色怎么知道到底哪一个可用，哪一个不可用：

各个服务器实例通过PING交换消息相互监视。与DOS命令的PING原理差不多，但是功能比DOS下的PING要强大的多，DOS下的PING只是检查网络的连通性，而此处的PING即要监视网络的连通性，这是第一步，还要监视数据库服务器实例的运行情况，服务器是否是正常的，还有就是这个服务器上的数据库是否正常。

总结一下数据库镜像工作过程：

正常情况下，配置好数据库镜像以后，用户只能连接主体数据库，但此时镜像数据库是不可用的。用户连上去也没有用。用户只能使用主体服务器时，主体服务器会将数据一方面写到自己的数据库中，另一方面通过事务日志的方式传给镜像服务器，写到镜像服务器的数据库，此时主体服务器会进入一个等待状态。等待镜像服务器的确认，也就是当镜像服务器的数据成功写入到镜像数据库以后会发一个消息给主体数据库，说我现在已经完成了数据的更新了也就是在镜像服务器上执行了一个REDO的过程。这是一个确认。当主体服务器收到这个确认以后会给客户端一个回应，说刚才的那个数据更新的操作已经完成了

那么为什么能实现一个快速恢复机制，这主要和2005中的一个机制是分不开的

但SQL 2005不是没有必要等到回滚结束只要在REDO之后就可以使用了，至于UNDO的操作，在用户使用的过程中你再继续UNDO，所以当主体服务器发生数据更新了，镜像服务器会以最短的时候来时间更新，以至于如果主体数据发生故障了，镜像服务器右以在最短的时间内接替主服务器进行工作。

下面来介绍一下数据库镜像中的三种操作模式：

高可用性：最常用的。

高级别保护

高性能

下面咱们分别来看一下这三种模式，当然最主要的就是高可用性，这是使用比较广的一个模式

高可用性模式：

服务器角色： 主体服务器 镜像服务器 见证服务器

应用场景：

要求高可用性的场合 如股票交易 证券交易 银行等。

要求实现自动故障转移

确保数据的完整： 要求只要是用户提交到服务器上的数据，那怕说数据刚提交上主体服务器就发生故障了，也能保证数据不会丢失。故障转移之后的数据是不会丢失，从而保证数据库的完整性

高级别保护模式：

我们从名称上也能看出来，它的重点在于对数据的一种保护，而不是实现可用性

服务器角色： 主体服务器 镜像服务器

应用场景：

高的数据完整性要求

不要求自动故障转移

对服务的可用性要求较低 也就是说主体数据库的宕机还是可以接受的，但是数据的丢失是不可以接受的，那么这种场合可以使用高级别保护模式

因为没有见证服务器，所以是不能进行自动的故障转移的。那如果主体服务器不可用，那么想实现故障转移，只能是手工完成，所以对服务器的可用性要求较低

高性能模式：

服务器角色： 主体服务器 镜像服务器

应用场景：

主体服务器和镜像服务器距离很远的时候 十几公里或是完全两个城市

通讯链路有明显的延迟

对性能的要求高于数据的完整性

原理是：当主体服务器收到用户的操作后，将此事务传给镜像服务器，因此距离远所以有明显的延迟，所以他不会等镜像服务器的确认，也就是说它不管这个数据到底有没有写到镜像服务器，所以这种模式就在于尽快的响应用户的请求，也就是对用户对性能有一个较高的要求，这个要求是高于数据的完整性。

这种模式下会存在数据的丢失，也就是说如果主体服务器宕机了，我们会把镜像服务器作为主体服务器，但是不能保证这里面的数据就是和主体服务器上的数据是一致的，因为有可能会有丢失。

我们对几个概念简单的介绍一下：

事务安全性：

FULL 主体和镜像数据库同步传输的模式，

主体在发送日志后等待镜像的确认

主体和镜像的日志完全一致

OFF

主体和发送日志后不等待镜像的确认，继续处理后继的操作。

主体失败时在镜像上可能丢失部分数据

仲裁：在高可用性或是高级别保护模式下需要仲裁。以决定那一个服务器是主体服务器，

仲裁的改变将导致故障转移，如主体服务器发生故障了，则会发生仲裁的改变，将镜像服务器定为主体服务器。

形成仲裁的形式一般有这么几种：

下面我们就来看一下如何配置数据库镜像： 这应该是大家感觉很兴奋的，因为听我西里哗拉的讲了半天。终于不用再受罪了。其实配置很简单的，只要注意几个步骤就行了。

准备镜像数据库 在镜像服务器上准备镜像数据库

创建数据库镜像端点 在各个服务器上配置镜像端点

配置安全性

启动数据库镜像

下面我们就具体看一下如何去做，有哪些需要注意：

这里需要提到的一点的就是在SQL SERVER2005刚刚发布出来的时候数据库镜像这个服务默认是关闭的，也是不支持的。在刚刚发布SQL SERVER2005正式版本的时候，认为数据库镜像这个技术还不成熟，有待完善。所以如果你使用的是正式版本则无法使用这个技术。

那么需要下载SP1或是以上的补丁。