SQL Server 数据库实战：完整解析SQL Server 2005镜像配置全过程

SQL Server | 数据库实战：完整解析SQL Server 2005镜像配置全过程

那个惊心动魄的凌晨3点

"老张！生产数据库挂了！" 凌晨3点接到这通电话时，我正梦见自己在夏威夷度假，一个激灵从床上弹起来，手忙脚乱地穿上衣服就往公司赶，到了机房才发现，主数据库服务器因为硬件故障彻底罢工了，而我们的备用数据库...呃,其实是上周的备份磁带。

如果当时配置了SQL Server数据库镜像，我本可以喝着咖啡，优雅地点击几下就把服务切换到备用服务器上，今天我就把这份血泪教训转化为实战经验，手把手带你搞定SQL Server 2005的镜像配置。

镜像配置前的准备工作

1 硬件环境要求

首先别急着动手，咱们得把场地准备好,配置镜像需要至少两台服务器：

• 主体服务器：跑主数据库的机器
• 镜像服务器：随时准备接班的备胎
• （可选）见证服务器：负责自动故障转移的裁判

我建议三台物理分开的机器，实在预算紧张的话，至少主体和镜像要分开，别学我之前那家公司，把主备放在同一台物理机的两个虚拟机上——电源一断全玩完。

2 软件要求

• SQL Server 2005 Standard/Enterprise版（Workgroup版不支持镜像）
• 所有服务器最好同版本同补丁级别
• 数据库恢复模式必须为完整恢复模式

-- 检查数据库恢复模式
SELECT name, recovery_model_desc 
FROM sys.databases 
WHERE name = '你的数据库名';

如果不是"FULL",赶紧改过来：

ALTER DATABASE 你的数据库名 SET RECOVERY FULL;

3 网络准备

服务器之间需要开通5022端口（默认镜像端口）的通信，如果跨机房，记得让网络组的同事把防火墙规则配好，别到时候互相ping得通,镜像死活连不上。

实战配置步骤

1 备份当前数据库

先在主体服务器上做个全备+日志备份：

-- 全量备份
BACKUP DATABASE 你的数据库名 
TO DISK = 'D:\Backup\你的数据库名.bak' 
WITH FORMAT, COMPRESSION;
-- 日志备份
BACKUP LOG 你的数据库名 
TO DISK = 'D:\Backup\你的数据库名.trn';

把这两个备份文件拷贝到镜像服务器上。

2 在镜像服务器上还原数据库

关键点来了！还原时一定要加WITH NORECOVERY，这样数据库会保持在"正在还原"状态,准备接收镜像数据。

-- 还原全量备份
RESTORE DATABASE 你的数据库名 
FROM DISK = 'D:\Backup\你的数据库名.bak'
WITH NORECOVERY, 
MOVE '逻辑数据文件名' TO 'D:\Data\你的数据库名.mdf',
MOVE '逻辑日志文件名' TO 'D:\Logs\你的数据库名.ldf';
-- 还原日志备份
RESTORE LOG 你的数据库名 
FROM DISK = 'D:\Backup\你的数据库名.trn'
WITH NORECOVERY;

3 配置端点（Endpoint）

镜像通信靠端点,相当于给数据库开了个专属热线。

在主体服务器上执行：

CREATE ENDPOINT MirroringEndpoint
STATE = STARTED
AS TCP (LISTENER_PORT = 5022)
FOR DATABASE_MIRRORING (ROLE = PARTNER);

在镜像服务器上执行同样的命令,注意ROLE也设为PARTNER。

4 建立镜像关系

现在让两台服务器"牵手成功",先在镜像服务器上设置主体服务器：

ALTER DATABASE 你的数据库名 
SET PARTNER = 'TCP://主体服务器IP:5022';

然后在主体服务器上设置镜像服务器：

ALTER DATABASE 你的数据库名 
SET PARTNER = 'TCP://镜像服务器IP:5022';

如果一切顺利，你会看到数据库状态变成"已同步",这时候可以喝口茶庆祝下了。

5 （可选）配置见证服务器

想要自动故障转移？那就得上见证服务器了,配置步骤类似：

1. 在见证服务器上创建端点
2. 在主体和镜像服务器上设置见证服务器地址：

ALTER DATABASE 你的数据库名 
SET WITNESS = 'TCP://见证服务器IP:5022';

常见翻车现场与解决方案

1 错误1416：数据库不完全一致

这个问题我遇到过不下十次，通常是因为备份还原步骤没做对,检查：

• 是否使用了NORECOVERY
• 是否还原了所有必要的日志备份
• 两台服务器上的数据库文件名和路径是否一致

2 镜像状态显示"已挂起"

网络问题占90%！检查：

• 防火墙是否放行了5022端口
• SQL Server服务账号是否有权限访问端点
• 可以尝试telnet对方IP 5022测试连通性

3 性能突然下降

镜像会占用网络带宽，如果数据变更频繁,建议：

• 使用专用网络进行镜像通信
• 调整镜像安全级别（默认是FULL，可以尝试HIGH PERFORMANCE模式）

日常运维小贴士

1. 监控镜像状态：

   

   SELECT db_name(database_id) AS DatabaseName, 
       mirroring_state_desc, 
       mirroring_safety_level_desc
   FROM sys.database_mirroring
   WHERE mirroring_guid IS NOT NULL;

2. 故障转移测试：定期演练手动故障转移，确保真出事时不手忙脚乱

   -- 在主体服务器上执行
   ALTER DATABASE 你的数据库名 SET PARTNER FAILOVER;

3. 日志备份不能停：镜像依赖日志传送，长期不备份日志会导致镜像挂起

真实案例：那次我们真的用上了镜像

去年双十一大促，我们的电商平台数据库服务器CPU风扇突然罢工，机器直接过热关机，得益于配置好的镜像，30秒内完成了自动切换，用户甚至没感觉到异常，事后算了下，那次故障如果导致系统停运1小时，公司至少损失200万订单——而我们的DBA团队获得了一个月奖金和三天假期。

SQL Server镜像技术虽然已经被后来的Always On技术取代，但在SQL Server 2005环境下仍然是实现高可用的重要手段，配置过程看似复杂，但只要按步骤来，其实就像搭积木一样有章可循，好的DBA不是在故障发生时力挽狂澜,而是让故障根本影响不到业务。

去配置你的数据库镜像吧，..祝你永远用不上它！