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原理及如何進行故障排除，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。