本文接着前面的章节:SQL Server镜像简单介绍
本文出处: http://blog.csdn.net/dba_huangzj/article/details/27203053俗话说:工欲善其事必先利其器。计划好怎样部署和使用镜像,能够降低非常多不必要的风险。
本文将依照三步骤的形式展示。可是要注意这不是唯一的标准,详细情况详细分析。
第一步:了解环境
在搭建SQL Server镜像时,必须先了解你所要部署的环境。才干决定镜像的配置项。
这不仅是镜像配置的前提,也是部署SQL Server甚至搭建数据平台和其它高可用都应该做的事情。以下是一些常见的须要了解的问题:
- server是否已经准备好
- 数据库是否已经准备好
- 是否知道所需的服务帐号
- 是否了解数据库的大小
- 镜像server和主体server的性能情况
- 是否须要和其它技术组合
以下详细介绍一下这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可能也会停止响应。这会导致搭建镜像的初衷荡然无存。毕竟搭建镜像主要就是针对这样的情况。
是否须要和其它技术组合:
在企业级应用中。非常少仅仅使用单纯的一种高可用技术,可能会使用镜像搭配复制、日志传输甚至集群。
当混合使用的时候,须要更严谨的測试。兴许将会提到。
第二步:了解应用程序:
除了了解镜像环境的硬件部分,也要了解软件部分,也就是执行在这个环境下的应用程序。这些应用中,有些是“黑盒”,特别是第三方软件。对于这方面的内容,须要考虑的有:
- 应用程序是怎样连到server的
- 是否有不支持自己主动Failover的组件
- 应用程序是否依赖其它库
- 应用程序是否依赖外部资源
应用程序是怎样连到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地址訪问。
第三步:检验计划:
- 在主体server和镜像server上建立所需的帐号,建议使用专用的域账号,并做好归档处理,避免其它维护人员或者时间过久之后连自己都不记得账号password。
- 镜像库不建议使用sa作为owner。
- 假设CLR依赖TRUSTWORTHY配置,须要在初始化Failover之后配置。能够通过使用同样的数据库owner来解决。即镜像库和主体库在搭建过程中就要尽可能保持全然一致,包含数据库的owner。
- 在镜像配置过程中确保全部数据库备份的作业都禁用,完整备份和日志备份都将影响镜像server恢复失败。
- 确保完整模式下配置镜像。
- 确保镜像server和主体server上相关数据库的数据文件及日志文件名称字、路径都全然一样。顺带说一句,系统库不可做镜像。
实践建议:
- 使用与主体server性能尽可能接近的镜像server。
- 使用专用网络用于镜像环境的传输数据。网络和磁盘I/O往往是镜像和其它高可用技术的常见瓶颈。特别是在大事务量传输时。
- 在高性能模式下不要使用见证server。否则有引起服务丢失的风险,当见证不能连接主体或镜像时,另外一个伙伴会由于丢失仲裁而offline。
- 使用同样的盘符和文件路径。
- 在測试环境中进行压力測试。确保镜像环境不是一个幌子,而是真正能协助业务连续性的功能。
- 在生产环境中。先使用异步方式执行,假设性能满足。切换到同步模式,假设同步模式也满足,再加入见证server。
- SQL Server最好使用2005 的SP2(带有CU6)。或者2008。推荐使用2008R2。
- 确保镜像和主体server是同样的SP和SQL Server版本号。
- 使用同样的排序规则。
- 维护计划不支持镜像功能,须要额外编程,针对sys.databases中的state字段做处理。在《SQL Server镜像日常维护》一文中介绍。
- 保存镜像的配置脚本及文件。以便高速重建及版本号管控。
- 不要把伙伴的timeout时间设为小于10秒。过小的timeout会影响镜像的正常执行,可是从实践来说。并非越长越好。一般上限是30~50秒。
- 初始化镜像时能够暂时使用logshipping同步。Logshipping也能够作为高性能模式下的辅助功能。
- 监控msdb中suspect_pages系统表,用于修复torn pages。
- 避免使用同样的交换机或者路由器用于连接主体和镜像。主要原因是避免由于交换机、路由器同一时候出现问题而影响整个网络环境。
- 确保镜像所需的port没有被占用,搭建一文会延时。镜像须要某些port,尽管不强制。可是要指定,所以网络不仅要连通,还要port可Telnet,防火墙的配置也要考虑。
配置SQL Server镜像——域环境:http://blog.csdn.net/dba_huangzj/article/details/28904503
版权声明:本文博主原创文章。博客,未经同意不得转载。
本文转自mfrbuaa博客园博客,原文链接:http://www.cnblogs.com/mfrbuaa/p/4883023.html,如需转载请自行联系原作者