為什麼選擇 SQL FCI 而不是數據庫鏡像
我有 SQL 2016標準版來安裝和配置 HA/DR 解決方案。我需要在兩個節點的集群中進行自動故障轉移。我提出 SQL FCI over database Mirroring 的原因如下：
- FCI 將只需要兩個節點進行配置，並將自動進行故障轉移
- 微軟正在逐步淘汰數據庫鏡像，此外，為了實現自動故障轉移，除了集群的兩個節點之外，我們還需要一個額外的伺服器（用於見證）。因此需要 3 個虛擬機中的 3 個不同的 SQL 實例。
你同意我的推理嗎？請問我還有其他需要考慮的事情嗎？自動故障轉移在需求中是必不可少的。
謝謝你。
我要補充一點，數據庫鏡像是一種數據庫 HA/DR 解決方案。相反，FCI 是一個實例 HA/DR 解決方案。這意味著它涵蓋了系統數據庫和登錄、連結伺服器、作業等內容……
這是一個非常開放的問題，並且缺少很多資訊。
- 您的伺服器是在硬體上執行還是已經虛擬化（VMware、Microsoft、其他……）？
- 本地磁碟還是 SAN？
- 您是否意識到 FCI（故障轉移集群實例）需要您配置 WSFC（Windows 伺服器故障轉移集群）？
如果您決定使用 FCI，那麼您將引入大量複雜性。意見可能會有所不同，但根據文件Always On Failover Cluster Instances (SQL Server) (Microsoft | SQL Docs)，您仍然可能存在單點故障。
例子：
（強調我的）
與可用性組相反，FCI 必須在 FCI 的所有節點之間使用共享儲存來儲存數據庫和日誌。共享儲存的形式可以是 WSFC 群集磁碟、SAN 上的磁碟、儲存空間直通 (S2D) 或 SMB 上的文件共享。這樣，每當發生故障轉移時，FCI 中的所有節點都具有相同的實例數據視圖。然而，這確實意味著共享儲存有可能成為單點故障，而 FCI 依賴於底層儲存解決方案來確保數據保護。
所以你的假設：
FCI 將只需要兩個節點進行配置，並將自動進行故障轉移
.. 不完整。您還需要在後台共享儲存。
WSFC 是一個複雜的設置，如安裝故障轉移群集之前(Microsoft | Docs) 中所述。
回答你的問題
你同意我的推理嗎？請問我還有其他需要考慮的事情嗎？
好吧，見上文。我不同意。鏡像非常簡單，可以配置為在 VMware 環境中執行，具有較低的複雜性和較低的要求。是的，您需要 3 台伺服器來進行自動故障轉移，但它們在虛擬化環境中價格低廉。
在 VMware 環境中安裝 FCI 和 WSFC 可能會很棘手。想一想，當您在 VMware 級別擁有它時，為什麼需要在 SQL Server 級別進行 HA/DR 配置？
- FCI 將只需要兩個節點進行配置，並將自動進行故障轉移
沒錯，但在後台使用共享儲存。
- 微軟正在逐步淘汰數據庫鏡像，此外，為了實現自動故障轉移，除了集群的兩個節點之外，我們還需要一個額外的伺服器（用於見證）。因此需要 3 個虛擬機中的 3 個不同的 SQL 實例。
沒錯，但在虛擬化環境中價格便宜。並且更易於配置，因為您不需要底層 WSFC 和共享儲存。
如果我們將問題的標題作為自己的問題：
為什麼選擇 SQL FCI 而不是數據庫鏡像
..那麼我可以用微軟的建議來回答這個問題：
此功能將在 Microsoft SQL Server 的未來版本中刪除。避免在新的開發工作中使用此功能，併計劃修改目前使用此功能的應用程序。請改用 Always On 可用性組。
兩種實現都各有利弊，但我發現鏡像的簡單性超過了 WSFC 和 FCI 的複雜性。