Exchange Server作为企业内部使用最广泛的邮件系统之一，其可用性直接关系到日常办公。单台邮箱服务器一旦宕机，数据库无法挂载，邮件收发立刻中断。微软给出的标准答案就是DAG（Database Availability Group，数据库可用性组），它可以将多台邮箱服务器组合成一个逻辑单元，让数据库副本在成员服务器之间自动复制，主副本故障时自动切换到备用副本。本文将结合Windows Server环境，详细讲解DAG的原理、部署步骤和常见问题的排查方法。
一、DAG的工作原理与核心概念
DAG的本质是一个故障转移集群的简化版，但它不完全依赖Windows故障转移群集（WSFC）。在Exchange 2013及之后的版本中，DAG仍然会底层创建一个WSFC群集，只是管理界面被Exchange接管，管理员不需要手动操作群集资源。每个加入DAG的服务器最多可以承载100个数据库副本，而一个数据库在DAG内的副本数量最多为16份。
DAG的核心机制是日志传送和重放。活动数据库副本产生事务日志文件，日志首先写入本地，然后通过日志传送机制复制到其他被动副本所在的服务器，被动副本将日志重放到自己的数据库副本中，从而保持数据一致。这个过程是异步的，也就是说被动副本可能存在短暂的落后，这也是为什么在极端灾难场景下可能丢失少量最新邮件。
另一个关键概念是仲裁（Quorum）。DAG需要一个多数节点集来判定谁是合法的活动副本。当DAG成员为偶数时，必须引入见证服务器（Witness Server）来打破平局，防止出现脑裂（Split Brain）。见证服务器可以是域内任何一台运行Windows Server的机器，但推荐使用不承载Exchange邮箱角色的服务器，比如客户端访问服务器或其他成员服务器。
二、部署DAG的前置条件与网络准备
部署DAG之前需要确认几个硬性条件：所有成员服务器必须运行相同版本的Exchange Server，操作系统建议使用Windows Server 2016或更高版本；所有服务器必须加入同一个Active Directory域，且不能是域控制器；每台服务器需要至少两块网卡，一块用于MAPI通信（客户端访问），一块用于复制网络（日志复制流量），虽然单网卡也能工作，但生产环境强烈建议分离。
权限方面，创建DAG的账户需要是Exchange Organization Management角色组成员。如果使用见证服务器，Exchange Trusted Subsystem组需要对见证服务器拥有本地管理员权限，这个组默认存在于域中，可以通过下面的PowerShell命令把见证服务器的本地管理员组加入Exchange Trusted Subsystem：
# 在见证服务器上执行，将Exchange Trusted Subsystem加入本地管理员组 $exGroup = [ADSI]"WinNT://contoso/Exchange Trusted Subsystem,group" $localAdmins = [ADSI]"WinNT://./Administrators,group" $localAdmins.Add($exGroup.Path)
此外还要检查Windows防火墙规则，DAG成员之间需要放行的端口包括：MSExchangeRepl服务使用的TCP 64327（动态分配，也可以手动固定）、集群心跳端口UDP 3343以及RPC动态端口范围。如果服务器之间有网络设备隔离，务必先测试连通性，可以使用Test-ReplicationHealth命令验证复制通道是否正常。
三、创建DAG并添加成员服务器
DAG的创建可以通过Exchange管理中心的图形界面完成，也可以用命令行完成。命令行方式更适合批量操作和脚本化，这里以PowerShell为主进行演示。假设我们有两台邮箱服务器MBX01和MBX02，见证服务器为WITNESS01，创建DAG的命令如下：
# 创建一个名为DAG01的数据库可用性组
New-DatabaseAvailabilityGroup -Name DAG01 `
-WitnessServer WITNESS01 `
-WitnessDirectory C:\DAGWitness `
-DatabaseAvailabilityGroupIpAddresses 192.168.10.50
参数中的WitnessDirectory是见证服务器上存放仲裁文件的目录，系统会自动创建。DatabaseAvailabilityGroupIpAddresses为DAG分配一个静态IP地址，如果环境是纯IPv6或者使用DHCP，可以填写参数值AUTO。创建完成后，把两台邮箱服务器加入DAG：
# 向DAG添加成员服务器 Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer MBX01 Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer MBX02
添加过程需要几分钟，期间Exchange会在底层创建WSFC群集对象。如果这一步失败，最常见的原因是WitnessDirectory权限不足或者C:\Windows\System32下的集群组件被安全策略限制，可以查看系统事件日志中的FailoverClustering来源的报错来定位。加入成功后，用Get-DatabaseAvailabilityGroup DAG01 -Status | fl Name,Servers,WitnessServer,AlternateWitnessServer确认成员列表和见证服务器状态。
四、添加数据库副本与故障转移验证
DAG就绪后，接下来为数据库添加副本。假设数据库DB01当前位于MBX01上，执行下面的命令在MBX02上创建一份被动副本：
# 在MBX02上添加DB01的副本 Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer MBX02 -ActivationPreference 2 # 查看副本状态和内容索引状态 Get-MailboxDatabaseCopyStatus DB01 | fl Name,Status,CopyQueueLength,ReplayQueueLength,ContentIndexState
ActivationPreference指定激活优先级，数字越小优先级越高。副本添加后需要等待初始种子设定（Seeding）完成，即MBX02通过网络完整复制一份数据库文件和日志到自己的路径下。种子设定耗时取决于数据库大小和网络带宽，也可以用Update-MailboxDatabaseCopy命令手动重新做种子。健康状态下，Status应显示Healthy，CopyQueueLength和ReplayQueueLength应接近于零，ContentIndexState为Healthy表示搜索索引也已同步。
部署完成后必须做一次故障转移演练。可以先模拟MBX01宕机，观察数据库是否自动切换到MBX02，也可以手动执行移动：
# 手动将DB01激活到MBX02 Move-ActiveMailboxDatabase -Identity DB01 -ActivateOnServer MBX02 -MountDialOverride:None # 检查DAG整体复制健康度 Test-ReplicationHealth -Server MBX02 Get-MailboxDatabaseCopyStatus * | ft Name,Status,CopyQueueLength -AutoSize
切换过程中客户端会经历短暂断开，Outlook会自动重连，无需用户干预。建议每季度做一次完整的故障转移演练，并记录切换耗时，作为容灾指标的参考数据。
五、常见问题排查与运维建议
DAG日常运维中最常见的问题是副本状态长时间处于Failed或ServiceDown。排查思路可以按顺序进行：先看Test-ReplicationHealth的输出定位失败的具体检查项，再检查MSExchangeRepl服务是否运行，然后确认网络是否丢包，尤其是复制网络的MTU配置不一致会导致日志复制卡顿。日志文件默认存放在数据库所在目录，路径中类似E:\ExchangeDB\DB01的位置如果磁盘空间不足，重放队列会持续增长。
另一个高频问题是见证服务器失效导致DAG离线。当偶数成员的DAG失去见证服务器时，剩余节点无法达成仲裁，所有数据库都会卸载。解决办法是提前配置备用见证服务器：
# 配置备用见证服务器
Set-DatabaseAvailabilityGroup -Identity DAG01 `
-AlternateWitnessServer WITNESS02 `
-AlternateWitnessDirectory C:\DAGWitnessAlt
运维层面还有两点建议：一是为DAG配置数据中心激活协调模式（DAC Mode），防止跨机房切换时旧站点数据库意外上线；二是定期用Get-MailboxDatabaseCopyStatus做巡检并把结果输出到日志，可以配合Windows计划任务实现自动化监控，一旦发现队列长度异常增长就及时告警。做好这些细节，DAG才能真正发挥它高可用架构的价值。
Exchange DAG数据库可用性组Windows Server修改时间：2026-09-12 20:12:39