AlwaysOn可用性组功能测试(1)-故障转移测试

blog已经转移至github,大家请访问 http://qaseven.github.io/

　一、 AlwaysOn可用性组故障转移测试

　　1. 自动故障转移

　　1.1 将故障转移模式改成自动，如果实例为SQL Server故障转移实例则配置无效。

　　1.2 在SERVER03自动转移，CLUSTEST03\CLUSTEST03手动转移的情况下，kill SERVER03的SQL Server服务。如下界面

　　1.3 无法发送自动故障转移，整个可用性主失败，如下所示

　　2. 计划手动故障转移

　　2.1 计划手动故障转移，需要将可用性模式改成同步提交，待所有副本都同步后，开始手动转移

　　2.3 选择新主副本，由于是同步提交，没有数据丢失

　　2.4 转移摘要，需确认转移信息

　　2.5 开始转移，以下是转移成功界面

　　3. 强制手动故障转移

　　3.1 强制转移，可用性模式为异步提交模式，以下是故障转移向导

　　3.3 确认可能丢失数据，为防止误操作，若确认如下界面

　　3.4 开始故障转移，以下是转移成功界面。

　　3.5 以下是强制故障转移后，可用性组的同步情况，可以看出全部挂起，可用性组已经断开。

　　总结测试

　　A. AlwaysOn可用性组的可用性副本，若有在SQL Server故障转移群集上，则无法配置为自动故障转移。

　　B. 计划手动故障转移前，需要将可用性模式该成同步模式，且需要等待所有副本已同步，才可以切换

　　C. 强制手动故障转移会有数据丢失

　　D. 强制手动故障转移后，该可用性组将挂起，无法实现数据同步

　　E. 任何故障转移需要在，新副本上执行转移语句。

posted on 2014-11-13 10:06 顺其自然EVO 阅读(1283) 评论(0) 编辑收藏所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。




网站导航: 博客园 IT新闻知识库 C++博客博问管理
相关文章: 如何进行Web服务的性能测试？利用drozer进行Android渗透测试 Appium Android Bootstrap源码分析之命令解析执行 Fliptest—iOS 的应用A/B测试框架 iOS功能测试工具 Frank iOS单元测试框架Kiwi for iOS Appium Android Bootstrap之控件AndroidElement 移动应用测试框架—Calabash Android 简介 Appium Server源码分析之作为Bootstrap客户端移植MonkeyRunner的图片对比功能实现-Appium篇

qileilove