三——第二部分——第二篇论文 计划建设SQL Server镜像

本文接着前面的章节：SQL Server镜像简单介绍　　

本文出处：http://blog.csdn.net/dba_huangzj/article/details/27203053

俗话说：工欲善其事必先利其器。计划好怎样部署和使用镜像，可以下降很是多没必要要的风险。

本文将依照三步骤的形式展现。但是要注意这不是惟一的标准，详细状况详细分析。

第一步：了解环境

　　在搭建SQL Server镜像时，必须先了解你所要部署的环境。才干决定镜像的配置项。

这不只是镜像配置的前提，也是部署SQL Server甚至搭建数据平台和其它高可用都应该作的事情。如下是一些常见的需要了解的问题：

1. server是否已经准备好
2. 数据库是否已经准备好
3. 是否知道所需的服务账号
4. 是否了解数据库的大小
5. 镜像server和主体server的性能状况
6. 是否需要和其它技术组合

　　如下详细介绍一下这6点：

server是否已经准备好：

　　依据镜像的要求，必须使用SQL Server 2005 SP1以上的版本号，SP1是第一个全然支持镜像功能的版本号。理想状况下。主体server和镜像server所使用的操做系统和sqlserver的版本号尽可能全然一致。对于SQL Server版本号，必须是企业版或者标准版。除此以外，数据库的数据文件和日志文件所在的盘符和文件夹名必须一致，假设不一致，当主体库把事务发送到镜像库时会因为没法识别从而引发报错。

　　假设引入了见证server，可以执行在工做组或者express版本号上。

数据库是否已经准备好：

　　首先需要确保没有文件组使用filestream选项。因为filestream是经过T-SQL操做本地文件，镜像没法在镜像server中读取主体server上的文件。

　　其次，镜像环境要求完整恢复模式。

是否知道所需的服务帐号：

　　在部署过程当中，最简单的就是使用域帐号。

假设使用一样的服务账号。就不需要在端点中受权。

假设使用本地系统账号执行镜像，必须使用证书受权来替代Windows受权。当使用证书时。需要注意证书的过时时间。和其它最佳实践同样，假设不能使用域帐号，建议使用专用的帐号操做

是否了解数据库的大小：

　　假设需要作镜像的库很是大，在初始化的过程当中就要考虑到可能的风险。因为通常步骤是先作完整备份，而后传输备份到镜像server而后再还原。而后再在主体数据库上作日志备份再还原到镜像中，这个步骤可能需要好几个小时。

假设此时业务自己就比較繁忙。加上镜像库需要追上主体库的进度，会致使严重的性能问题，最起码网络传输压力会很是大。

　　针对这样的状况，可以使用log shipping功能进行传输。注意使用NORECOVERY选项而不要用STANDBY选项。在搭建镜像一文中会提到，镜像库需要使用NORECOVERY状态。

 

镜像server和主体server的性能状况：

　　理想状况下。镜像server的性能应该接近主体server。因为在Failover的时候可能会短时间接管主体server的所有请求，假设镜像server性能过低，会致使用户响应速度变慢。极端状况下，镜像server可能会在短时间内承受不了原主体server带来的压力直接崩溃。也就是说镜像server可能也会中止响应。这会致使搭建镜像的初衷荡然无存。毕竟搭建镜像主要就是针对这样的状况。

 

是否需要和其它技术组合:

　　在企业级应用中。很是少仅仅使用单纯的一种高可用技术，可能会使用镜像搭配复制、日志传输甚至集群。

当混合使用的时候，需要更严谨的測试。兴许将会提到。

 

第二步：了解应用程序：

　　除了了解镜像环境的硬件部分，也要了解软件部分，也就是执行在这个环境下的应用程序。这些应用中，有些是“黑盒”，特别是第三方软件。对于这方面的内容，需要考虑的有：

1. 应用程序是怎样连到server的
2. 是否有不支持本身主动Failover的组件
3. 应用程序是否依赖其它库
4. 应用程序是否依赖外部资源

应用程序是怎样连到server的：

　　假设需要支持镜像。应用程序需要使用SQL Native Client、ADO.NET 2.0 Data Provider或者JDBC 1.1 Driver for SQL Server。并且链接字符串需要使用Failover partner属性。

