SQLserver AlwaysOn 提交模式与节点的可用性

这篇具有很好参考价值的文章主要介绍了SQLserver AlwaysOn 提交模式与节点的可用性。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

接上文:https://www.cnblogs.com/wy123/p/17905118.html,关于AlwaysOn主副本与辅助副本之间提交模式与安全故障转移的话题
参考AlwaysOn属性面板中的信息

SQLserver AlwaysOn 提交模式与节点的可用性

1,主节点异步提交模式:如果主要副本配置为“异步提交模式” ,则从节点不管是同步或者异步,主节点提交事务都无须等待从节点(永远是异步模式)。 
2,主节点同步提交模式:需要分两种情况
  2.1 如果从节点是同步模式,则主节点与从节点同步提交(同步模式)
  2.2 如果从节点是异步模式,则主节点提交事务都无须等待从节点(异步模式)
3,上面截图备注中的备注:
  当一辅助副本超过了主副本的会话超时期限,则主副本将暂时切换到该辅助副本的异步提交模式。 在该辅助副本重新与主副本连接后,它们将恢复同步提交模式。
  上述第2.1中的情况,也就是同步提交模式,主结点提交事务等从提交同步提交,如果对应的从超时或者从节点自身宕机,同步模式将会自动退化为异步模式。
  此时同步提交模式退化为异步提交(这一点跟MySQL的半同步复制如出一辙,都存在主从同步模式退化的问题)。
 
那么这里先引出几个问题:
1,即便是同步模式,在某些条件下会自动“退化”为异步模式,此时主节点其实是在裸奔,最严重的是从节点直接宕机,主节点还可以正常读写,在某些高安全模式下是不允许单点运行的,这是可以被接受的吗,又如何破解?
2,上面截图中的Session Timeout是什么作用,可以理解成一个普通的连接超时时间吗?
3,截图中的参数required_synchronized_secondaries_to_commit,与节点之间的同步和异步模式有什么关系,该参数该如何理解?忽略此参数的情况下,所谓“自动故障转移”真的可靠吗?

同步提交模式退化为异步模式

如上截图,将SQL1和SQL2两个节点设置为同步模式,SQL1上执行的事务性操作,将会等待日志传送到SQL2节点之后再反馈给客户端提交成功的信息,这一点没有问题
select 
    r.replica_server_name,
    r.availability_mode,
    r.availability_mode_desc,
    r.failover_mode_desc,
    r.session_timeout,
    s.connected_state_desc
from sys.availability_replicas r inner join sys.dm_hadr_availability_replica_states s on s.replica_id = r.replica_id

SQLserver AlwaysOn 提交模式与节点的可用性

数据已同步到SQL1和SQL2两个节点

SQLserver AlwaysOn 提交模式与节点的可用性SQLserver AlwaysOn 提交模式与节点的可用性

目前SQL1和SQL2两个节点是同步模式,现在简单粗暴,直接关闭SQL2节点,模拟同步模式的辅助副本宕机的情况

SQLserver AlwaysOn 提交模式与节点的可用性

此时会发现,SQL1节点仍旧可以正常读写,这就是同步模式的退化机制,就是同步模式的辅助副本,不管是同步模式(这里SQL1和SQL2就是同步模式)或者异步模式,都不会影响主副本的读写。

其实此时主副本已经处于裸奔了,因为与他同步模式的辅助副本实际上已经下线。

这种情况下,主副本和辅助副本之间所谓的“同步提交”模式实际上形同虚设,实际上完整的数据实际上只有SQL1上的一份(SQL3是一步提交模式),极端情况下如果SQL1再宕机,存在数据丢失的风险。

SQLserver AlwaysOn 提交模式与节点的可用性

 

AlwaysOn节点中Session Timeout的作用

参考这里:https://learn.microsoft.com/zh-cn/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups?view=sql-server-ver15&redirectedfrom=MSDN

备注里提到的“如果某一辅助副本超过了主副本的会话超时期限,则主副本将暂时切换到该辅助副本的异步提交模式。 在该辅助副本重新与主副本连接后,它们将恢复同步提交模式。”

如果同步提交模式在祝福本会话超时之前,主节点在写入数据时时什么情况?再次实验,把SQL2节点正常启动,恢复同步提交模式,同时修改Session Timeout为一个较大的值,这里修改为600(默认是10秒)

