利用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或是以上的补丁。

· 版本号	sql server 2005 版本
9.00.1399	sql server 2005（初始版本）
9.00.2047	sql server 2005 sp1
9.00.3042	sql server 2005 sp2

我们这里直接打sp2补丁：略

准备数据库：

条件 很重要：

主体数据库必须是完全恢复模式

创建镜像数据库

在主体数据库上做一个完全备份，在镜像服务器上使用norecover选项恢复主体数据库。

继续恢复后续日志备份（norecover） norecover 很重要

配置数据库镜像端点 （endpoint）

数据库镜像端点实现镜像会话的通讯，也就是各个服务器的入口点，有点类似于端口号。但不是。也就是说你创建了这个端点之后，各个服务器之间就可以使用tcp协议进行实例间的通讯。每个镜像端点上都在一个唯一的tcp端口号上侦听，一般大家都使用5022号端口。

创建数据库镜像端点：

需要在每个实例上创建

只有管理员组的成员才能权限。

设置端点角色 即有的是伙伴端点，有的是见证端点，所以必须要指定。

激活端点 默认是不能使用的，所以要激活。

下面我们看一下使用t-sql 语句创建端点

create endpoint dbmirroring

as tcp（listener_port=5022）当然也可以使用其他端口，只要没有被使用

for database_mirroring(role=partner,encryption=supported) go

-- 创建的是一个数据库镜像端点，角色是伙伴，通讯过程是通过加密的。

alter endpoint dbmirroring state=started go --激活

此时这个端点就开始侦听了。

创建见证服务器的端点：创建的时候激活端点。

create endpoint dbmirroring

state=started as tcp（listener_port=5022）

for database_mirroring (role=witness,encryption=supported)

配置安全性：

数据库镜像中的实例之间必须可信 都使用windows 身份验证或是基于证书的身份验证（非信任域），为了简单为例，我们使用windows身份验证。

赋予服务帐户对端点的连接权限。

在这里我们都使用相同的用户名口令

下面我们创建完端点后就要启动数据库镜像，注意顺序很重要

指定镜像数据库的伙伴 在镜像服务器上操作

指定主体数据库伙伴 在主体服务器上操作

指定见证服务器 在见证服务器上操作

指定事务安全选项 full 还是 off

对应语句分别是：

alter database nothwind set partner=n'tcp：/server1h:5022'

–-在server2（镜像）上执行

alter database nothwind set partner=n'tcp:/server2:5022'

--在server1（主体）上执行

alter database nothwind set witness=n'tcp:/server3:5022'

--在server1（主体）上执行

alter database nothwind set safety full;

--在server1（主体）上执行 高可用性

当然也可以使用smss

那么完成之后怎么来查看数据库镜像是否完成，可以通过以下两种方法：

smss 数据库属性---镜像状态

t-sql

select * from sys.database——mirroring

select * from sys.database——mirroring——witness

下面我们具体看一下配置高可用性数据库镜像

我们使用t-sql 可以很明显的看到配置的过程。

下面我来介绍一下我们所使用的环境：

server1为主体服务器

server2为镜像服务器

server3 为见证服务器

首先我们要

准备数据库：一个是备份主体数据库，一个是在镜像服务器上恢复。

所以

在serve1上：

backup database northwind to disk='c:\nw.bak'

在 server2上：

restore database northwind from disk='c:\nw.bak' with norecovery

创建数据库端点：

1． 在server1上创建数据库镜像端点，用于伙伴通讯

create endpoint dbmirrep as tcp (listener_port=5022)

for database_mirroring (role=partner,encryption=supported );

alter endpoint dbmirrep state=started

通过图形界面可以查看到

2． 在server2上创建数据库端点，也是用于伙伴通讯

create endpoint dbmirrep as tcp (listener_port=5022)

for database_mirroring (role=partner,encryption=supported)

alter endpoint dbmirrep state=started

3． 在server3上创建镜像端点，用于见证通讯

create endpoint dbmirrep as tcp （listener_port=5022）

for database_mirroring (role=witness,encryption=supported)

alterendpointdbmirrepstate=started

4． 检查端点配置

select * from sys.database_mirroring_endpoints

也可以通过图形界面查看

配置数据库镜像安全性：也就是指定哪些用户可以使用这个端点。肯定是管理员，一般用户不让他访问。

分别执行:

grant connect on endpoint::"dbmirrep" to "server1\dufei"

grant connect on endpoint::"dbmirrep" to "server2\dufei"

grant connect on endpoint::"dbmirrep" to "server3\dufei"

最后一个就是启动数据库镜像。注意：顺序 首先要从镜像服务上配置

在server2上，指定伙伴端点：

alter database itet set partner='tcp://server1:5022'

在server1上，指定伙伴端点：

alter database itet set partner='tcp://server2:5022' –查看数据库

--到此为止，就是咱们前面所介绍的高级别保护模式。可以实现数据完整性，但是不能实现高可用性。所以还要继续，也就是说到这里为止，不要见证服务器也可以，但是不能实现故障的自动转移：

在 server1上，指定见证服务器端点：

alter database itet set witness=n'tcp://server3:5022'

设置数据库镜像事务安全级别：

alter database itet set safety full

实验结束,但一定要注意细节

最后看一下数据库镜像角色切换：也就是如何实现故障转移

自动故障转移：

只针对高可用性模式

safety=full

测试：禁用主服务器的网卡，查看库状态，再启用再查看

我们到这里已经知道了如何实现数据库镜像，那么用户如何来使用：客户端都是连接到主体服务器上进行工作的。那么如果主体服务器不可用了，那么就会造成用户连接的失败，它怎么知道去自动连接镜像服务器，这里一般使用ado技术，如asp.net 或是微软所提借的连接工具。

我们这里借助windows 的集群功能：来进行测试：

server1与server2配置成windows集群：

实验到此结束!

本文出自 “杜飞” 博客