Exchange DAG自动故障转移 – 原因

前端之家收集整理的这篇文章主要介绍了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对群集的响应,如果数据库发生故障,则始终存在错误.交易所对任何错误的默认反应是使数据库失败以防止裂脑情况(两个数据库都认为它们活跃并导致危害人类罪).

你可以拥有一个完全合理的cpu /内存,而且似乎没有网络闪烁,但在MSFT群集中,你会看到失败的原因有很多.如果群集认为它有问题,它可以很好地重新启动群集服务以确保一切正常.发生这种情况时,Exchange将故障转移所有数据库.这可能是由许多类似的问题引起的:

>超出邮箱服务器的高内存使用量已经疯狂的内存分配(2013年在这里做得更好)
>列表项目
>网络“昙花一现”;不要冒犯你的网络管理员,它可能会在心跳网络上增加TTL,甚至无论出于何种原因重置为vswitch
> Vmotion ….但你有正确的,因为这是不支持的.

猜你在找的Windows相关文章