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

转载自 http://dufei.blog.51cto.com/382644/84972 

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

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

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

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

 

 

 

 

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

 

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

 

 

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

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

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

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

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

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

 

 

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

 

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

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

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

 

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

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

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

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

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

 

 

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

 

 

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

 

 

 

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

 

 

高可用性：最常用的。

高级别保护

高性能

 

 

 

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