SQL SERVER 2014 Standard - 高可用性偵聽器解決方案
該公司擁有 SQL Server 2014 Standard 許可證，我們將伺服器置於 VMware 環境中。
我最初的計劃是在每個數據庫伺服器上創建 2 個實例，並將 SQL1 上的 Instance1 作為主伺服器，將 SQL2 上的 Instance2 作為主伺服器執行，反之亦然。
問題：
- 如果沒有僅通過企業添加可用的偵聽器，是否有人在故障轉移進行維護時使用負載均衡器重新指向數據庫連接？
- 有沒有更好的標準版故障轉移方法？
唯一想到的其他解決方案是 DNS CNames/ALIAS 並重新指向不同的 IP 地址，但這似乎天生就有缺陷。
使用 SQL Server 2014 標準版，您可以創建一個兩節點故障轉移基礎結構。為此，您需要在每個節點中至少擁有 Windows Server 2008 R2 SP1 Standard，因為您需要首先使用 Windows Server 生成故障轉移群集。
如果您想要一個多實例故障轉移集群，那麼您需要生成兩個 SQL Server 2014 安裝，因為該產品在主動-被動模式下工作。我的意思是，您需要安裝第一個實例 SQL1，然後繼續安裝第二個實例 SQL2。您需要配置每個實例，以便 SQL1 在節點 1 中執行，而 SQL2 在節點 2 中執行。
此外，非常重要和建議您至少有一個 SAN 或一些可以為您提供共享儲存架構的設備，因為在 SQL Server 故障轉移群集安裝之前，您需要驗證 Windows Server 故障轉移群集對 SQL 的支持伺服器一。
為什麼不使用數據庫鏡像，並配置您的應用程序以使用連接字元串中的故障轉移夥伴進行連接（在此處閱讀更多資訊Connect Clients to a Database Mirroring Session (SQL Server)）。如果您需要自動 DBM 故障轉移，那麼您還需要一個見證伺服器（並同步執行）才能使用具有自動故障轉移的高安全模式。
如果您不想在連接字元串中使用故障轉移夥伴，而不是使用 DNS 別名重定向，您還可以考慮使用 SQL 客戶端別名。如果您希望它們被“企業部署”，您可以使用組策略將這些系統資料庫項推送到您的應用程序伺服器中。請記住，這些解決方案是手動的（與 FP 是自動的相反）。
請注意，數據庫鏡像在 SQL Server 2012 中已被棄用，因此您應該注意 if 將在未來版本中刪除：
此功能將在 Microsoft SQL Server 的未來版本中刪除。避免在新的開發工作中使用此功能，併計劃修改目前使用此功能的應用程序。請改用 AlwaysOn 可用性組。
因此，一旦您使用 SQL Server 2016 SE，您可以考慮將您的 DBM 升級到 Basic AG。當您準備好遷移到基本可用性組時，請查看AlwaysOn 基本可用性組 (SQL Server) 概述，以了解該組與企業版 AG 之間的限制。