SQL SERVER Alwayson原理及如何進(jìn)行故障排除

本篇文章給大家分享的是有關(guān)SQL SERVER  Alwayson原理及如何進(jìn)行故障排除，小編覺得挺實用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

SQL SERVER Alwayson 是SQL SERVER 分布式數(shù)據(jù)庫的一種形式，使用的公司可能不是很多，對于快速開發(fā)和高可用，是一種很不錯的解決方法。但在使用中，也會有TROUBLE的問題，我們今天來聊聊SQL SERVER 的ALWAYS ON 的原理以及一些故障，希望對大家有幫助。

SQL SERVER 的Always on 是基于PAXOS 協(xié)議的，其實說到底WINDOWS  Failover Cluster 也應(yīng)該是基于 PAXOS （如果有不對，希望 WINDOWER 們來指正我哈）

這張圖就是一個SQL SERVER ALWAYS ON  2016 -2017 的架構(gòu)圖，SQL SERVER 2017 支持 1個主 8個從節(jié)點的架構(gòu)，不過一般來說都是1個主 兩個從的使用方式是一個主流。那SQL SERVER 的 ALWAYS ON  和 MYSQL的  MGR 有什么不同

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

2 SQL SERVER 的AWO 支持 同步和異步模式  MYSQL 的  MGR 你可以視為是強(qiáng)一致的同步模式。

3 SQL SERVER 和 MYSQL 都是通過日志的方式來進(jìn)行復(fù)制的。

4  MYSQL 的 MGR 是使用整體數(shù)據(jù)庫復(fù)制的方式 ORACLEER們可以理解，而 SQL SERVER 的集群，不是基于 INSTANCE 而是基于數(shù)據(jù)庫的（不是ORACLE 理解的數(shù)據(jù)庫，ORACLE的ER 們可以理解為一組 SCHEMA，用戶擁有的表），從這點看 SQL SERVER 還是比較靈活的和友好的。

那下面還是的在深入的說一下 ALWAYS ON的原理

上面的圖很好的詮釋了ALWAYS ON 的整個信息的同步流程

1 SQL SERVER 將 LDF 日志刷入磁盤，并且此時LDF 的日志必須要復(fù)制到從節(jié)點發(fā)送和主庫的日志寫入的順序是一致的。（這是不是想起MYSQL的 BINLOG，但不是很一樣，為什么自己想，上面寫了哦，想不起來，文章結(jié)尾會寫）

2 日志會復(fù)制到對應(yīng)的從庫的日志隊列，然后捕捉的線程會一直運行，將傳送過來的數(shù)據(jù)進(jìn)行數(shù)據(jù)的同步，如果由于某些原因，復(fù)制出現(xiàn)問題，那LOG SEND隊列就建立起來了。

3 信息在每個數(shù)據(jù)庫中的復(fù)制隊列被拿出然后通過網(wǎng)絡(luò)傳輸?shù)綇膸熘?/p>

4 從庫接受并且將數(shù)據(jù)快速 cache 起來

5 LOG 被物理的FLUSH 到從庫的LDF 文件中，并且會給 主庫一個 ACK（這讓我想起MYSQL 的半同步）

6 啟動REDO 線程，將數(shù)據(jù)刷入到 MDF NDF 文件中。

看上去很簡單，但實際的工作絕對不比MYSQL的 BINLOG  復(fù)制簡單。

另外在主，從副本中是要有流量控制的，以一個數(shù)據(jù)包來說 包含了 8192個 MESSAGES ，同時對于數(shù)據(jù)庫等級也是有控制的，一個數(shù)據(jù)庫最大一次傳輸  11200 MESSAGES ，（以那個為準(zhǔn)，這個問題估計你不是SQL SERVER  DBAER，文章結(jié)尾也會提到） ，這個兩個標(biāo)準(zhǔn)以先到先得的標(biāo)準(zhǔn)，在對方不應(yīng)答的情況下，傳送LOG的服務(wù)會等到對方應(yīng)答，接受到這么多的日志后，傳送方會繼續(xù)傳送。同時還有一個隱藏的發(fā)送標(biāo)準(zhǔn)就是LSN號，主從庫的差異，當(dāng)然通過 last commit的時間也是可以判斷主從節(jié)點之間的同步狀態(tài)是怎樣的。具體請參考 SQL SERVER DMV 的 hard_database_replica_states

