SQL Server 的“高可用性”與“災難恢復” 之二 故障轉移群集
SQL Server使用最廣的高可用性技術叫做故障轉移群集（SQLServer Failover Cluster）。這是一項基於Windows故障轉移群集的一種技術。SQLServer故障轉移群集技術集成了微軟技術一貫簡單易用的特點，在部署和管理上都非常容易，同時又能提供非常良好高可用性，因此目前得到了非常廣泛的使用。可以說，它是SQL2012之前的各個版本，實現高可用性的必選技術。
故障轉移群集
要了解SQL Server故障轉移群集，首先要對Windows故障轉移群集有一個基本的瞭解。下面介紹的內容不求面面俱到地都覆蓋Windows群集的知識，但對於一個資料庫系統管理員，理解這些概念是非常有用的。
1. Windows故障轉移群集的基本組成要素
Windows故障轉移群集是由多個伺服器組成的。每個伺服器也被稱為“節點”(Node)，每個節點上都執行著Microsoft 群集服務 （MSCS）。這些節點有相同的軟硬體配置，並且具有共享的磁碟（Shared Array）。所有需要在幾個節點之間共享的東西，例如SQLServer的資料庫檔案、錯誤日誌等，都會被安放在共享磁碟上。不需要共享的內容則被安放在每個節點的本地磁碟上。
除了共享磁碟之外，組成群集的多個節點之間通過“私有網路”（privatenetwork）和“公共網路”（public network）連線起來。每個節點上有一塊私有網絡卡，這些網絡卡通過網路互相連線組成了私有網路。節點之間通過私有網路互相傳送訊號來感知彼此是否已經工作正常，這類訊號被稱為“心跳線”。一旦某伺服器因為某種異常而無法迴應訊號，這就好像一個人的心跳停止了一樣。此時剩餘的節點就認為這個節點已經“死了”，於是就把這個節點排除出當前群集。
公用網路，顧名思義是用來被群集外部的資源所使用的一個網路。每個節點上有一塊公共網絡卡，外部資源通過公用網絡卡來訪問這個節點。要注意的是，私有網絡卡和公共網絡卡在物理上可以是一塊網絡卡，這種時候群集就通過一個網路來完成私有網路和公共網路的職責，這個網路被稱其為混合網路（mixednetwork）。
一個群集內的所有節點共同組成一個“虛擬”的伺服器(VirtualServer)。也就是說，從這個群集的外部來看，只能看到一個伺服器，而不是它背後的一堆節點伺服器。虛擬伺服器具有自己的機器名和IP地址，而這個名稱和IP與群集內的任何節點都不同。由於伺服器是虛擬的，因此人們稱呼它的IP是“虛擬IP”，而它的機器名是“虛擬網路名”（virtualnetwork name）。但事實上“虛擬IP”和“虛擬網路名”都是在DNS伺服器上登記在冊的，它們本身和一臺真實的物理機器的IP和機器名沒有任何區別，只是它們對應的伺服器是一個虛擬的機器。虛擬IP一定要和公共網路配置在同一個網段裡，因為這個IP需要在網路上可以被其他機器訪問到。
在Windows群集中，虛擬IP，虛擬網路名，共享磁碟，SQL Server等等，被統稱為“資源”。在任意時刻，只有群集中的一個節點能提供使用者所需的服務和資源，而其他節點都處於空閒狀態。所以，Windows群集無法提供負載均衡的能力。這個技術和NLB是有本質區別的。
那麼當用戶使用虛擬IP或者虛擬網路名來訪問虛擬伺服器的時候，到底是哪個節點來為使用者提供服務呢？答案是，由“活躍節點”來提供服務。所謂的活躍節點，就是當前擁有該群集資源的節點。
舉個例子，假設當前有兩個節點，分別是NodeA和NodeB；它們組成的群集的虛擬網路名是Vserevr。在某個時刻，NodeA擁有了虛擬網路名和虛擬IP這兩個資源，而伺服器B擁有了一個共享磁碟資源DiskX。這種情況下，對虛擬網路名和IP而言，NodeA就是活躍節點，而對於共享磁碟DiskX而言，NodeB才是活躍節點。如果你使用遠端桌面工具去連線虛擬網路名Vserver，你實際上是登入到了NodeA上，你可以的本地磁碟上的檔案其實是NodeA磁碟中的檔案，你執行的程式都是NodeA上安裝的程式。虛擬網路名好像一箇中轉站一樣，所有該虛擬伺服器的請求都被轉向到了NodeA上。但是NodeA上看不到共享磁碟。因為共享磁碟資源當前被NodeB所擁有。您只有直接登入到NodeB上才能看到那個共享磁碟。
誰是“活躍節點”是Windows群集服務決定的，對使用者完全透明。使用者不需要關心當前哪個節點正在執行。客戶端的連線指令始終都是一樣的：指向虛擬IP，或者虛擬網路名。例如使用者要通過UNC方式訪問共享磁碟上的某個檔案，他所發出的指令會是\\Vsever\DiskX\FolderY\。
2. 故障轉移
接下來再來談談群集的“故障轉移”（Failover，也稱為“切換”）。也就是說，當“活躍節點”伺服器出問題的時候，群集服務是怎麼實現其“高可用性”的。
還是前面的這個例子，假設此時NodeA擁有DiskX，虛擬網路名和虛擬IP地址三個資源。如果NodeA突然間由於硬體故障藍屏了，那麼Windows群集會立刻探知到這個問題，然後自動發起一個故障轉移。轉移完成後，這三個資源全部在NodeB上線，也就是被NodeB所擁有。如果之前有一個使用者通過\\Vsever\DiskX\FolderY\這樣的UNC方式來訪問共享磁碟上的某個檔案，NodeA的藍屏對該使用者不會造成任何的影響。使用者甚至可能沒感覺到虛擬伺服器內部的故障轉移。對他而言通過Vserver裡的那個檔案一直都是可以訪問，而這就是高可用性的目的。
除了由於系統故障所造成的Windows群集的自動切換，系統管理員也可以通過工具或者命令列手動發起切換。
故障轉移群集
所謂的SQL Server故障轉移群集，就是將SQLServer部署在Windows群集中的多個節點上，然後組成一個虛擬的SQLServer例項。這樣SQL Server 例項依舊像執行在單臺計算機一樣顯示在網路中。不過它具有一種功能，即在當前執行SQLServer例項的節點不可用時，可以在節點之間進行故障轉移，把SQL Server切換到工作正常的節點上去繼續為應用程式提供服務。
實現這個功能，需要將SQL Server安裝成群集模式，而不是單機模式。安裝的具體步驟，請參見本書的第一章。安裝成功以後，您就可以看到本節所提到的各個管理介面了。
開啟Windows的故障轉移群集管理器（FailoverCluster Manager），然後使用Windows群集的虛擬網路名來連線群集。左側的面板中的“Servicesand application”節點，下面會列出該Windows群集的所有“資源組”。“資源組”顧名思義就是由一個或者多個資源組成的組。所有的故障轉移都是以資源組為單位發生的，在任何時候，每個資源組都僅屬於群集中的一個節點，這個節點就是該資源組的“活躍節點”。由於資源組裡的資源是一起切換的，所以這些資源應該是彼此關聯，並且協同工作來提供某項服務。使用者應當儘量避免把無關的資源加入到同一個資源組裡。可以簡單地把資源組想象成在虛擬伺服器上執行的一個個獨立的應用程式或者服務，而群集技術為這些應用程式或者服務提供了高可用的特性。SQLServer資源組就是一個很好的例子。
SQL Server群集資源組的結構
1. SQLServer網路名和SQL Server IP地址：
SQL Server群集並不使用Windows群集的虛擬網路名和虛擬IP地址來作為應用程式訪問它的介面。在SQLServer的資源組裡有該SQL Server例項自己專用的虛擬網路名和IP地址這兩個資源，它們提供了應用程式訪問SQL Server時使用的機器名或者IP地址。事實上，無論是Windows群集還是SQL Server群集的虛擬機器器名/IP，它們的資源型別都是相同的，只是它們一個服務於Windows虛擬伺服器；一個服務於SQL Server群集例項。
2. SQL Server和SQLServer Agent
這兩個資源是SQL Server故障轉移群集的關鍵資源。它們分別代表了SQL Server服務和SQLServer Agent服務。事實上，SQL Server 2005群集還包含有第三種資源：SQL Server Fulltext Search。但是這個資源在SQL Server 2008以後被併入了SQL Server資源裡，因此就只剩下現在這2個資源了。
對於一個SQL Server群集，群集中的所有節點上都會有安裝有SQL Server和SQLServer Agent服務以及與服務所對應的二進位制檔案、登錄檔鍵值等。Node1是SQL Server的“活躍節點”。如果你到群集中的每個節點上的SQLServer Configuration Manager裡檢視的話，會發現只有Node1上的SQL Server例項對應的服務是處於啟動狀態，其餘所有節點上服務都是處於停止狀態的。
如果SQL Server是預設例項的話，那麼SQL Server資源的名字就是“SQLServer”。如果SQL Server是命名例項的話，SQLServer資源名就是“SQL Server (例項名)”。客戶端應用程式就是通過“虛擬網路名\例項名”的形式找到它所想要訪問的SQLServer例項。
3. 共享磁碟
共享磁碟資源可以是一塊邏輯磁碟，也可以是一塊磁碟上的一個mountpoint。
對於一個SQL Server群集例項，資料庫的所有資料檔案和事務日誌檔案（MDF，NDF和LDF），SQL Server和SQLServer Agent的日誌檔案（ERRORLOG），以及一些其他的檔案和目錄，都是儲存在共享磁碟上的。必須設定共享磁碟和SQLServer資源在一個資源組裡，這樣就保證了執行SQL Server服務的節點一定能訪問到共享磁盤裡的資料。
事實上SQL Server資源和共享磁碟資源是具有“依賴”關係的。也就是說在磁碟資源無法在某節點正常執行的時候，SQL Server資源在該節點也無法上線執行。
需要注意的是，一個共享磁碟資源只能屬於一個SQLServer例項（事實上，在安裝SQL Server群集例項時是不允許把SQLServer安裝在一個已經被其他SQL Server群集例項使用的共享磁碟上的）。但是一個SQLServer群集例項可以使用多個共享磁碟。
4. 其他
除了上述列出的資源之外，SQLServer資源組裡還可能包含
(1) FileShare：如果 SQL Server要使用FileStream，就需要這樣一個資源
(2) AnalysisServices：這個資源和SQL Server/SQL Server Agent資源不同，是屬於Generic Service資源。
一般而言，每個資源可能處於的狀態有：
上線（online）：該資源在某個節點上正常工作中。
離線（offline）：該資源在某個節點上處於停止工作狀態，無法提供相應的服務。
失敗（failed）：該資源在某節點嘗試上線，但是由於某些異常無法上線成功。
上線掛起（onlinepending）：資源嘗試進入上線狀態，但是還沒完全成功上線。
離線掛起（offlinepending）：資源嘗試進入離線狀態，但是還沒完全成功離線。
以上五個狀態中，上線/離線/失敗是會長時間保持的狀態；除非有人為的操作或者系統異常發生，否則他們會保持這個狀態。而兩個“掛起”的狀態不會長時間保持。經過一段時間之後，它們要麼成功“上線”，要麼由於某種錯誤或者由於超時最後進入了“失敗”狀態。
2. 叢集資源的配置
在任意一個資源上點右鍵，選擇“屬性”，在彈出視窗上能看到一系列選項卡，這裡包含了群集資源的重要設定選項。
這裡以SQL Server資源為例。首先來看“Dependencies”選項卡。
SQL Server資源的Dependencies屬性頁
這裡顯示了SQL Server依賴了哪些資源。SQLServer要依賴的資源包括：
· 虛擬網路名資源
· 共享磁碟資源
這兩個資源之前的關係是“and”，就是說只有兩個資源都online之後，SQL Server資源才可以online。這也符合SQL Server成功啟動的要求：（1）能繫結IP地址，（2）能找到系統資料庫和錯誤日誌。
如果去看虛擬網路名的依賴“選項”卡，你會發覺它其實是依賴於虛擬IP資源。這樣就組成了一個完整的依賴“鏈條”。SQL Server資源組裡各個資源的依賴關係如下：
SQL Server資源組中屬性的依賴關係
一個資源所依賴的其他資源必須要和這個資源處於同一個資源組裡，跨資源組的依賴關係是不存在的。如果使用者需要SQLServer群集例項同時可以訪問多個共享磁碟資源，必須在SQL Server資源組裡新增，然後讓SQLServer資源去依賴於它們。沒有這樣的依賴關係，SQL Server群集例項將無法看到或者使用這些磁碟。
再來看“Policies”選項卡。
SQL Server資源的Policies屬性頁
這個選項卡里的選項決定了該資源發生故障轉移時的行為。下面介紹一些推薦的設定:
1) 對於SQL Server資源組裡的以下型別的資源：
· SQL Server資源
· 共享磁碟資源
· 虛擬IP地址資源
· 虛擬服務名資源
都建議在策略選項卡里保留其預設設定。即確保If resource fails, attempt restart on currentnode 被選中並選擇Ifrestart is unsuccessful, fail over all resources in this service or application。這樣的設定下，上面的資源如果因為軟體或硬體故障進入失敗狀態，會在15分鐘內嘗試在當前節點重啟（一般就是立刻嘗試重啟，不需要等15分鐘那麼長），第一次嘗試重啟失敗的話，就會將整個資源組故障轉移到另外的節點上。這樣的設定被稱為“affectthe group”。
2) 出於最大化高可用的目的，對以下資源：
· SQL Server Agent資源
· File Share資源
· Analysis Services資源
建議設定為選擇 If resource fails, attempt restart on current node選項，並且不選擇If restart is unsuccessful, failover all resources in this service or application 選項。這樣設定下，上述資源如果由於軟硬體異常進入失敗狀態，並不會導致整個資源組的切換，這些資源不會“affectthe group”。對於這些不是非常關鍵的資源，通常都建議配置成不“affect the group”，這樣可以消除那些不必要的故障切換髮生，提高資料庫伺服器的線上時間。千萬不要把那些和SQL Server例項無關的資源加入到SQL Server資源組來，並且把它們配置為“affectthe group”，因為這樣會大大提升SQL Server資源組發生無謂切換的風險。
最後，來看一下“Advanced Policies”選項卡。
SQL Server資源的Advanced Policies屬性頁
該選項卡中的“possible owners”部分會列出該資源可以切換到哪些節點上執行。SQLServer資源可以在Node1或者Node2上（這說明，在安裝SQL Server群集的時候，SQL Server被部署到了這兩個節點上）。如果任意節點前沒有打鉤的話，就意味著資源不能在這個節點上上線執行。
在這個選項卡里還有兩個重要的選項。一個是“Basic resourcehealth check interval”，另外一個是“Thorough resource healthcheck interval”。Windows Cluster為了每個資源是否工作正常，會使用不同的時間間隔來做的兩種不同程度的檢查。我們通常把Basicresource health check俗稱為“looks alive check”，而把Thorough resource health check稱為“isalive check”。我們會在下面一小節裡詳細介紹這兩種檢查。
群集什麼時候會發生“故障轉移”
SQL Server故障轉移群集是如何檢測到系統故障，從而觸發故障轉移群集的呢？
前面說到過，Windows群集是通過做“looksalive check”和“is alive check”這兩種不同的檢查來判斷資源是否工作正常的。如果檢查失敗，則判定該資源出現異常，然後就按照該資源的“Policies”選項卡里中設定，來進行故障轉移。
群集裡的每個資源都是一種資源型別。比如，共享磁碟的資源型別是physicaldisk，虛擬IP的資源型別是IP address，SQL Server資源對應的資源型別名字就叫“SQL Server”。根據不同型別的資源，會使用不同的方式進行isalive和looksalive檢查。
資源型別、資源DLL和資源的關係
對於physical disk, IP, network name和DTC這類Windows群集自帶的資源型別，它們各自的isalive和lookalive方法都定義在一個Windows群集自帶的resource DLL “clusres.dll”中。對於那些非自帶的資源（比如說SQLServer），如果它們有自己專屬的資源型別並且有專屬resource dll，就可以在resource DLL中定義自己的isalive和looksalive檢查方法。有些資源沒有特定的資源型別，我們稱這類資源的資源型別為“通用服務”（Generic Service）。對於Generic Service型別的資源，Windows群集依舊使用clusres.dll來作為它們的resource dll。Clusres.dll裡有針對Generic Service的“標準”isalive和lookalive檢查方法。Windows群集服務程序clussvc.exe會產生名為RHS.exe的程序，RHS.exe會裝載resource dll，並且呼叫dll中定義的方法來檢查相應resource的狀態。一個資源其屬性的AdvancedPolices選項卡中如果沒有勾選“run this resource in a separateResource ”，它的resource dll就會裝載在一個預設的RHS.exe中；反之，則會有一個單獨的RHS.exe來裝載該資源的resourcedll。所以在工作管理員中你可能看到多個RHS.exe程序。
在安裝SQL Server的時候，會安裝兩個SQLServer自己的resource dll ：sqsrvres.dll和sqagtres.dll，它們分別服務於SQLServer資源和SQL Server Agent資源。一般只會把SQLServer資源配置成affect the group模式，因此要了解SQLServer群集什麼情況下會故障轉移，就要了解sqsrvres.dll是怎麼定義looksalive和isalive方法的。事實上，從SQL Server 2000到SQL Server 2008 R2，sqsrvres.dll中定義的looksalive和isalive方法都是類似的。具體來講：
Looksalive：通過服務控制管理器（Service ControlManager，簡稱SCM）來檢查SQL Server服務在活躍節點是否處於“啟動狀態”。根據SQLServer資源的Advanced Polices選項卡中的設定，這個檢查預設是每5秒鐘做一次。
Isalive：根據SQL Server資源的Advanced Polices選項卡中的設定，這個檢查預設是每60秒鐘做一次，也就是說每12次Looksalive檢查就會伴隨一個Isalive檢查。SQL Server需要Isalive檢查，是因為即使SQL Server服務是正在執行狀態，也不能說明SQLServer就可以良好地響應應用程式的請求。有的時候可能整個SQL Server已經掛起了，但是服務的狀態還是“啟動”。所以需要Isalivecheck來進一步檢查SQL Server的狀態。此外，一旦lookalive檢查的結果失敗，Windows群集服務就會立刻觸發Isalive檢查。
在SQL 2012之前，Isalive所做的事情很簡單，Windows群集服務會使用TCP/IP或者Named Pipes來連線SQL Server群集例項。連線上之後，執行一句命令“select @@servername”。如果該語句成功返回結果，那麼Isalive檢查就成功了。
如果連線不上SQL Server群集例項或者語句執行失敗，那麼Isalive檢查失敗。此時Windows群集會再做3-5次（根據Windows的版本和設定不同）Isalive檢查。如果這些檢查都失敗了，就要根據Policies選項卡中的設定開始進行故障轉移。
您可以把故障轉移簡單地想象成SQL Server服務的重啟，所不同的是故障轉移的時候，SQL Server服務是在當前節點停止，然後在另一個節點上啟動起來。因此故障轉移所花費的時間和SQLServer服務重啟的時間是差不多的。當然共享磁碟和虛擬網路名等資源在另一個節點上線也會額外花費一點時間，不過在大多數情況下這部分時間是比較短的。另外，由於故障轉移一般是意外發生的，所以您要預期SQLServer切換到新節點以後，還需要一段時間來做資料庫的recovery。
前面也提到過，除了SQL Server和SQLServer Agent以外，SQL Server資源組裡可能還會有AnalysisService資源。但是和SQL Server/SQL Server Agent不同的是，Analysis Service資源沒有自己的資源型別，也就是說它是一個GenericService（通用服務）。Analysis Service的isalive和looksalive檢查就使用的是clusres.dll中定義的通用服務檢查方法。
SQL Server的諸多服務和元件中，SQL Server、SQL Server Agent以及Analysis Service這三個服務，無論是有自己專屬的資源型別還是通用服務，都是被設計為可以通過resource dll形成群集資源。這種型別的服務被稱為cluster-aware。SQLServer還有很多其他資源，比如SQL browser, Reporting Service等，它們被設計成無法通過任何resource dll在Windows群集中形成資源，所以它們不是cluster-aware的。對於不是cluster-aware的服務，即使被安裝在了群集的節點上，Windows依舊把它當成是安裝在了一個單機環境中，它無法具有故障轉移的功能。
需要提一下的是Integration Services是一個比較特別的服務。Integration Services本身不是cluster-aware的服務，但是使用者可以通過一些步驟手動把它配置成一個群集資源。但是這樣配置出來的Integration Services群集資源不是一個真正的資源，是不具有自動故障轉移功能的，因此微軟並不推薦這麼做。更多的資訊可以參考下面兩篇技術文章：
群集的拓撲結構
最簡單的SQL Server故障轉移群集拓撲結構就是“活躍/非活躍”群集。這種結構下群集有2個節點，使用者在群集上安裝一個SQL Server群集例項，該例項的“可能的所有者”（possibleowners）包含上述兩個節點。這樣任意時間只有一個節點上有SQL Server服務在執行，而另一個節點就是“非活躍”節點。這種配置的優點是結構簡單明瞭，無論SQL Server執行在哪個節點上都能獲得同樣的效能表現。缺點是總有一個節點處於空閒狀態，浪費了50%的硬體資源。
“活躍/非活躍”群集
另一種拓撲結構是“活躍/活躍”群集。還是以一個2節點的群集為例。這個時候使用者在群集上安裝兩個SQLServer群集例項，每個例項的“可能的所有者”都包含群集兩個節點。在正常情況下，兩個例項分別執行在不同的節點上。這樣兩個節點就都是“活躍”節點。
“活躍/活躍”群集
這種結構的優勢是兩個節點的硬體資源都能被充分利用，節約成本。缺點是，一旦某個節點發生故障轉移，就會發生另一個節點上同時運行了兩個SQLServer例項的情況。此時，這兩個例項可能會爭用這個節點上的CPU，記憶體，I/O等資源，導致兩個例項的效能都受到影響。有時候可能兩邊的使用者都不能接受。因此要儘快解決異常節點上的問題，儘早把發生故障轉移的例項切換回去。
在此基礎上，我們來介紹所謂的N+1結構，即N個活躍節點加上1個非活躍節點。以3個節點的群集為例，在上面安裝兩個SQL Server群集例項，每個例項的possibleowner包含群集中的兩個節點，但是隻有一個節點是兩個例項共有的。在正常情況下，兩個SQL Server都執行在非共有的那個節點上，互不干涉。一旦某個節點發生故障轉移，就會切換到那個共有的非活躍節點上。
N+1群集
這個結構是一個介於“活躍/非活躍”和“活躍/活躍”之間的一種方案。相對於“活躍/非活躍”，它浪費的節點資源比較少（1/N+1）。另外，兩個以上的節點同時發生故障轉移，需要同時切換到共有節點的概率是比較低的，因此也在一定程度上解決了“活躍/活躍”結構的效能問題。
無論什麼樣的拓撲結構，有兩點是不會變的：
1. SQL Server群集無法提供資料庫端的負載均衡功能。作為“活躍/活躍”群集，其實是幾個獨立的資料庫例項，它們彼此間沒有聯絡。再次強調，群集技術只是一個提供”高可用性”的技術，而不是提升效能的技術。
2. 無論群集有幾個節點，對於某個資料庫例項，它只有一份資料。一旦資料本身出現問題，群集對此無能為力。所以，群集技術不是一個提供資料“災難恢復”的技術。對重要的資料庫，僅僅使用群集技術是不夠的。
SQL Server 2012對故障轉移群集的改進
SQL Server 2012群集基本沿襲了SQL Server2008群集以來的一系列特點。不過它也帶來了一些新特性，使得群集具有了更加強大的功能以及更高的可用性。現在就讓我們來看看SQLServer 2012群集都有哪些新東西。
從Windows Server 2008開始，故障轉移群集開始支援所謂“多站點（multi-site）群集”。也就是說，組成一個群集的節點可以被安置在相隔很遠的不同的站點。此外，不同站點可以處於不同的子網，因此多子網（multi-subnet）群集也得以實現。在地理上相隔很遠的站點進行群集有時被稱為拉伸群集（Stretch Clustering）。
對於一個多子網的群集，需要為群集裡的每個站點都配置一個虛擬IP地址，而“虛擬網路名”資源會依賴所有這些IP地址資源。當群集執行在某個站點上時，只有對應該站點子網的虛擬IP地址資源可以處於上線狀態，其餘IP地址資源由於在該子網內無法被成功分配，因此都會處於“失敗”或“離線”狀態。從Windows Server 2008群集開始，使用者可以把虛擬網路名資源配置成以“OR”的關係來依賴這些IP地址資源。因此即使只有一個IP地址可以上線，“虛擬網路名”資源也可以成功上線。可以說是，WindowsServer 2008群集對OR依賴關係的支援，是實現多站點和多子網群集的一個關鍵。
可是，雖然Windows Server 2008群集支援多子網，SQL Server 2008和SQL Server2008 R2群集卻並不支援多子網。這是因為SQL Server 2008本身不支援OR的依賴關係。從SQL Server 2012開始，相應部分遺留的程式碼得到了重寫，因此SQLServer支援多子網群集的障礙也得到了掃除。目前，只有執行在Windows Server 2008 R2群集上的SQL Server 2012群集才完全支援了多子網的功能。
在SQL Server 2012中，如果SQLServer發現“虛擬網路名”資源所依賴的某個IP地址不能上線，就會在SQLServer的錯誤日誌中記錄以下資訊：
SQL Server could not listen on IP address [156.69.72.165]because the cluster resource ‘SQL IP Address 2 <inst>’ is not online(state=3). This is an informational message and may indicate that resource ‘SQLNetwork Name (CHSU-SQL2)’ has OR type of dependency on several IP addressessome of which are currently offline or in a failed state. Further action is onlyrequired if it is generally possible to bind the IP address of the clusterresource ‘SQL IP Address 2 <inst>’ to a network segment on the currenthosting node.
這條資訊清楚的顯示了IP地址[156.69.72.165]的狀態，並說明了SQL Server沒有繫結該IP地址。
對於成功上線的IP地址，錯誤日誌中依舊會記錄SQLServer繫結該IP的資訊。該資訊和之前版本的SQLServer是一樣的：
Server is listening on [10.22.13.16 <ipv4> 60362].
以下是使用多子網的 SQL Server故障轉移群集的一些示例配置：
· SQL Server群集 包括 Node1 和 Node2。 節點1連線到Subnet1。 Node2 連線到 Subnet2。 SQL Server 安裝程式將此配置視作一個多子網群集，並且將 IP地址資源依賴關係設定為 OR。
· SQL Server群集包括 Node1、Node2 和 Node3。Node1 和 Node2 連線到 Subnet1。 Node3 連線到 Subnet2。SQL Server 安裝程式將此配置視作一個多子網群集，並且將 IP 地址資源依賴關係設定為OR。 因為 Node1 和 Node2 位於同一子網上，所以此配置還提供本地高可用性。
· SQL Server群集包括 Node1 和 Node2。 Node1 連線到Subnet1 上。 Node2 同時連線到 Subnet1 和 Subnet2 上。 SQL Server 安裝程式將此配置視作一個多子網群集，並且將 IP 地址資源依賴關係設定為OR。
· SQL Server群集包括 Node1 和 Node2。 Node1 連線到Subnet1 和 Subnet2。 Node2 也連線到 Subnet1 和 Subnet2。 SQL Server 安裝程式將 IP 地址資源依賴關係設定為 AND。要注意，這種配置不被視作多子網故障轉移群集，因為群集的節點實際上是處於完全相同的子網環境中。
我們所討論的多子網SQL Server只限於IP地址資源依賴關係是OR的情況，即各個節點彼此處於不同的子網環境，多個IP地址不能在一個節點上全部上線的情況。
SQL Server 2012對多子網的支援，使得它更加適用於部署多站點群集。使用多子網的SQLServer群集，即使某個子網由於網路裝置的突然故障而整體癱瘓，也能通過故障轉移使用其他子網中的節點繼續執行資料庫服務，因此在抵禦網路故障上具有更強的能力。多子網的SQLServer群集在地理上分散，使得它能更好地抵禦例如自然災害，大規模停電等重大異常。此外，多子網的群集不是在有所有節點間共享資料儲存，所以需要在多個子網之間進行硬體儲存器級別的資料複製，這樣就獲得了多個可用資料的副本。因此在硬體支援的前提下，多子網SQLServer群集除了具備高可用性之外，還提供了資料災難恢復解決方案。
2. RegisterAllProvidersIP
多子網的SQL Server一般情況下，一個虛擬網路名對應多個IP地址，而只有其中一個IP地址資源是上線狀態的。那麼在DNS上到底是隻註冊了那個上線的IP地址，還是全部IP地址都註冊了呢？這取決於“虛擬網路名”資源的一個私有屬性，叫做RegisterAllProvidersIP。
如果RegisterAllProvidersIP被設定為0，那麼只有上線的IP地址會被註冊到DNS上，網路名也只會被解析到上線的IP地址。這看起來沒什麼問題，但是在發生故障轉移的時候可能會帶來一些麻煩。假設群集發生了故障轉移，從一個子網中的節點切換到了另一個子網中的節點。當故障轉移完成後，SQLServer資源組中的虛擬網路名沒有發生變化，但是開始啟用新子網中的IP地址。這時，客戶端需要知道新的IP地址，才能連上SQL Server。這通常要藉助DNS伺服器。但是DNS伺服器上的快取可能會造成DNS的更新延遲，在一段時間之內DNS伺服器依舊會將伺服器名解析成之前的IP地址（即老的子網的IP地址）。於是在這段時間裡，即使SQL Server已經恢復執行，連線SQL Server的請求還是會由於無效的IP地址而失敗，這會增加客戶端應用恢復到SQL Server的連線所需的時間。事實上，為了避免這類問題，WindowsServer 2008 R2群集在虛擬網路名資源上線的時候會立刻給DNS伺服器發一個註冊請求，目的就是儘快將伺服器名指向新的IP地址。不過如果在DNS伺服器端發生任何延遲，影響註冊請求的完成，那麼在這一段時間內，訪問SQLServer的請求還是會受到影響的。
為了徹底避免DNS更新延遲帶來的問題，SQL將虛擬網路名資源的RegisterAllProvidersIP的預設值設定為1。也就是說預設情況下，無論這個IP地址處於什麼狀態，多子網的群集依舊會在DNS 伺服器上註冊虛擬網路名到所有IP地址之間的解析關係。當客戶端應用要使用虛擬網路名來連線SQLServer的時候，它會從 DNS 伺服器檢索所有已註冊的IP 地址，並嘗試連線到這些地址。這樣，多子網SQL Server群集中的客戶端恢復連線的時間不再受DNS 更新延遲的影響。
預設情況下，客戶端會按順序去嘗試DNS上所有IP 地址。 當客戶端在其連線字串中使用MultiSubnetFailover=True 引數時，客戶端會改為並行地嘗試所有IP 地址，並使用第一臺響應它的IP地址來連線SQL Server伺服器。這樣的機制有助於在發生故障轉移時最大程度地減少客戶端恢復連線的延遲。目前，只有以下驅動支援在進行TCP連線時使用MultiSubnetFailover引數：
· SQL Native Client 11.0
· .NET Framework 4.02 或更高版本中的SQLClient（必須在連線字串中指定資料庫例項的 TCP 埠）。
· Microsoft JDBC Driver 4.0 for SQL Server
對於其他的驅動，你無法在連線字串中使用MultiSubnetFailover 引數，也就是說它們只能順序去嘗試所有IP地址。這增加了遇到連線資料庫超時錯誤的風險。因此，對那些訪問多子網SQL Server群集的客戶端，建議在連線字串中適當地增加連線超時的閾值。通常情況下的建議是：資源組中每增加一個IP地址資源，就增加 21秒的連線超時。 這樣，客戶端在嘗試重新連線SQLServer時，它會有足夠的時間來依次訪問所有 IP 地址。
SQL Server 2005 以前版本的SQL Server 故障轉移群集，資料庫的所有資料檔案和日誌檔案都必須被放在共享磁碟上，包括使用者資料庫和系統資料庫。
SQL Server 2008和SQL Server 2008 R2將系統資源資料庫（resource DB）與其他的系統資料庫分隔開來，單獨存放在了每個例項對應的Binn目錄下，和其他的SQL Server可執行檔案和DLL檔案放在了一起。這是因為resource 資料庫是隻讀的不可修改的，它僅是用來提供SQLServer所有的系統物件，因此從功能上來看resource資料庫更接近一個SQLServer的DLL而不是一個系統資料庫。因此SQLServer 2008和SQL Server 2008 R2的群集中resource資料庫的檔案是存放在本地磁碟上，而不是共享磁碟上。
從SQL Server 2012開始，除resource資料庫以外的所有系統資料庫（master，msdb，model和tempdb）及使用者資料庫不但可以被存放在共享磁碟中，也可以被存放在共享資料夾中。如果你的SQLServer 2012群集使用共享資料夾來存放資料庫，你必須使用“\\Servername\ShareName\...”這樣的通用命名約定 (UNC) 路徑格式。不可以使用環迴路徑（loopbackpath，例如 \\localhost\.. \）、管理共享（adminshare，例如 \\servername\x$）或對映網路驅動器。共享資料夾可以位於Windows檔案伺服器或第三方 的SMB（Server MessageBlock） 儲存裝置承載。 如果使用 Windows 檔案伺服器，該Windows 檔案伺服器版本應為 2008 或更高。
相比較共享磁碟，共享資料夾有三個主要的優點：
1. 免去了為共享磁碟配置SAN或者iSCSI等一系列繁瑣的操作步驟。
2. 節省了SAN儲存硬體。你可以使用任何儲存器來提供共享資料夾。
3. 使用共享磁碟，一個Windows群集上可以安裝的SQL Server 群集例項的數量取決於可用驅動器號的數量（無論是否使用mountpoint）。 如果只對作業系統使用一個驅動器號，則最多隻能有 25 個SQL Server 例項。使用共享資料夾的話，就可以突破驅動器號數量的限制，在一個Windows群集上可以安裝最多50個SQL Server群集例項。
你會發現在安裝的過程中，安裝程式並不強制要求你必須選擇一個共享磁碟。顯示了兩個可用的共享磁碟，但是你可以兩個都不勾選。
在指定資料庫存在位置的步驟中，你就可以使用共享檔案夾了。
SQL Server 2012群集的另一個變化是tempdb存放的位置。之前版本的SQL Server群集，要將所有使用者資料庫和系統資料庫，包括tempdb，都儲存在共享磁碟上。這樣能確保所以節點都使用同一份資料。故障轉移後無論哪個節點變成活躍節點，它所訪問的資料都是一致的。但是tempdb是一個特殊的資料庫，它在每次SQL Server啟動時都會被重新建立。也就是說，故障轉移後新的活躍節點得到的永遠是一個新的tempdb，它不包含任何以前存在於tempdb中的資料。因此tempdb資料庫其實不需要被群集的節點所共享。
SQL Server 2012群集允許使用者在安裝時將tempdb的存放位置設定在本地磁碟上。這樣當SQL Server資源組在某個節點上線時，就會在該節點的本地磁碟上建立新的tempdb的資料檔案和日誌檔案。除了tempdb和資源資料庫以外的其他資料庫依舊存放在共享磁碟或SMB檔案共享上。
你可以發現SQLServer 2012群集的安裝程式中多了Temp DB directory和TempDB Log directory這兩個文字框，它們允許你為tempdb單獨設定區別於其他資料庫的存放路徑。
將tempdb存放在本地磁碟可以節約共享磁碟的空間。另外，tempdb上一般會發生較多的I/O操作，所以將tempdb存放在本地磁碟還可以減輕共享磁碟的負載，有助於提高其他資料庫的I/O效能。
如果將tempdb存放在本地磁碟的目錄中，你需要確保群集中的所有節點上都有這個目錄並且SQLServer的啟動賬號對這個目錄有讀寫許可權。否則一旦發生故障轉移，SQL Server就可能會因為無法建立tempdb而不能上線。
前面介紹過SQL Server群集使用兩種檢查方式來確保群集正常工作並在需要的時候觸發故障轉移。一種是looksalive檢查，它僅是簡單的去檢查活躍節點上SQL Server服務是否還在執行。另一種是Isalive檢查，它是由群集服務開啟一個連線到SQL Server裡，並執行語句[email protected]@servername，根據語句是否成功執行來進一步判斷SQL Server是否依舊在正常提供服務。
很多情況下SQL Server發生故障轉移就是由Isalive檢查失敗所觸發的。管理員在故障轉移發生以後，需要檢查SQL Server日誌和Windows系統日誌，以瞭解為什麼Isalive檢查會失敗，當時SQL Server出了什麼問題。但是，很大一部分故障轉移產生的原因是SQL Server當時出現了效能問題，以至於無法響應Isalive檢查。很多效能問題，如CPU使用率100%，工作執行緒用盡，都不會記錄在錯誤日誌中。由此帶來的問題就是，資料庫管理員能從群集日誌或Windows的事件日誌中判斷出SQL Server當時可能發生了效能問題，但無法得知具體是什麼樣的效能問題，於是也就無法採取措施來防止問題再次發生。
有時候SQL Server效能問題並不是十分嚴重，而且可能在很短的時間內就能自動恢復。使用者可能不希望在這種情況下，Isalive檢查失敗就立刻觸發故障轉移。但是舊有的Isalive檢查沒有提供客製化的介面，使用者或管理員無法自己指定SQLServer發生故障轉移的場景。
SQL Server 2012群集使用了全新的Resource DLL（名字依舊是sqsrvres.dll）。新的Resource DLL中，Looksalive檢查基本保持了其原有的功能，但是Isalive檢查方式發生了變化。新的Isalive不僅依賴檢查群集服務和SQLServer之間的連通性來判斷SQL Server的健康狀況，它還依賴SQLServer內部進行自我診斷，並將診斷結果報告給Resource DLL。總的來說，新的ResourceDLL有四個特性：
· 舊的Resource DLL在每次執行Isalive檢查時生成一個連線到SQL Server，執行完select @@servername後就關閉連線，直到下次執行Isalive檢查時再建立新的連線。而新的Resource DLL會在SQLServer資源上線後就始終使用一個獨立的執行緒來維持一個到SQL Server的持續連線，連線不會中斷，直到SQL Server資源進入離線狀態。
· 新的Resource DLL改為執行一個全新的儲存過程 “sp_server_diagnostics”來執行Isalive檢查，判斷伺服器健康情況。Sp_server_diagnostics會收集SQLServer當前的診斷資訊並返回給resource DLL並記錄在擴充套件事件日誌中，預設情況下sp_server_diagnostics每20秒執行一次。SQL Server 2012群集的Isalive檢查就依賴sp_server_diagnostics返回的資訊來判定SQL Server是否工作正常，預設Isalive檢查間隔依舊是60秒。可見，這種檢查比僅執行[email protected]@servername要可靠很多。
· 新的Resource DLL允許使用者自己指定發生故障轉移的條件。一旦Isalive或Looksalive發現SQL Server例項處於不健康的狀態，那麼resource DLL就會將當前的健康狀態與使用者指定的故障轉移條件做對比，決定是否應該發生故障轉移。客戶可以根據系統的要求，設定什麼情況下SQL會做故障轉移。
· Resource DLL會保留一段時間的sp_server_doagnostics歷史診斷資訊。這些資訊可以更有效地幫助管理員找到發生故障轉移的原因。
Resource DLL會根據SQL Server資源名到登錄檔裡查詢SQL的版本資訊，以決定當前的SQL例項是否是2012版本，是否使用新的擴充套件功能。這意味從SQL Server2012開始，管理員不能輕易更改SQL Server的資源名，否則就可能會發生Resource DLL找不到該例項的版本、造成SQLServer資源不能上線的問題。
因為SQL Server資源型別使用了新的resourceDLL，你會發現SQL Server資源有了一些新的私有屬性。
其中大部分屬性在以前版本的SQL Server群集中都存在，它們的作用也沒什麼變化。這裡我們重點介紹下新的resource DLL引入的兩個新屬性。
FailureConditionLevel
SQL Server 2012群集定義了從0到5總共6個級別的故障轉移條件。使用者可以通過設定SQLServer資源的FailoverConditionLevel屬性來指定SQLServer在滿足何種條件下發生故障轉移。對於級別 1-5，每個級別除了自己的條件外，還包括之前級別的所有條件。這意味著，級別越高，故障轉移或重新啟動的機率就越大。 下表（2-1）介紹了這些故障條件級別：
|
級別 |
名稱 |
條件 |
|
0 |
無自動故障轉移或重新啟動 |
|
|
1 |
伺服器關閉時進行故障轉移或重新啟動 |
SQL Server使用最廣的高可用性技術叫做故障轉移群集（SQLServer Failover Cluster）。這是一項基於Windows故障轉移群集的一種技術。SQLServer故障轉移群集技術集成了微軟技術一貫簡單易用的特點，在部署和管理上都非常容易，同時又能提供 結構 故障轉移 ppi 靈活 使用 表數 定時 不支持 http 原文:sql server 高可用性技術總結一. 復制Replication（快照、事務、合並）
應用場景： 負載均衡、提供副本讀，寫操作。 分區將歷史數據復制到其它
經常在論壇中看到有人問資料同步的技術，如果只是同步少量的表，那麼可以考慮使用連結伺服器+觸發器，來實現資料同步，但當要同步的資料表比較多，那麼可以考慮用資料庫複製技術，來實現資料的同步。
一、使用場
介紹
物理故障、作業系統故障或 SQL Server 故障都可能導致兩個可用性副本之間的會話失敗。 可用性副本不會定期檢查 Sqlservr.exe 所依賴的元件來驗證這些元件是在正常執行還是已出現故障。 但對於某些型別的故障，受影響的元件將向 Sqlservr.exe 報告錯誤。 由另一個元 span 術語 sre 數據庫配置 logs 優點 style col 登錄 原文:sql server 高可用日誌傳送一. 日誌傳送概述
SQL Server使用日誌傳送，可以自動將主服務器的事務日誌備份發送到一個或多個輔助數據庫上。可選的監視服務器，記錄備份和 設置 inf 初始 08 r2 執行 進行 利用 iscs info 二臺sql服務器配置ISCSI虛擬磁盤
在上篇我們利用ISCSI Target軟件在DC-ISCSCI上創建了三個ISCSI虛擬磁盤，在下面我們將為大家介紹SQL-CL01(hsr1 50)和
SQL Server 是 windows 平臺 .NET 架構下標配資料庫解決方案，與 Oracle、MySQL 共同構成了 DB-Engines Ranking 的第一陣營，在國內外企業市場中有著廣泛的應用。Mirroring 是 SQL Server 最常用的高可用解決方 上一篇中提到用SpringBoot2.0+Eureka搭建服務註冊中心和服務提供者，詳情參考：
https://www.cnblogs.com/SysoCjs/p/10127448.html
現在講一下SpringCloud+Eureka搭建高可用註 在談到SQL Server的高可用性之前，我們首先要談一談單例項的高可用性。在單例項的高可用性中，不可忽略的就是檔案和檔案組的高可用性。SQL Server允許在某些檔案損壞或離線的情況下，允許資料庫依然保持部分線上，從而保證了高可用性。 檔案和檔案組 有關檔案和檔案組的基本概念，有很 自從SQL Server 2005以來，微軟已經提供了多種高可用性技術來減少宕機時間和增加對業務資料的保護，而隨著SQL Server 2008，SQL Server 2008 R2，SQL Server 2012的不斷髮布，SQL Server中已經存在了滿足不同場景的多種高可用性技術。
下面列舉了選擇高可用性解決方案的注意事項：
故障轉移群集和資料庫映象都提供以下功能：
·自動檢測和故障轉移
·手動故障轉移
·透明客戶端重定向
故障轉移群集具有下列限制：
·需要在伺服器例項範圍內進行操作
·需要簽名的硬體
·備用部分不具有報告功能
·利用資料庫的單個副本
·
本章，我們討論有關RabbitMQ的容錯性，訊息一致性及高可用性。RabbitMQ可以作為叢集節點來執行，因此RabbitMQ通常被歸為分散式訊息系統，對於分散式訊息系統，我們的關注點通常是一致性與可用性。
我們為什麼要討論分散式系統的一致性與可用性，本質在於兩者描述的是系統在失敗的
Eureka簡介
什麼是Eureka？
Eureka是Netflix開源的服務發現元件，本身是一個基於REST的服務。它包含Server和Client兩部分。Spring Cloud將它整合在子專案Spring Cloud Netflix中，從而實現服務的註冊與發現 （注：Eurek
主從複製
redis主從複製非常簡單，只需要在從資料節點配置slaveof master-ip master-port即可。我就不多說了。
舉個例子，分別建立3個配置檔案，redis-6379.conf，redis-6380.conf，
所謂高可用性指的是系統如何保證比較高的服務可用率，在出現故障時如何應對，包括及時發現、故障轉移、儘快從故障中恢復等等。本文主要以點評的交易 系統的演進為主來描述如何做到高可用，並結合了一些自己的經驗。需要強調的是，高可用性只是一個結果，應該更多地關注迭代過程，關注業
SQL Server 2008 資料庫的備份與恢復
平時敲程式碼習慣了不時的儲存、生成新的解決方案以保證意外發生時能夠及時拯救自己的成果。
對於資料庫這樣的重要資料就更加需要合理備份，下面我們就來一起看看它的備份與恢復吧！
SQL資料庫的備份
進入Mic 賬號 後來 普通 src water col blog online 容器 近期在搭建Always On高可用性集群時需要與域控對接，申請域賬號，對其進行加域權限委派，服務器加域及集群創建均無問題，在創建監聽的時候提示：群集網絡名稱資源“*_listener”無法在域“my ani 否則 編譯 什麽 高並發 設置時間 檢測 isolation 管理 了解事務和鎖
事務：保持邏輯數據一致性與可恢復性，必不可少的利器。
鎖：多用戶訪問同一數據庫資源時，對訪問的先後次序權限管理的一種機制，沒有他事務或許將會一塌糊塗，不能保證數據的安全正確讀寫。
死鎖 wget 環境 erb 服務 work complete status ppr sql 環境說明：操作系統：CentOS6.7 x86_64Nginx版本：nginx-1.9.7Keepalived版本：keepalived-1.2.24 主nginx + Keepaliv cisco ap 高可用性設置AP HA Settings1-AP HA 設置2-global configuration下配置3-確保RF group名字一致4-確保APgroup也一致本文出自 “Erick WAY” 博客，謝絕轉載！AP 高可用性設置 |