使用 SQL Server Standard 對可用性組進行負載平衡
所以我有目前的場景，它看起來工作得非常好，但我只是想獲得一些關於配置的輸入。聰明嗎？有沒有我沒有想到的問題？
我們有 SQL Server Standard，因此，每個 AG 只能有 1 個 DB（我們有 20 個數據庫），並且沒有隻讀輔助數據庫。基本上意思是，主伺服器正在做所有的提升，而輔助伺服器做的少得多。因此，本質上，您為節點 2 的資源付費，這些資源的工作負載為 10%，而節點 1 的工作負載為 70/80%。兩個節點都獲得了 SQL Server 核心的完全許可。
為了幫助實現這一點，我所做的是將數據庫初選分割開來。所以大約 50% 的數據庫是 node1 上的主數據庫，而另外 50% 是 node2 上的主數據庫。
結果：
這些應用程序都通過各自的偵聽器很好地連接到任一節點。如果發生故障轉移，只有故障節點上的數據庫會受到影響，並且故障轉移到另一個節點（我們對此進行了很好的測試）。
現在每個節點都可以分擔負載，本質上是負載平衡。以這種方式設置它是一個手動過程，並且在部署新的數據庫和組時，它們會轉到較輕的節點。但是要付出很小的代價來購買“更多”硬體而無需太多成本（我們已經擁有的許可證和一些管理員）。
小伙伴們對此有何看法？
我有點喜歡你的想法，雖然它打敗了主節點和第二節點的想法。您應該確保評估一台伺服器是否可以承擔兩者的負載，如果一台伺服器出現故障，那麼一台伺服器將承擔所有負載。
您還應該小心，如果一台伺服器上的活動及時變高，它可能會影響“第二”節點活動並導致 I/O 瓶頸。（這完全取決於您的磁碟是如何配置的。）
但除此之外，它可能是一個不錯的選擇，當您的組織變得更大時，您將能夠負擔得起另一台伺服器來從目前設置中移除一些負載。只要確保仔細檢查您的緊急情況並對其進行很好的測試。
我在輔助節點上編寫了一些 AG 的故障轉移腳本，以便能夠一直“負載平衡”我的 AG（作業在伺服器啟動時執行）。
我沒有在產品中實現它，也不會因為：
1 - 很難確定每個節點是否能夠處理全部負載（例如，在一個節點發生故障或 DR 的情況下）。由於負載總是“分裂”的，如果兩台伺服器都以 80% 使用，我不會注意到它，並且在伺服器故障的情況下會受到影響，迫使我只在一個節點上執行幾天。
2 - 它使修補變得更加困難，因為我們可以在不影響使用者的情況下修補輔助節點，使用“拆分”方法，將不再有任何輔助伺服器，因此無論您重新啟動節點，您都會受到影響（兩次如果載入是自動的，因為一旦修補的伺服器重新上線，就會有另一個故障轉移）。
最後，您還應該確保沒有跨數據庫查詢。如果 DB1 中的查詢/儲存過程如下所示：
update DB2.dbo.table ...您最終將嘗試在不可寫的數據庫上執行更新。
如果你對這些缺點沒意見，那麼我想有“負載平衡”是件好事，不幸的是，它沒有內置在 SQL 中的可用性組中。
謝謝