16.5 故障转移

16.5  故障转移

16.5.1  故障转移模式

  在新建可用性组时,默认不选择“自动故障转移”和“同步提交”,可以根据实际业务的需求指定“自动故障转移”(最多可指定2个副本)和“同步提交”(最多可指定3个副本)。

  与数据库镜像的可用性模式类似,AlwaysOn 可用性组可以有以下3种高可用模式可供选择。

(1)自动故障转移和同步提交。选择了“自动故障转移”,则系统将自动同时选择“同步提交”。此副本将使用同步提交可用性模式,同时支持自动故障转移和手动故障转移,不会丢失数据。

(2)手动故障转移和同步提交。即仅选择“同步提交”。此副本将使用同步提交可用性模式,仅支持手动故障转移,不会丢失数据。

(3)手动故障转移和异步提交。即“自动故障转移”和“同步提交”都不选择。此副本将使用异步提交可用性模式,且只支持强制故障转移(可能丢失数据)。

  在可用性组的“属性”中,也可以编辑“可用性模式”和“故障转移模式”。如果“故障转移模式”设置为“自动”,但“可用性模式”不会自动设置为“同步提交”,需要手动确认。

  对于同步提交的辅助副本,其同步状态将显示为“已同步”,对于异步提交的辅助副本,其同步状态则显示为“正在同步”。

16.5.2  自动故障转移

  检测到主副本发生故障后,故障转移群集服务将自动转移到“故障转移模式”为“自动”的辅助副本。

16.5.3  手动故障转移

  在 SSMS 中选择一个可用性组,然后在右键菜单中选择“故障转移”。在“显示面板”中也有“启动故障转移向导”的链接。

  上述操作,脚本为:


--- YOU MUST EXECUTE THE FOLLOWING SCRIPT IN SQLCMD MODE.

:Connect SQLSVR2

ALTER AVAILABILITY GROUP [HAGroup01] FAILOVER;

GO

16.5.4  强制转移

  遇到主副本发生故障,而自动故障转移又不能成功时,可能需要强制将某个辅助副本提升为主副本。

  需要在辅助副本上执行以下脚本。这个操作可能会造成数据丢失,请谨慎使用。

ALTER AVAILABILITY GROUP [HAGroup01] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  强制切换之后,新的主副本上数据库显示为“已同步”,其他辅助副本上数据库则显示为“未同步”。

  强制转移后,当辅助副本重新联机后,可以分别在辅助副本上运行以下脚本,同步数据更新。


ALTER DATABASE [SQLDB01] SET HADR RESUME;

ALTER DATABASE [SQLDB02] SET HADR RESUME;

  上述脚本执行成功后,辅助副本上的数据库状态将显示为“已同步”(同步提交模式)或“正在同步”(异步提交模式)。

时间: 2024-12-28 01:31:37

16.5 故障转移的相关文章

测试ReplicaSets读写分离和故障转移

读写分离实现步骤: 从库能够进行查询就更好了,这样可以分担主库的大量的查询请求. 1) 先向主库中插入一条测试数据 rs1:PRIMARY> db.c1.insert({age:30});db.c1.insert({age:30}); WriteResult({ "nInserted" : 1 }) rs1:PRIMARY>  db.c1.find() db.c1.find() { "_id" : ObjectId("5791ef011f4c6

案例分享:数据库镜像故障转移失败

案例分享:数据库镜像故障转移失败 对于关键性数据库,我们配置了带有见证服务器的同步数据库镜像,来允许自动故障转移.一切运行正常,直到有一次数据中心的突然断电.数据库镜像执行了故障转移,但是运维反馈说应用程序挂起了.当我们手动切换回来,应用程序又正常工作.为什么应用程序没有也故障转移呢? 这是使用数据库镜像的合理的常见问题,像这样的生产应用失败,是因为在镜像部署后没有做故障转移测试.在失败的故障转移之后我们感到棘手. 为了避免生产应用停机,我们在测试环境复制了线上的镜像环境.在确认应用和数据库镜像

redis演练(7) redis Sentinel实现故障转移

书接上文<redis演练(6) redis主从模式搭建>. <redis演练(6) redis主从模式搭建>中仅仅配置了redis主从环境.分别配置了2个主从结构. 分别是1.有向无环,2星型模型.配置起来非常简单.但是,遗留了一个尾巴,没有阐述.如果master宕掉了怎么办?redis如何实现fail-over故障转移?本文,就重点说一下这块.主要内容 手动实现fail-over效果 sentinel实现自动fail-over效果 手动实现fail-over效果 #有向无环模型(

部署SQL Server2008 R2故障转移群集

配置Sql Server故障转移集群 环境:使用VMware 12虚拟机搭建环境 系统 网卡及IP配置 服务 Windows Server 2008 R2 IP:192.168.1.1 GW:192.168.1.1 DNS:192.168.1.1 搭建域控制器为abc.com Windows Server 2008 R2 网卡1: IP:192.168.1.2 GW:192.168.1.1 DNS:192.168.1.1 网卡2: IP:172.16.10.1(心跳网络) 网卡3: IP:192

MySQL 高可用MHA安装部署以及故障转移详细资料汇总 转

http://blog.itpub.net/26230597/cid-87082-list-2/ 1,简介 1.1mha简介 MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性. MHA(Master High Availability)是自动的master故障转移和Sl

sql server 2008 故障转移群集

数据库群集的分类: (1)主动/被动群集(常用模式) 布署简单.比较安全.应用广泛 .资源利用率低 (2)主动/主动群集 没有闲置节点,资源利用率高.安全性差,争抢资源 (3)N+1群集(较好模式) 一定程度上克服了资源利用率低和争抢资源的问题  .多个实例同时出问题时才存在争抢资源的问题 操作系统参数表 主机名 操作系统 IP地址 磁盘 用户 备注 DC01 Win Ser2008 R2 Enterprise Public:192.168.1.101 子网:255.255.255.0 DNS:

MHA mysql主从故障转移

MHA 一.MHA介绍 1 二.部署MHA 2 1.部署MHA Node 2 2.安装MHA Manager 3 3.配置SSH登录无密码验证 3 4.搭建主从复制环境 3 5.配置MHA 4 6.检查SSH配置 8 7.检查SSH配置 8 8.检查MHA Manager状态 8 9.开启MHA Manager监控 8 10.关闭MHA Manager监控 8 11.MHA引入VIP 8 三.自动Failover 17 四.手动Failover(MHA Manager必须没有运行) 19 五.在

MySQL 高可用MHA安装部署以及故障转移详细资料汇总

1,简介 1.1mha简介 MHA,即MasterHigh Availability Manager and Tools for MySQL,是日本的一位MySQL专家采用Perl语言编写的一个脚本管理工具,该工具仅适用于MySQLReplication(二层)环境,目的在于维持Master主库的高可用性. MHA(Master High Availability)是自动的master故障转移和Slave提升的软件包.它是基于标准的MySQL复制(异步/半同步). MHA有两部分组成:MHA M

32SkypeForBusiness2015进阶篇--故障转移节点

6.3.16 故障转移节点