我想更好地理解“sql server standalone”和“sql server failover instance”之間的區別
正如這些問題所問的：
“Always On Failover Cluster Instances”和“SQL Server Failover Clustering”是一回事嗎？
Windows Server 故障轉移群集不應該已經處理 SQLServer 故障轉移群集嗎？
我對集群有一些疑問。
在我的第一份工作中，我記得我們有一個帶有 4 個節點的故障轉移集群。每個節點上有 3 個 SQL 伺服器實例和一個用於故障轉移的空節點。如果某個節點出現問題，它將故障轉移到那個空節點，並且不會導致已經有 SQL 實例的節點出現性能問題。
問：如果我沒記錯的話，我們有一個共享磁碟故障轉移集群。因此，每個數據庫都位於與所有節點共享的單個磁碟中。但是實例變為空節點發生了什麼？我的意思是，那裡沒有 SQL 安裝，沒有實例，但是在故障轉移之後，該實例及其所有作業都在那裡。這是否意味著虛擬機去了空節點？
現在我有了一份新工作，但我仍然不太了解集群的概念。我們有一個帶有 2 個節點的故障轉移集群。在這裡，我創建了一個 Always on 可用性組環境。它很好用（唯一的問題是我們還沒有法定人數，但我們會到達那裡）。這裡的環境不一樣。我必須在每個節點上安裝 2 個 SQL Server 實例。這就是我想到達的地方。
這是否意味著在第一份工作中我們有一個
sql server failover cluster installation? 在這項新工作中，我剛剛stand-alone installation在兩個節點上都安裝了普通實例。（當我開始第一份工作時，我的 sql 知識為 0，所以我真的不記得配置是什麼了）。
sql server stand-alone installation所以基本上，和`sql server 故障轉移集群安裝有什麼區別。還有一個問題。幾乎每週我們都會遭受故障轉移的困擾。我確定 node1 正在失去與 node2 的連接，然後仲裁失去。quorum 的概念是，如果 node1 與 node2 失去連接，quorum 可以說“哦，他們沒有相互通信，但 node1 還活著，所以我不會對它們進行故障轉移。對嗎？
首先，讓我們定義幾個術語：
SQL Server 故障轉移群集/Always On 故障轉移群集實例
這些術語可以互換。Always On 故障轉移群集只是 SQL Server 故障轉移群集或 SQL FCI 的現代術語。FCI 由具有共享磁碟的 Windows Server 故障轉移群集中的多個節點組成。
SQL Server 軟體安裝在每個節點上，但是，安裝的實例是集群的特殊實例 - 故障轉移集群實例。WSFC 服務管理節點之間的 SQL 實例和共享磁碟的故障轉移，以提供高可用性和災難恢復。該實例的 SQL Server 服務存在於所有節點上，但僅在群集的活動節點上啟動和執行。
出於所有意圖和目的，只有一個實例，它與底層共享磁碟一起在節點之間移動。節點之間的數據同步是通過使用相同的底層磁碟來實現的，因此節點之間的數據狀態是相同的。
SQL Server Always On 可用性組
SQL Server Always On 可用性組 (SQL AG) 是一種用於高可用性和災難恢復的現代解決方案，它不需要共享磁碟基礎架構（事實上，在某些情況下甚至不需要 WSFC 群集，但這是另一個主題）。
它仍然使用 WSFC 集群來管理故障轉移和可用性，但是，節點之間的數據同步並沒有利用共享磁碟來確保數據是最新的，而是完全在 SQL Server 內部使用一種機制來在節點之間傳輸數據塊，或複製品，因為它們在 AG 中被稱為。
AG 架構中的每個 Replica 都是一個獨立的 SQL Server 實例。底層電腦作為節點加入 WSFC 集群，每個節點上的 SQL Server 實例都啟用了 Always On 功能。
在這些副本之間創建 AG 時，數據移動機制開始在連接到 AG 的數據庫的副本之間移動數據。這與 SQL Server 早期版本的數據庫鏡像非常相似，並且基於相同的技術建構。使用這種“鏡像”技術實現數據同步。
獨立 SQL Server 實例
獨立 SQL Server 實例很簡單，是一個沒有通過 HADR 技術連結或加入的 SQL Server 實例。顧名思義，這個實例是獨立的。
雖然看起來 Always On 架構具有多個獨立實例，但因為伺服器是通過底層 WSFC 集群加入的，而實例是通過可用性組加入的，所以它們不是獨立實例。
集群與集群
通常術語集群、SQL 集群和 Always On 集群在 Always On 和 FCI 之間相當可互換，但有一個重要區別 - SQL 集群是 SQL Server 故障轉移集群實例，Always On 集群並不真正存在，它的Always On 可用性組，應該這樣稱呼，“集群”通常是指 FCI 或 Always On Ag 所基於的底層 Windows Server 故障轉移集群。
現在回答你的問題：
問：如果我沒記錯的話，我們有一個共享磁碟故障轉移集群。因此，每個數據庫都位於與所有節點共享的單個磁碟中。但是實例變為空節點發生了什麼？
共享磁碟 FCI 在每個節點上都安裝了軟體，但實例會根據需要在節點之間移動。將實例視為主數據庫所在的任何位置。當 FCI 故障轉移時，託管主機的共享磁碟也會進行故障轉移，因此當 SQL Server 在新節點上啟動時，它會啟動已移動的主數據庫，從而啟動實例。
我的意思是，那裡沒有 SQL 安裝，沒有實例，但是在故障轉移之後，該實例及其所有作業都在那裡。這是否意味著虛擬機去了空節點？
實際上，SQL Server 安裝在該節點上。當託管文件的磁碟移動時，VM 沒有移動，實例及其所有數據庫、作業等都移動了。節點 2 上的 SQL Server 服務在故障轉移後啟動並重新連接到實例文件。
這是否意味著在第一份工作中我們安裝了 sql server 故障轉移集群？在這個新工作中，我只是在兩個節點上安裝了普通的獨立安裝實例。
在新環境中，聽起來他們已經安裝了 Always On 可用性組架構。
還有一個問題。幾乎每週我們都會遭受故障轉移的困擾。我確定 node1 正在失去與 node2 的連接，然後仲裁失去。quorum 的概念是，如果 node1 與 node2 失去連接，quorum 可以說“哦，他們沒有相互通信，但 node1 還活著，所以我不會對它們進行故障轉移。對嗎？
Quorum 應該是決勝局——如果兩個節點都投票認為他們看不到另一個，那麼每個節點都想接管主要角色（FCI 或 AG），這將導致腦裂。WSFC 集群不會讓這種情況發生，而是會關閉集群。
當您擁有偶數個節點時，Quorum 會給您一個決定性的投票。如果節點 1 上的集群服務無法與節點 2 通信，但它可以與仲裁見證（文件共享或共享磁碟）通信，則它有兩個投票（一個來自節點，一個來自仲裁見證），節點 2 只有一票。它被否決，節點 1 保持活動狀態。如果節點 2 有兩票，則啟動故障轉移。
重要的是始終擁有奇數票。在更高版本的 Windows Server 中，節點權重和節點投票會動態調整以嘗試強制執行奇數票，但只有兩票，它無法強制執行此操作。
更新 -
下面是來自 Microsoft 的圖表，有助於說明差異：
從圖中可以看出，可用性組是跨安裝在加入 WSFC 群集的伺服器上的獨立 SQL Server 實例建構的。故障轉移群集實例作為 SQL Server 的單個實例安裝在 WSFC 群集中的多個節點上，使用共享儲存。
儘管 SQL Server 的二進製文件和執行檔安裝在 FCI 的所有節點上，但實例（系統數據庫、使用者數據庫等）安裝在共享儲存上，並且一次僅在單個節點上處於活動狀態。
在 AG 中，兩個獨立實例同時啟動並執行，AG 偵聽器（虛擬網路名稱）僅偵聽主副本。
此連結提供有關 SQL Server 中業務連續性的詳細資訊，包括 AG 和 FCI。