SQLserver AlwaysOn 提交模式与节点的可用性

此时再次关闭SQL2节点,然后在SQL1节点上写入数据,会出现什么情况?参考截图,实际上这个insert语句的执行会一直等下去,直到超出上面设置的session timeout的值。

因此这里就有一个选择,在某些高安全的模式下,如果跟主副本同步提交的辅助副本宕机,主副本可选选择一会等待,直到辅助副本上线

SQLserver AlwaysOn 提交模式与节点的可用性

实际上这个SQL会一直执行到上面设置的Session Timeout,也就是600秒(读操作不受影响),这里执行到9分52秒是因为设置完这个时间,从关闭SQL2节点的MSSQL服务到SQL开始执行有几秒钟时间,超时时间是SQL1最早探测到SQL2下线开始计算

SQLserver AlwaysOn 提交模式与节点的可用性

令笔者意外的是,在上面这个SQL执行期间,启动SQL2上的服务,发现主副本(SQL1)上可以正常连接到SQL2,但是SQL2无法加入AG group,直至这个insert语句执行完成,SQL2才正常加入到AG Group中来。

 

required_synchronized_secondaries_to_commit

正如这个参数名字上的含义,主副本在写入数据时,要求同步提交到(N个)辅助副本,联系上面提交模式的选择,如果节点之间本身是异步提交模式,那么设置同步提交到N个节点是没有意义的,这里尝试将所有节点设置为异步提交模式,同时required_synchronized_secondaries_to_commit设置为1,尝试保持会发现直接报错:

“The Alter operation is not allowed by the current availability-group configuration. The required_synchronized_secondaries_to_commit 1 is greater than the 0 possible secondary synchronous-commit availability replicas in availability group 'ag1'. Change one of the existing asynchronous-commit replicas to the synchronous-commit availability mode, and retry the operation. (.Net SqlClient Data Provider)”

其实不难理解:既然要求同步提交打一个节点,那么节点之间必然是同步模式,如果是异步提交模式,就相互矛盾了。

SQLserver AlwaysOn 提交模式与节点的可用性

按照正常模式,设置SQL1和SQL2之间为同步提交模式,设置REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT为1,可以正常保存。

SQLserver AlwaysOn 提交模式与节点的可用性

ALTER AVAILABILITY GROUP [ag1] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

此时AG节点正常同步数据,如果目前再次关闭SQL2节点,会发生什么?

同样地,SQL1上的写操作会等待SQL2响应(SQL1上的读操作不受影响),此时SQL2已经宕机,然后等待超时(session timeout)之后会发生什么?

SQLserver AlwaysOn 提交模式与节点的可用性

可以看到此时SQL1上并没有像第二个case的“自动退化”为异步模式,而是给出了一个插入失败的错误提示

SQLserver AlwaysOn 提交模式与节点的可用性

Remote harden of transaction 'INSERT' (ID 0x000000000000ddc6 0000:000003c4) started at Dec 18 2023  9:34PM in database 'DB01' at LSN (37:2080:3) failed.

(1 row affected)
Msg 596, Level 21, State 1, Line 35
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 35
A severe error occurred on the current command.  The results, if any, should be discarded.

此时再尝试访问DB01会给出一个如下错误提示:

SQLserver AlwaysOn 提交模式与节点的可用性

Msg 988, Level 14, State 1, Line 34
Unable to access database 'DB01' because it lacks a quorum of nodes for high availability. Try the operation again later.

也就是DB01连读操作都不允许了,参考这里:https://learn.microsoft.com/zh-cn/sql/linux/sql-server-linux-availability-group-ha?view=sql-server-ver15

如果是两个节点的同步副本&REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT为1 ,在次要副本中断的恢复之前,主要副本拒绝所有连接。

SQLserver AlwaysOn 提交模式与节点的可用性

以下是其他情况下主副本的可用性情况

SQLserver AlwaysOn 提交模式与节点的可用性

 

SQLserver AlwaysOn 提交模式与节点的可用性

可见,AlwaysOn节点之间,如果在忽略REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT参数的情况下,因为主副本存在一个退化为异步的情况,

不管是同步或者异步模式,实际上都是不完全“安全”的。只有在要求强一致(两个或者多个节点同步提交)且设置REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT大于1的时候,主节点才能完全安全模式。文章来源地址https://www.toymoban.com/news/detail-760205.html

 

