可用性組、非同步模式、手動/強制故障轉移 - 處理身份重疊
我們有一個非同步模式下的兩個副本 2017 標準可用性組。使用故障轉移（手動/強制，因為不能自動執行），如果輔助節點落後於主節點，我們就有可能重疊/重用標識值。這對我們來說真的很糟糕……客戶A 看到客戶B 的數據。
編輯：我最關心的是主伺服器意外離線的 DR/故障故障轉移。計劃中的故障轉移（修補等）將更易於管理，方法是等待或強制輔助節點在使主節點離線之前同步到主節點，如下所示。
- 有沒有辦法在輔助節點接管主角色時自動執行腳本，以碰撞所有身份列（DBCC CHECKIDENT RESEED）以允許最終合併舊主節點的未同步記錄？
- 由於這是標準的，所以在它接管為主伺服器之前，輔助伺服器是不可訪問的，那麼腳本何時/如何執行？
- 附帶問題：由於舊的主要成為次要（一旦它重新上線）並且在那時無法訪問（標準），如何對其執行查詢以確定未同步的記錄？將舊主數據庫備份/恢復為非 AG 數據庫？
謝謝！
與其嘗試對新主節點上的故障轉移做出反應，我認為更新您的手動故障轉移過程以首先將 AG 更改為同步模式會更有意義。
一旦 AG 指示它已同步，則執行故障轉移。這樣您就不會失去數據。然後，您可以在故障轉移完成後返回非同步模式。
有關如何在故障轉移之前進行更改的說明，請參閱更改可用性副本 (SQL Server) 的可用性模式。
注意：如果兩台伺服器之間的網路變慢，同步模式 AG可以暫時切換到非同步模式
如果輔助副本超過了主副本的會話超時期限，則主副本會暫時切換到該輔助副本的非同步送出模式。當輔助副本與主副本重新連接時，它們會恢復同步送出模式
但是根據故障轉移文件，同步模式 AG 保證在手動故障轉移期間數據失去為零。
這保證了在以前的主數據庫上送出的每個事務也已在新的主數據庫上送出
我不確定客戶 A 將如何查看客戶 B 的數據，除非您在主伺服器上的客戶 A 和客戶 B 之間移動數據（並假設所有數據都在 1 個數據庫中）。數據的同步順序與在主伺服器上發生的順序相同。它可能不代表主伺服器中的目前時間點，但它將代表生產伺服器上的確切時間點。
在增加 ID 方面，從 SQL 2012 開始，每當您重新啟動 SQL Server 時，SQL Server 都會在 Identity 列中預設增加（請參閱此答案），因此無論如何您可能會看到一個跳躍。
在主系統恢復聯機後同步數據方面：如果您在非同步 AG 上強制進行故障轉移，那麼一旦主系統恢復聯機，您就必須對所有數據進行完全重新同步，而不僅僅是從那時起更改的數據它離線了。這通常涉及在主節點上刪除和重新創建數據庫，然後將其重新添加到可用性組，就好像它是一個全新的節點一樣。沒有開箱即用的同步數據方法。
這並不意味著您不能建構一個，您可以找到在故障轉移之前存在於主伺服器上但沒有進入輔助伺服器的所有數據，然後將其複製到目前的主伺服器，但這取決於您將這些數據拉出並將其添加到輔助節點。在此過程中，您可以創建新的 ID。你的複製品跑了多遠？企業願意放棄多少數據？如果您只落後幾分鐘並且有能力失去 5 分鐘的數據，那麼您可能不想取回這些數據。
附帶說明一下，SQL 標準版上的可用性組也存在您無法找到的數據損壞的真正風險。這是因為您無法在輔助節點上執行完整性檢查或備份。我認為您應該定期對數據的每個副本執行完整性檢查，否則您如何知道輔助伺服器上的數據在故障轉移之前沒有被磁碟錯誤損壞？