SQL Server数据库镜像实战：从零配置到故障转移（附常见问题排查）

SQL Server数据库镜像实战：从零配置到故障转移（附常见问题排查）

对于许多运维工程师和DBA来说，当业务系统对停机时间的容忍度从“小时”缩短到“分钟”甚至“秒”时，高可用性就不再是一个可选项，而是必须落地的技术方案。我经历过不止一次深夜被电话叫醒，处理数据库服务器宕机的紧急情况，那种压力至今记忆犹新。正是在这些实战中，SQL Server的数据库镜像（Database Mirroring）技术，以其相对简洁的架构和可靠的故障转移能力，成为了许多团队构建第一道高可用防线的选择。它不像AlwaysOn可用性组那样需要复杂的Windows故障转移集群（WSFC）基础架构，但又能提供实时的数据保护和快速的业务接管能力，特别适合那些希望以较低成本快速提升核心数据库韧性的场景。本文将从一个实践者的角度，带你完整走一遍从环境准备、配置、测试到故障转移的闭环，并分享那些配置手册上不会写、但实际工作中一定会遇到的“坑”及其解决方案。

1. 环境准备与前置检查：打好地基

在开始敲任何配置命令之前，充分的准备工作是成功的一半。数据库镜像对运行环境有一些特定的要求，忽略它们往往会导致配置过程卡壳，甚至为未来的稳定运行埋下隐患。

首先，我们需要明确角色与网络拓扑。 一个标准的数据库镜像会话涉及三个角色：主体服务器（Principal）、镜像服务器（Mirror），以及可选的见证服务器（Witness）。主体服务器承载生产数据库，处理所有读写事务；镜像服务器则实时接收并重做（Redo）事务日志，保持数据同步；见证服务器仅用于在高安全模式下实现自动故障转移，它不存储数据，只参与仲裁。对于大多数初次部署的场景，我建议先从“主体-镜像”两台服务器开始，手动进行故障转移测试，待熟悉流程后再考虑引入见证服务器实现自动化。

注意：主体数据库和镜像数据库必须使用相同的SQL Server版本（如均为SQL Server 2019 Standard Edition）且排序规则一致。企业版支持所有功能，而标准版仅支持同步高安全模式，不支持异步高性能模式。

网络是数据库镜像的“生命线”。所有服务器实例之间必须能够通过主机名或完全限定域名（FQDN）相互解析和访问。一个常见的错误是只在IP层面连通，而忽略了名称解析。

# 在每台服务器上，使用ping和telnet测试连通性与端口
ping mirror-server-hostname
telnet mirror-server-hostname 5022

上述命令检查到镜像服务器的网络连通性以及默认的数据库镜像端点端口（5022）是否开放。如果使用非默认端口，需相应调整。

其次，进行必要的服务账户与权限配置。 虽然可以使用内置账户，但为了更好的安全性和可管理性，我强烈建议为SQL Server服务配置一个域账户。这个账户需要在所有参与镜像的服务器上拥有适当的权限。更重要的是，我们需要为每个SQL Server实例创建数据库镜像端点（Endpoint）。端点就像一个专用的、安全的通信通道。

-- 在主体服务器上创建镜像端点示例
CREATE ENDPOINT [MirroringEndpoint]
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
    FOR DATA_MIRRORING (
        ROLE = PARTNER,
        AUTHENTICATION = WINDOWS NEGOTIATE,
        ENCRYPTION = REQUIRED ALGORITHM AES
    );

创建端点后，需要将连接权限授予给镜像服务器和见证服务器（如果存在）的服务账户。

GRANT CONNECT ON ENDPOINT::[MirroringEndpoint] TO [YOURDOMAIN\SQLServiceAccount];

最后，准备源数据库。 不是所有数据库都适合镜像。需要确保数据库恢复模式为“完整恢复模式”（FULL），因为镜像依赖事务日志进行同步。然后，对主体数据库进行一次完整备份和一次事务日志备份，这是为镜像服务器准备种子数据的基础。

-- 在主体服务器上执行
BACKUP DATABASE [YourDatabase]
TO DISK = N'D:\Backup\YourDatabase_Full.bak'
WITH FO