利用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)

   ALTER ENDPOINT DBMIRREP STATE =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集群：

 

实验到此结束!