我们的2013年DAG似乎有些任意激活其他服务器上的数据库,并将它们从活动的数据库中移出。 在查看指标时,RAM / IO / Networking /等中没有明显的高峰,所以我不确定为什么会出现这种情况。
我找不到如何审核数据库移动的原因,并且正在查找可能有助于解决此问题的日志文件或PowerShell cmdlet。
为了澄清,简化了很多事情:服务器1具有DB1活动服务器2具有DB2活动服务器3具有活动的DB3
每台服务器都有另外两个数据库的被动副本。 一夜之间,没有明显的原因,事情会移动,看起来像这样:
服务器1具有活动的DB1和DB3服务器2没有活动的数据库服务器3具有活动的数据库2
谢谢你的帮助!
PS:如果有人正在处理这个问题,并希望在丢失某些function(如自动过期)时停止它,请考虑在要停止自动closures的每台服务器上使用以下策略:
Set-MailboxServer -Identity EXSRV01 -DatabaseCopyAutoActivationPolicy Blocked
EXSRV01replace为Exchange服务器的名称以停止自动激活。
我会添加到我的评论更完整的答案。 build立在mfinni对集群的响应上,如果一个数据库发生故障,总会有一个错误。 交易所对任何错误的默认反应是使数据库失效,以防止分裂的大脑情景(这两个数据库都认为它们是活跃的并导致危害人类的罪行)。
你可以有一个完全合理的CPU /内存,似乎没有networking闪烁,但在MSFT集群,你会看到许多原因失败。 如果集群认为存在问题,那么RESTARTING集群服务确保一切正常。 发生这种情况时,Exchange将对所有数据库进行故障转移 这可能是由以下许多问题引起的:
群集事件查看器日志会为您提供发生“失败”的时间,您可以将此事件与高可用性事件查看器日志相关联,以确定问题是否存在或者是否是突发事件。 我已经看到了数据库本身在忙于跟上某些部门由于失控cron作业而造成的一些邮件炸弹,这导致事务日志超过了数据库健康的复制阈值极限。 ..故障转移。
如果您在这些日志中find任何内容,请发布它(清理敏感数据),我可以提供更多帮助。 并确保您在所有Exchange服务器上进行了最新补丁。 有几个CU更新导致类似的问题无缘无故。
如果这些是虚拟机,并且备份过程涉及到获取Vmware快照,则可能会在允许的DAG心跳上超时。 您需要将SameSubnet和CrossSubnet延迟和阈值设置为高于默认值。
cluster /prop SameSubnetDelay=2000:DWORD cluster /prop CrossSubnetDelay=4000:DWORD cluster /prop CrossSubnetThreshold=10:DWORD cluster /prop SameSubnetThreshold=10:DWORD