SQL SERVER Alwayson原理及如何进行故障排除

本篇文章给大家分享的是有关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 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的原理

上面的图很好的诠释了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 性能监控器的 DATABASE REPLICA 中的 事务延迟和 事务镜像同步 都可以看出延迟了多长时间。

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

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

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

以上就是SQL SERVER  Alwayson原理及如何进行故障排除，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。