Exchange DAG自动故障转移 – 原因

发布时间：2020-12-13 23:02:49 所属栏目：Windows 来源：网络整理

导读：我们的2013 DAG似乎在某种程度上任意激活其他服务器上的数据库,并将它们从他们活跃的服务器上移除.在查看指标时,RAM / IO /网络/等没有明显的峰值,所以我不确定为什么会有移动. 我找不到如何审核数据库移动的原因,并且正在查找日志文件或powershell cmdlet,

我们的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 ….但你有正确的,因为这是不支持的.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!