同時由于ALWAYSON 的 FAILOVER 功能，在進(jìn)行FAILOVER 也是要評判當(dāng)前的切換的主機(jī)是否和從庫的 LSN 吻合，這樣就演化出判斷AWO的性能的兩個參數(shù)  RTO 和 RPO 兩個參數(shù)通過這兩個參數(shù)可以判斷出AWO如果目前遇到主機(jī)故障，是否可以快速切換。讓我想起 MYSQL的 MHA的功能以及其存在的意義。這里不再做詳細(xì)的解釋，感興趣 GOOGLE 就可以，一堆解釋和腳本。

一般ALWAYSON 的故障常見的故障或問題，

 數(shù)據(jù)延遲，這是一種，（AWO 有兩種，異步和同步），這里即使你使用了同步的方式進(jìn)行復(fù)制，那其實主庫和從庫還是有時間差異的（尤其在I/O 和網(wǎng)絡(luò)性能不好的情況下）

在SQL SERVER 里面這樣的問題叫 HIGH HADR_SYNC_COMMIT 

那引起這個問題是哪幾部可能存在這樣的問題，

事務(wù)在主節(jié)點初始化

主復(fù)制不作transaction logs 并且發(fā)送到 secondary 復(fù)制

從庫復(fù)制接受并且硬化日志并發(fā)送給從庫

下面的圖中，就是有可能產(chǎn)生性能問題的地方，但用大白話來說

1  大事務(wù)

2  糟糕的網(wǎng)絡(luò)

3  糟糕的I/0

同時通過SQL SERVER 性能監(jiān)控器的 DATABASE REPLICA 中的 事務(wù)延遲和 事務(wù)鏡像同步 都可以看出延遲了多長時間。

所以打破一個概念就是 SQL SERVER  AWO 同步復(fù)制，主從數(shù)據(jù)就一定百分百時間一致，NO NO NO 我查看了 目前的生產(chǎn)庫， MYSQLER們可以理解為 behind master 當(dāng)然 SQL SERVER 高大上，時間都顯示了，差多少都心里有數(shù)。 

好了回答上面的， 有人不知道的問題

MYSQL 5.6 的復(fù)制 和 MYSQL 5.7 的復(fù)制有什么不同，不知道這里就不提了，這里拿MYSQL 5.6 多線程復(fù)制 對比 SQL SERVER AWO 復(fù)制，可以類比，因為都是一個庫一個線程（SQL SERVER AWO 看上去也是），MYSQL 5.7 以后 到  8.0  可都是要 多線程復(fù)制，并且GR 的復(fù)制方式，這里就慢慢和 AWO 不能進(jìn)行類比了。另外SQL SERVER 的復(fù)制是按照數(shù)據(jù)庫日志，而MYSQL 的復(fù)制是按照 BINLOG (FILTER database replication  那也是過濾和SQL SERVER 的復(fù)制還是不一樣，所以這點是不能類比的。

順便給SQL SERVER  打個廣告 SQL SERVER 2019 直接整合 SPARK ，做大數(shù)據(jù)庫的 可以關(guān)注一下，雖然不見得有多好，但至少多一個選擇，短平快，數(shù)據(jù)量一般的還是可能享受到一波 ”宏利“

以上就是SQL SERVER  Alwayson原理及如何進(jìn)行故障排除，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學(xué)到更多知識。更多詳情敬請關(guān)注億速云行業(yè)資訊頻道。