外观
SQLServer 从单机到 Always On 迁移
从单机到 Always On 迁移概述
将 SQL Server 从单机架构迁移到 Always On 可用性组是提高数据库高可用性和灾难恢复能力的重要步骤。Always On 可用性组提供了比传统故障转移群集更灵活的高可用解决方案，支持多数据库故障转移和可读辅助副本。
本文将详细介绍从单机到 Always On 可用性组的迁移过程，包括准备工作、实施步骤、验证和最佳实践，帮助 DBA 顺利完成迁移。
迁移前准备
1. 环境准备
硬件要求：
- 至少需要两台服务器（推荐三台或更多，用于承载主副本和辅助副本）
- 每台服务器需要足够的 CPU、内存、磁盘和网络资源
- 建议使用相同或相似的硬件配置，确保性能一致性
软件要求：
- SQL Server 2012 或更高版本（企业版或开发版）
- Windows Server 2008 R2 或更高版本
- .NET Framework 4.0 或更高版本
网络要求：
- 所有服务器必须加入同一个 Active Directory 域
- 服务器之间需要可靠的网络连接，建议使用专用网络进行同步
- 配置适当的防火墙规则，允许 Always On 相关端口通信
2. 配置 Windows 故障转移群集
Always On 可用性组依赖于 Windows 故障转移群集（WFC），因此需要先配置 WFC：
步骤：
- 在所有服务器上安装故障转移群集功能
- 验证群集配置（运行 Validate Cluster 向导）
- 创建故障转移群集
- 配置群集网络和存储（如果需要）
示例命令：
powershell
# 安装故障转移群集功能
Install-WindowsFeature Failover-Clustering -IncludeManagementTools
# 验证群集配置
Test-Cluster -Node Server1, Server2, Server3 -Include "Storage", "Network", "System Configuration"
# 创建故障转移群集
New-Cluster -Name AOCluster -Node Server1, Server2, Server3 -StaticAddress 192.168.1.1003. 配置 SQL Server 实例
启用 Always On 可用性组：
- 在 SQL Server 配置管理器中，右键单击 SQL Server 服务，选择属性
- 在 "Always On 高可用性" 选项卡中，勾选 "启用 Always On 可用性组"
- 重启 SQL Server 服务
配置服务账户：
- 确保所有 SQL Server 实例使用相同的域账户运行
- 为服务账户授予适当的权限，包括群集管理权限
配置端点：
- Always On 使用数据库镜像端点进行通信
- 确保端点已正确配置，并且使用合适的身份验证方式（证书或 Windows 身份验证）
示例脚本：
sql
-- 创建数据库镜像端点
CREATE ENDPOINT [Hadr_endpoint]
STATE=STARTED
AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (
ROLE = ALL,
AUTHENTICATION = WINDOWS NEGOTIATE,
ENCRYPTION = REQUIRED ALGORITHM AES
);迁移实施步骤
1. 数据库准备
在源数据库上执行：
- 确保数据库使用完整恢复模式
- 执行完整备份和事务日志备份
- 确保数据库不是只读的
- 移除任何数据库级别的限制
示例脚本：
sql
-- 检查并修改恢复模式
ALTER DATABASE [YourDB] SET RECOVERY FULL;
-- 执行完整备份
BACKUP DATABASE [YourDB] TO DISK = N'\backup\YourDB_full.bak' WITH COMPRESSION, STATS = 10;
-- 执行事务日志备份
BACKUP LOG [YourDB] TO DISK = N'\backup\YourDB_log.bak' WITH COMPRESSION, STATS = 10;2. 创建可用性组
步骤：
- 在主副本服务器上，使用 SSMS 或 T-SQL 创建可用性组
- 指定可用性组名称和副本配置
- 选择要包含在可用性组中的数据库
- 配置可用性组监听器
示例脚本：
sql
-- 创建可用性组
CREATE AVAILABILITY GROUP [AG1]
WITH (DB_FAILOVER = ON, CLUSTER_TYPE = WSFC)
FOR DATABASE [YourDB]
REPLICA ON
N'Server1' WITH (
ENDPOINT_URL = N'TCP://Server1:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50,
SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE)
),
N'Server2' WITH (
ENDPOINT_URL = N'TCP://Server2:5022',
FAILOVER_MODE = AUTOMATIC,
AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50,
SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE)
),
N'Server3' WITH (
ENDPOINT_URL = N'TCP://Server3:5022',
FAILOVER_MODE = MANUAL,
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 100,
SECONDARY_ROLE (ALLOW_CONNECTIONS = READ_ONLY),
PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE)
);
-- 创建可用性组监听器
ALTER AVAILABILITY GROUP [AG1]
ADD LISTENER N'AGListener' (WITH IP (
(N'192.168.1.101', N'255.255.255.0')
) , PORT = 1433);3. 加入辅助副本
步骤：
- 在每个辅助副本服务器上，连接到 SQL Server 实例
- 加入可用性组
- 恢复数据库到辅助副本
示例脚本：
sql
-- 在辅助副本上加入可用性组
ALTER AVAILABILITY GROUP [AG1] JOIN WITH (CLUSTER_TYPE = WSFC);
ALTER AVAILABILITY GROUP [AG1] GRANT CREATE ANY DATABASE;
-- 恢复数据库到辅助副本（在每个辅助副本上执行）
RESTORE DATABASE [YourDB] FROM DISK = N'\backup\YourDB_full.bak'
WITH NORECOVERY, STATS = 10;
RESTORE LOG [YourDB] FROM DISK = N'\backup\YourDB_log.bak'
WITH NORECOVERY, STATS = 10;
-- 将数据库加入可用性组
ALTER DATABASE [YourDB] SET HADR AVAILABILITY GROUP = [AG1];4. 同步数据
监控同步状态：
- 使用 SSMS 查看可用性组仪表板
- 检查每个副本的同步状态
- 确保所有数据库都处于 "已同步" 状态（对于同步提交模式）
示例查询：
sql
-- 检查可用性组状态
SELECT ag.name AS AGName,
ar.replica_server_name AS ReplicaName,
db_name(drd.database_id) AS DBName,
drs.synchronization_state_desc,
drs.synchronization_health_desc,
drs.last_hardened_lsn,
drs.last_redone_lsn
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_database_replica_cluster_states drd ON ar.replica_id = drd.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drd.replica_id = drs.replica_id AND drd.group_database_id = drs.group_database_id
ORDER BY ag.name, ar.replica_server_name, db_name(drd.database_id);5. 应用切换
准备工作：
- 更新应用程序连接字符串，使用可用性组监听器名称
- 测试应用程序连接到监听器
- 确保所有数据库都已同步
切换步骤：
- 停止应用程序对源数据库的写入操作
- 执行最后一次事务日志备份
- 在辅助副本上恢复最后一次事务日志备份（使用 WITH RECOVERY）
- 更新应用程序连接字符串，指向可用性组监听器
- 启动应用程序，验证功能正常
示例脚本：
sql
-- 执行最后一次事务日志备份
BACKUP LOG [YourDB] TO DISK = N'\backup\YourDB_final_log.bak' WITH COMPRESSION, STATS = 10;
-- 在辅助副本上恢复最后一次事务日志备份
RESTORE LOG [YourDB] FROM DISK = N'\backup\YourDB_final_log.bak'
WITH RECOVERY, STATS = 10;迁移验证
1. 功能验证
- 验证应用程序可以通过监听器正常连接到数据库
- 测试数据库读写操作正常
- 验证辅助副本的可读性
2. 高可用性验证
手动故障转移测试：
- 在 SSMS 中，右键单击可用性组，选择 "故障转移"
- 按照向导执行故障转移
- 验证应用程序自动连接到新的主副本
- 验证数据一致性
自动故障转移测试：
- 模拟主副本服务器故障（如重启 SQL Server 服务或关闭服务器）
- 监控可用性组自动故障转移过程
- 验证应用程序连接是否自动恢复
- 检查数据一致性
3. 性能验证
- 监控主副本和辅助副本的性能指标
- 检查 CPU、内存、磁盘和网络使用率
- 验证复制延迟在可接受范围内
- 测试应用程序响应时间
迁移后优化
1. 备份策略优化
- 配置备份优先级，让辅助副本承担备份负载
- 避免在主副本上执行大型备份操作
- 确保备份策略覆盖所有副本
示例脚本：
sql
-- 配置备份优先级
ALTER AVAILABILITY GROUP [AG1]
MODIFY REPLICA ON N'Server3' WITH (BACKUP_PRIORITY = 100);
-- 配置备份首选项
ALTER AVAILABILITY GROUP [AG1]
SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY_ONLY);2. 性能优化
- 优化网络配置，减少复制延迟
- 为辅助副本配置适当的只读路由
- 优化查询，利用可读辅助副本分担查询负载
- 配置适当的同步模式（同步/异步）
3. 监控和告警
- 配置可用性组监控，包括同步状态、复制延迟、故障转移事件等
- 设置告警，及时通知可用性组相关问题
- 定期检查可用性组日志和 Windows 事件日志
示例监控查询：
sql
-- 监控复制延迟
SELECT ag.name AS AGName,
ar.replica_server_name AS ReplicaName,
db_name(drd.database_id) AS DBName,
drs.synchronization_delay_sec,
drs.last_hardened_time,
drs.last_redone_time
FROM sys.availability_groups ag
JOIN sys.availability_replicas ar ON ag.group_id = ar.group_id
JOIN sys.dm_hadr_database_replica_cluster_states drd ON ar.replica_id = drd.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drd.replica_id = drs.replica_id AND drd.group_database_id = drs.group_database_id
WHERE drs.synchronization_delay_sec > 0
ORDER BY drs.synchronization_delay_sec DESC;常见问题和解决方案
1. 可用性组创建失败
问题：创建可用性组时出现错误，提示无法连接到端点
解决方案：
- 检查数据库镜像端点是否已启动
- 验证防火墙规则是否允许端点端口通信
- 检查服务账户权限是否足够
- 验证网络连接是否正常
2. 辅助副本同步失败
问题：辅助副本无法同步数据，显示 "未同步" 状态
解决方案：
- 检查数据库恢复模式是否为完整恢复模式
- 确保已在辅助副本上正确恢复完整备份和事务日志备份
- 检查端点配置和网络连接
- 查看 SQL Server 错误日志，查找具体错误信息
3. 故障转移失败
问题：执行故障转移时失败
解决方案：
- 检查故障转移群集状态是否正常
- 验证主副本和辅助副本的同步状态
- 确保辅助副本已同步所有事务日志
- 查看 Windows 事件日志和 SQL Server 错误日志
4. 应用程序连接问题
问题：应用程序无法通过监听器连接到数据库
解决方案：
- 检查监听器配置是否正确
- 验证监听器 IP 地址和端口是否可访问
- 检查 DNS 记录是否正确
- 测试监听器连接（使用 telnet 或 ssms）
最佳实践
1. 规划和设计
- 充分评估业务需求和 SLAs，选择合适的高可用架构
- 设计合理的副本拓扑，包括同步和异步副本
- 考虑地理位置冗余，将副本部署在不同的数据中心
- 规划足够的硬件资源，确保性能和可靠性
2. 实施和测试
- 在测试环境中充分测试迁移过程和故障转移
- 制定详细的迁移计划和回滚计划
- 选择业务低峰期进行迁移
- 确保所有团队成员了解迁移流程和职责
3. 监控和维护
- 建立完善的监控和告警机制
- 定期执行故障转移测试，确保高可用性正常工作
- 定期更新和维护 SQL Server 和 Windows 操作系统
- 保持文档更新，记录架构变更和维护操作
4. 性能和优化
- 优化网络配置，减少复制延迟
- 合理配置同步模式，平衡性能和数据安全性
- 利用辅助副本分担查询负载和备份操作
- 定期进行性能评估和优化
总结
将 SQL Server 从单机架构迁移到 Always On 可用性组是提高数据库高可用性和灾难恢复能力的重要举措。通过充分的准备工作、详细的实施计划和严格的验证测试，可以确保迁移过程顺利完成，并且在迁移后获得良好的高可用性和性能。
迁移过程中需要注意环境准备、群集配置、SQL Server 配置、数据同步和应用切换等关键步骤。同时，迁移后的监控、维护和优化也是确保 Always On 可用性组长期稳定运行的重要因素。
遵循本文介绍的最佳实践和注意事项，可以帮助 DBA 顺利完成从单机到 Always On 可用性组的迁移，为业务提供更可靠、更高可用的数据库服务。