Exchange DAG 自動故障轉移 - 原因
我們的 2013 DAG 似乎有點武斷地啟動其他伺服器上的數據庫並將它們從它們活躍的那些上移走。在查看指標時，RAM/IO/網路/等方面沒有明顯的峰值，所以我不確定為什麼會有變化。
我找不到如何審核數據庫移動的原因，並且正在尋找可能有助於解決此問題的日誌文件或 powershell cmdlet。
為了澄清，簡化了很多事情：伺服器 1 有 DB1 處於活動狀態 伺服器 2 有 DB2 處於活動狀態 伺服器 3 有 DB3 處於活動狀態
每台伺服器都有其他兩個數據庫的被動副本。一夜之間，沒有明顯的原因，事情會發生變化，看起來像這樣：
伺服器 1 有 DB1 和 DB3 處於活動狀態 伺服器 2 沒有處於活動狀態的 DB 伺服器 3 有 DB 2 處於活動狀態
謝謝你的幫助！
PS：如果有人正在處理此問題並希望在失去某些功能（即自動故障轉移）的情況下停止它，請考慮在您要停止自動故障轉移的每台伺服器上使用以下策略：
Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked其中 EXSRV01 替換為要停止自動啟動的 Exchange 伺服器的名稱。
我將添加到我的評論中以獲得更完整的答案。基於 mfinni 對集群的響應，如果數據庫發生故障轉移，總會出現錯誤。Exchange 對任何錯誤的預設反應是使數據庫故障轉移以防止出現腦裂情況（兩個數據庫都認為它們處於活動狀態並導致危害人類罪）。
您可以擁有完全合理的 CPU/記憶體，並且看似沒有網路故障，但在 MSFT 集群中，您會看到由於多種原因而出現的故障。如果集群認為它有問題，它會出色地重新啟動集群服務以確保一切正常。發生這種情況時，Exchange 將對所有數據庫進行故障轉移。這可能是由許多類似的問題引起的：
- 超出郵箱伺服器的高記憶體使用已經瘋狂的記憶體分配（2013 在這裡做得更好）
- 項目清單
- 網路“曇花一現”；不要在這裡冒犯您的網路管理員，這實際上可能是心跳網路上的 TTL 增加，或者甚至出於任何原因重置到 vswitch
- Vmotion ….但你把它關閉了，因為它不受支持。;-)
集群事件查看器日誌將為您提供“故障”發生的時間，您可以將其與高可用性事件查看器日誌相關聯，以確定是否存在問題或是否是突發事件。我已經看到數據庫本身太忙於試圖跟上一些由失控的 cron 作業引起的一些部門的郵件炸彈，這導致事務日誌超過數據庫健康的複制門檻值限制……繁榮。 .. 故障轉移。
如果您在這些日誌中發現任何內容，請將其發布（清理敏感數據），我可以提供更多幫助。並確保您在所有 Exchange 伺服器上都安裝了最新更新檔。有一些 CU 更新無緣無故地導致了類似的問題。