SQL SERVER Alwayson 原理及故障排除

时间:2024-04-06 16:07:42

SQL SERVER Alwayson 原理及故障排除

SQL SERVER Alwayson 是SQL SERVER 分布式数据库的一种形式,使用的公司可能不是很多,对于快速开发和高可用,是一种很不错的解决方法。但在使用中,也会有TROUBLE的问题,我们今天来聊聊SQL SERVER 的ALWAYS ON 的原理以及一些故障,希望对大家有帮助。

SQL SERVER 的Always on 是基于PAXOS 协议的,其实说到底WINDOWS  Failover Cluster 也应该是基于 PAXOS (如果有不对,希望 WINDOWER 们来指正我哈)

SQL SERVER Alwayson 原理及故障排除

这张图就是一个SQL SERVER ALWAYS ON  2016 -2017 的架构图,SQL SERVER 2017 支持 1个主 8个从节点的架构,不过一般来说都是1个主 两个从的使用方式是一个主流。那SQL SERVER 的 ALWAYS ON  和 MYSQL的  MGR 有什么不同

1 MYSQL 的MGR 支持 多主的模式, SQL SERVER 不支持

2 SQL SERVER 的AWO 支持 同步和异步模式  MYSQL 的  MGR 你可以视为是强一致的同步模式。

3 SQL SERVER 和 MYSQL 都是通过日志的方式来进行复制的。

4  MYSQL 的 MGR 是使用整体数据库复制的方式 ORACLEER们可以理解,而 SQL SERVER 的集群,不是基于 INSTANCE 而是基于数据库的(不是ORACLE 理解的数据库,ORACLE的ER 们可以理解为一组 SCHEMA,用户拥有的表),从这点看 SQL SERVER 还是比较灵活的和友好的。

那下面还是的在深入的说一下 ALWAYS ON的原理

SQL SERVER Alwayson 原理及故障排除

上面的图很好的诠释了ALWAYS ON 的整个信息的同步流程

1 SQL SERVER 将 LDF 日志刷入磁盘,并且此时LDF 的日志必须要复制到从节点发送和主库的日志写入的顺序是一致的。(这是不是想起MYSQL的 BINLOG,但不是很一样,为什么自己想,上面写了哦,想不起来,文章结尾会写)

2 日志会复制到对应的从库的日志队列,然后捕捉的线程会一直运行,将传送过来的数据进行数据的同步,如果由于某些原因,复制出现问题,那LOG SEND队列就建立起来了。

3 信息在每个数据库中的复制队列被拿出然后通过网络传输到从库中

4 从库接受并且将数据快速 cache 起来

5 LOG 被物理的FLUSH 到从库的LDF 文件中,并且会给 主库一个 ACK(这让我想起MYSQL 的半同步)

6 启动REDO 线程,将数据刷入到 MDF NDF 文件中。

看上去很简单,但实际的工作绝对不比MYSQL的 BINLOG  复制简单。

另外在主,从副本中是要有流量控制的,以一个数据包来说 包含了 8192个 MESSAGES ,同时对于数据库等级也是有控制的,一个数据库最大一次传输  11200 MESSAGES ,(以那个为准,这个问题估计你不是SQL SERVER  DBAER,文章结尾也会提到) ,这个两个标准以先到先得的标准,在对方不应答的情况下,传送LOG的服务会等到对方应答,接受到这么多的日志后,传送方会继续传送。同时还有一个隐藏的发送标准就是LSN号,主从库的差异,当然通过 last commit的时间也是可以判断主从节点之间的同步状态是怎样的。具体请参考 SQL SERVER DMV 的 hard_database_replica_states

同时由于ALWAYSON 的 FAILOVER 功能,在进行FAILOVER 也是要评判当前的切换的主机是否和从库的 LSN 吻合,这样就演化出判断AWO的性能的两个参数  RTO 和 RPO 两个参数通过这两个参数可以判断出AWO如果目前遇到主机故障,是否可以快速切换。让我想起 MYSQL的 MHA的功能以及其存在的意义。这里不再做详细的解释,感兴趣 GOOGLE 就可以,一堆解释和脚本。

一般ALWAYSON 的故障常见的故障或问题,

 数据延迟,这是一种,(AWO 有两种,异步和同步),这里即使你使用了同步的方式进行复制,那其实主库和从库还是有时间差异的(尤其在I/O 和网络性能不好的情况下)

在SQL SERVER 里面这样的问题叫 HIGH HADR_SYNC_COMMIT 

那引起这个问题是哪几部可能存在这样的问题,

事务在主节点初始化

主复制不作transaction logs 并且发送到 secondary 复制

从库复制接受并且硬化日志并发送给从库

下面的图中,就是有可能产生性能问题的地方,但用大白话来说

1  大事务

2  糟糕的网络

3  糟糕的I/0

SQL SERVER Alwayson 原理及故障排除

同时通过SQL SERVER 性能监控器的 DATABASE REPLICA 中的 事务延迟和 事务镜像同步 都可以看出延迟了多长时间。

所以打破一个概念就是 SQL SERVER  AWO 同步复制,主从数据就一定百分百时间一致,NO NO NO 我查看了 目前的生产库, MYSQLER们可以理解为 behind master 当然 SQL SERVER 高大上,时间都显示了,差多少都心里有数。 

SQL SERVER Alwayson 原理及故障排除

好了回答上面的, 有人不知道的问题

MYSQL 5.6 的复制 和 MYSQL 5.7 的复制有什么不同,不知道这里就不提了,这里拿MYSQL 5.6 多线程复制 对比 SQL SERVER AWO 复制,可以类比,因为都是一个库一个线程(SQL SERVER AWO 看上去也是),MYSQL 5.7 以后 到  8.0  可都是要 多线程复制,并且GR 的复制方式,这里就慢慢和 AWO 不能进行类比了。另外SQL SERVER 的复制是按照数据库日志,而MYSQL 的复制是按照 BINLOG (FILTER database replication  那也是过滤和SQL SERVER 的复制还是不一样,所以这点是不能类比的。

SQL SERVER Alwayson 原理及故障排除

顺便给SQL SERVER  打个广告 SQL SERVER 2019 直接整合 SPARK ,做大数据库的 可以关注一下,虽然不见得有多好,但至少多一个选择,短平快,数据量一般的还是可能享受到一波 ”宏利“

SQL SERVER Alwayson 原理及故障排除