假设搭建了镜像。而不加入Failover Partner属性，那么就要每次在Failover时手动改动应用程序的链接字符串。这会影响程序的业务持续性。

是否有不支持本身主动Failover的组件：

　　假设如DTS包、SSIS包或者外部应用使用了不支持镜像的链接协议，需要评估在进行Failover的时候的影响还要制定应对策略。常见的处理手段是把这些组件拷贝到镜像server并配置链接到镜像库中。

应用程序是否依赖其它库：

　　镜像是库级的高可用方案，假设应用程序需要使用多个数据库协同执行时。仅对一个库作镜像是不可行的。针对这样的状况。可以把所依赖的所有库都作镜像，并且使用触发器检測镜像状态。仅仅要有一个库的状态知足Failover。就强制把所有库都进行Failover。这需要额外的编程。

应用程序是否依赖外部资源：

　　假设应用程序依赖本机server的资源，Failover会致使应用程序出现意外，针对这样的状况。可以考虑把外部资源放到共享文件夹上，并用UNC地址訪问。

 

第三步：检验计划：

1. 在主体server和镜像server上创建所需的账号，建议使用专用的域帐号，并作好归档处理，避免其它维护人员或者时间太久以后连本身都不记得帐号password。

2. 镜像库不建议使用sa做为owner。

3. 假设CLR依赖TRUSTWORTHY配置，需要在初始化Failover以后配置。可以经过使用一样的数据库owner来解决。即镜像库和主体库在搭建过程当中就要尽量保持全然一致，包含数据库的owner。

4. 在镜像配置过程当中确保所有数据库备份的做业都禁用，完整备份和日志备份都将影响镜像server恢复失败。
5. 确保完整模式下配置镜像。
6. 确保镜像server和主体server上相关数据库的数据文件及日志文件名称字、路径都全然同样。顺带说一句，系统库不可作镜像。

 

实践建议：

1. 使用与主体server性能尽量接近的镜像server。

2. 使用专用网络用于镜像环境的传输数据。网络和磁盘I/O每每是镜像和其它高可用技术的常见瓶颈。特别是在大事务量传输时。
3. 在高性能模式下不要使用见证server。不然有引发服务丢失的风险，当见证不能链接主体或镜像时，另一个伙伴会因为丢失仲裁而offline。

4. 使用一样的盘符和文件路径。
5. 在測试环境中进行压力測试。确保镜像环境不是一个幌子，而是真正能协助业务连续性的功能。
6. 在生产环境中。先使用异步方式执行，假设性能知足。切换到同步模式，假设同步模式也知足，再加入见证server。
7. SQL Server最好使用2005 的SP2（带有CU6）。或者2008。推荐使用2008R2。
8. 确保镜像和主体server是一样的SP和SQL Server版本号。
9. 使用一样的排序规则。

10. 维护计划不支持镜像功能，需要额外编程，针对sys.databases中的state字段作处理。在《SQL Server镜像平常维护》一文中介绍。
11. 保存镜像的配置脚本及文件。以便高速重建及版本号管控。
12. 不要把伙伴的timeout时间设为小于10秒。太小的timeout会影响镜像的正常执行，但是从实践来讲。并不是越长越好。通常上限是30~50秒。
13. 初始化镜像时可以暂时使用logshipping同步。Logshipping也可以做为高性能模式下的辅助功能。

14. 监控msdb中suspect_pages系统表，用于修复torn pages。
15. 避免使用一样的交换机或者路由器用于链接主体和镜像。主要缘由是避免因为交换机、路由器同一时候出现问题而影响整个网络环境。
16. 确保镜像所需的port没有被占用，搭建一文会延时。镜像需要某些port，尽管不强制。但是要指定，因此网络不只要连通，还要port可Telnet，防火墙的配置也要考虑。

本文中没有针对每个点进行展开，但是尽量会在后面的几篇中进行解决。

域环境下镜像搭建和非域环境下镜像搭建可以看接下的两篇文章：

配置SQL Server镜像——非域环境：http://blog.csdn.net/dba_huangzj/article/details/27652857
配置SQL Server镜像——域环境：http://blog.csdn.net/dba_huangzj/article/details/28904503