到了这里,关于SQLserver AlwaysOn 提交模式与节点的可用性的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 服务可用性设计

    一、统计指标 根据普罗米修斯Prometheus中的up指标,按照分钟记录服务不可用的记录数 up指标:up{application=“agr-ecos.admin”,instance=“30.79.8.41:43950”,job=“agr-ecos”} 当实例下线时为0,实例上线时为1 1、判断服务不可用逻辑 服务在某个分钟里,所有实例的up指标全为0,如果满足条

    2024年02月07日
    浏览(38)
  • 什么是可用性测试?

    可用性测试(Usability Testing)是一种软件测试方法,旨在评估一个产品(如软件、网站、移动应用等)的易用性和用户体验。该测试方法通过让真实的用户执行特定任务,观察和记录他们的行为、反应和满意度,来评估产品的可用性和用户友好程度。 可用性测试的主要目标是

    2024年02月11日
    浏览(48)
  • Elasticsearch的高可用性与容错

    Elasticsearch是一个分布式、实时的搜索和分析引擎,它可以处理大量数据并提供快速、准确的搜索结果。在现实应用中,Elasticsearch的高可用性和容错性是非常重要的,因为它可以确保系统的稳定运行和数据的安全性。 在本文中,我们将深入探讨Elasticsearch的高可用性与容错,包

    2024年02月21日
    浏览(41)
  • 软件的可用性改善:善用帮助信息

    当我们吭哧吭哧的开发功能性模块的时候,也需要回头思考一下软件的可用性。今天的主题就是使用帮助信息来改善软件的可用性,让软件不仅”能用”,也更”好用”。 帮助信息,也叫工具提示(Tooltip)。当用户的鼠标悬停在一段文字或者控件上时,会自动显示相关的帮助信

    2024年02月10日
    浏览(43)
  • selenium代理ip可用性测试

    测试代理ip是否工作正常,将正常的代理ip提取出来 测试结果

    2024年01月20日
    浏览(50)
  • 14.RocketMQ之高可用性机制

    RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。 Master和Slave的区别:在Broker的配置文件中,参数 brokerId的值为0表明这个Broker是Master,大于0表明这个Broker是 Slave,同时brokerRole参数也会说明这个Broker是Master还是Slave。 Master角色的Broker支持读和写,Slave角色的Broker仅支

    2024年02月11日
    浏览(46)
  • 聊一聊医疗器械的可用性

    很抱歉由于各种因素这个号拖更了好久了,最近呢也有几个公众号做的挺好的,比如包总的 MD SRE 、丁总的 医械安全 、 饽饽糕的叨逼叨 ,而且更新也都比较频繁,大家可以 关注 一下; 好久没登录,当我上来看到已经有 5000多 的关注者,说实话,有 感动 ,有 自豪 ,也有

    2024年02月07日
    浏览(47)
  • 让Zookeeper更高效:高可用性扩展策略

    作者:禅与计算机程序设计艺术 引言 1.1. 背景介绍 随着分布式系统的广泛应用,Zookeeper作为一致性系统的核心组件,在分布式系统中发挥着越来越重要的作用。Zookeeper作为一个分布式协调服务,负责协调分布式系统中的各个组件,保证系统的一致性和可用性。 1.2. 文章目的

    2024年02月14日
    浏览(35)
  • 兼容性测试如何提高网站的可用性?

    兼容性测试如何提高网站的可用性? 在现代社会,网站已经成为了人们获取信息、进行交流的主要渠道之一。但是,在网站的设计和开发中,往往会存在兼容性问题,导致不同浏览器或设备的用户无法顺利地访问和使用网站,降低了网站的可用性。因此,进行兼容性测试是提

    2024年02月09日
    浏览(66)
  • Kafka 高可用性集群部署实践 锤子技术

    作者:禅与计算机程序设计艺术 随着互联网应用场景的不断扩张、人们对实时数据处理需求越来越强烈,消息队列(MQ)系统也在逐渐发展壮大。Kafka 是 Apache 开源的分布式消息系统,它是一个分布式、高吞吐量、可扩展且高容错的平台。相对于其他 MQ 系统而言,Kafka 有以下

    2024年02月08日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包