1. 环境准备与基础配置在开始部署SQL Server 2019 Always On高可用集群之前我们需要先准备好基础环境。这里我们使用两台运行Windows Server 2019 Datacenter的服务器分别命名为master和backup。这两台服务器将组成我们的高可用集群。首先我们需要为两台服务器配置网络环境。每台服务器都需要配置静态IP地址并确保它们位于同一子网内。以下是推荐的IP配置方案master服务器192.168.1.201backup服务器192.168.1.202集群虚拟IP192.168.1.203监听器虚拟IP192.168.1.204接下来我们需要修改每台服务器的hosts文件添加以下条目192.168.1.201 master.xx.com 192.168.1.202 backup.xx.com 192.168.1.203 MyCluster.xx.com 192.168.1.204 mk-SQL在实际操作中我发现关闭防火墙可以避免很多连接问题。虽然生产环境中不建议完全关闭防火墙但在测试环境中可以暂时禁用防火墙以便于调试。在两台服务器上执行以下PowerShell命令Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False2. 配置故障转移集群配置故障转移集群是整个部署过程中最关键的一步。我们需要在两台服务器上安装故障转移集群功能。可以通过PowerShell快速完成安装Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools安装完成后我们需要验证集群配置。在一台服务器上运行以下命令Test-Cluster -Node master.xx.com,backup.xx.com如果验证通过就可以创建集群了。创建集群时需要注意几个关键点集群名称建议使用有意义的名称如MyCluster管理访问点IP填写我们预留的集群虚拟IP192.168.1.203确保选择正确的存储设备如果有创建集群的PowerShell命令如下New-Cluster -Name MyCluster -Node master.xx.com,backup.xx.com -StaticAddress 192.168.1.203创建完成后可以通过故障转移集群管理器验证集群状态。我曾经遇到过集群创建成功但节点状态异常的情况这时候通常需要检查网络连接和防火墙设置。3. 安装SQL Server 2019在两台服务器上安装SQL Server 2019企业版时有几个关键点需要注意安装功能建议全选但可以排除机器学习服务以减少资源占用身份验证模式选择混合模式并设置强密码的sa账户数据目录建议使用非系统盘如果有确保两台服务器的安装选项完全一致安装完成后我们需要启用Always On功能。这可以通过SQL Server配置管理器完成打开SQL Server配置管理器右键SQL Server服务选择属性切换到Always On可用性组选项卡勾选启用Always On可用性组重启SQL Server服务我曾经遇到过启用Always On后服务无法启动的问题这通常是因为SQL Server服务账户没有足够的权限。解决方法是为服务账户授予锁定内存页和以服务身份登录权限。4. 配置证书认证在无域环境中我们需要使用证书来替代域认证。首先在两台服务器上创建共享文件夹如C:\gdmk并设置Everyone有读写权限。在主服务器master上执行以下T-SQL命令创建证书USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD YourStrongPassword123!; CREATE CERTIFICATE CERT1 WITH SUBJECT CERT1, START_DATE 2023-01-01, EXPIRY_DATE 2099-12-30; BACKUP CERTIFICATE CERT1 TO FILE C:\gdmk\CERT1.cer; CREATE ENDPOINT [group0_endpoint] AUTHORIZATION [sa] STATESTARTED AS TCP (LISTENER_PORT 5022, LISTENER_IP ALL) FOR DATA_MIRRORING (ROLE ALL, AUTHENTICATION CERTIFICATE CERT1, ENCRYPTION REQUIRED ALGORITHM AES); GO在备份服务器backup上执行类似的命令但要使用不同的证书名称USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD YourStrongPassword123!; CREATE CERTIFICATE CERT2 WITH SUBJECT CERT2, START_DATE 2023-01-01, EXPIRY_DATE 2099-12-30; BACKUP CERTIFICATE CERT2 TO FILE C:\gdmk\CERT2.cer; CREATE ENDPOINT [group0_endpoint] AUTHORIZATION [sa] STATESTARTED AS TCP (LISTENER_PORT 5022, LISTENER_IP ALL) FOR DATA_MIRRORING (ROLE ALL, AUTHENTICATION CERTIFICATE CERT2, ENCRYPTION REQUIRED ALGORITHM AES); GO证书创建完成后需要将证书文件互相拷贝到对方的共享文件夹中然后在每台服务器上导入对方的证书-- 在master服务器上执行 CREATE CERTIFICATE CERT2 FROM FILE C:\gdmk\CERT2.cer; -- 在backup服务器上执行 CREATE CERTIFICATE CERT1 FROM FILE C:\gdmk\CERT1.cer;5. 创建可用性组现在我们可以创建可用性组了。首先在主服务器上创建一个测试数据库CREATE DATABASE MyDemo; GO USE MyDemo; GO CREATE TABLE Product (ID INT PRIMARY KEY, Name NVARCHAR(50)); GO -- 执行完整备份 BACKUP DATABASE MyDemo TO DISK C:\gdmk\MyDemo.bak WITH INIT; GO然后通过SSMS的可用性组向导创建可用性组连接到主服务器右键Always On可用性组选择新建可用性组向导指定可用性组名称如AG1选择刚才创建的MyDemo数据库指定副本添加backup服务器作为次要副本配置监听器使用我们预留的监听器IP192.168.1.204选择完全初始数据同步创建完成后可以通过以下命令验证可用性组状态SELECT ag.name AS [AG Name], ar.replica_server_name, ars.connected_state_desc, ars.synchronization_health_desc FROM sys.availability_groups ag JOIN sys.availability_replicas ar ON ag.group_id ar.group_id JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id ars.replica_id;6. 测试故障转移为了验证我们的高可用集群是否正常工作我们需要进行故障转移测试。最简单的方法是手动触发故障转移在SSMS中展开Always On可用性组右键你的可用性组选择故障转移选择backup服务器作为新的主副本完成故障转移向导观察应用程序是否能够无缝切换到新的主副本。你也可以尝试直接关闭主服务器看看集群是否能够自动故障转移。在实际测试中我发现连接字符串需要指向监听器地址192.168.1.204而不是具体的服务器地址这样才能实现透明的故障转移。示例连接字符串如下Data Source192.168.1.204;Initial CatalogMyDemo;User IDsa;PasswordYourPassword;7. 性能优化与监控部署完成后我们需要对集群进行优化和监控。以下是一些实用的优化建议配置适当的同步提交模式。对于要求高可用性的场景使用同步提交对于跨地域的副本可以使用异步提交以提高性能。监控可用性组健康状况。可以创建以下查询来监控延迟SELECT ag.name AS ag_name, ar.replica_server_name, db_name(drs.database_id) AS database_name, drs.synchronization_state_desc, drs.log_send_queue_size, drs.redo_queue_size FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_replicas ar ON drs.replica_id ar.replica_id JOIN sys.availability_groups ag ON ar.group_id ag.group_id;配置适当的备份策略。可以利用次要副本来分担备份负载-- 在次要副本上执行备份 BACKUP DATABASE MyDemo TO DISK C:\Backup\MyDemo.bak WITH COPY_ONLY;定期测试故障转移流程确保在真正需要时能够正常工作。我建议至少每季度进行一次完整的故障转移测试。8. 常见问题排查在实际部署过程中可能会遇到各种问题。以下是一些常见问题及其解决方法证书认证失败确保两台服务器上的证书已正确交换并且SQL Server服务账户有权限访问证书文件。可以通过以下命令检查端点状态SELECT * FROM sys.database_mirroring_endpoints;同步延迟大如果发现次要副本的redo队列持续增长可能是网络带宽不足或次要副本I/O性能不足。考虑优化网络或升级存储。故障转移不自动触发检查集群仲裁配置和节点投票设置。确保至少有一个节点拥有投票权并且见证配置正确。监听器连接问题确保监听器IP在所有节点上都能正确响应。可以使用以下命令测试Test-NetConnection 192.168.1.204 -Port 1433数据库无法添加到可用性组确保数据库处于完整恢复模式并且已执行完整备份ALTER DATABASE MyDemo SET RECOVERY FULL; BACKUP DATABASE MyDemo TO DISK C:\Backup\MyDemo.bak;记住每次修改集群配置后都应该进行完整的测试包括手动故障转移和模拟节点故障以确保系统在真实故障时能够按预期工作。
Windows Server 2019 无域环境下的SQL Server 2019 Always On 高可用集群实战部署
发布时间:2026/7/14 10:13:34
1. 环境准备与基础配置在开始部署SQL Server 2019 Always On高可用集群之前我们需要先准备好基础环境。这里我们使用两台运行Windows Server 2019 Datacenter的服务器分别命名为master和backup。这两台服务器将组成我们的高可用集群。首先我们需要为两台服务器配置网络环境。每台服务器都需要配置静态IP地址并确保它们位于同一子网内。以下是推荐的IP配置方案master服务器192.168.1.201backup服务器192.168.1.202集群虚拟IP192.168.1.203监听器虚拟IP192.168.1.204接下来我们需要修改每台服务器的hosts文件添加以下条目192.168.1.201 master.xx.com 192.168.1.202 backup.xx.com 192.168.1.203 MyCluster.xx.com 192.168.1.204 mk-SQL在实际操作中我发现关闭防火墙可以避免很多连接问题。虽然生产环境中不建议完全关闭防火墙但在测试环境中可以暂时禁用防火墙以便于调试。在两台服务器上执行以下PowerShell命令Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False2. 配置故障转移集群配置故障转移集群是整个部署过程中最关键的一步。我们需要在两台服务器上安装故障转移集群功能。可以通过PowerShell快速完成安装Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools安装完成后我们需要验证集群配置。在一台服务器上运行以下命令Test-Cluster -Node master.xx.com,backup.xx.com如果验证通过就可以创建集群了。创建集群时需要注意几个关键点集群名称建议使用有意义的名称如MyCluster管理访问点IP填写我们预留的集群虚拟IP192.168.1.203确保选择正确的存储设备如果有创建集群的PowerShell命令如下New-Cluster -Name MyCluster -Node master.xx.com,backup.xx.com -StaticAddress 192.168.1.203创建完成后可以通过故障转移集群管理器验证集群状态。我曾经遇到过集群创建成功但节点状态异常的情况这时候通常需要检查网络连接和防火墙设置。3. 安装SQL Server 2019在两台服务器上安装SQL Server 2019企业版时有几个关键点需要注意安装功能建议全选但可以排除机器学习服务以减少资源占用身份验证模式选择混合模式并设置强密码的sa账户数据目录建议使用非系统盘如果有确保两台服务器的安装选项完全一致安装完成后我们需要启用Always On功能。这可以通过SQL Server配置管理器完成打开SQL Server配置管理器右键SQL Server服务选择属性切换到Always On可用性组选项卡勾选启用Always On可用性组重启SQL Server服务我曾经遇到过启用Always On后服务无法启动的问题这通常是因为SQL Server服务账户没有足够的权限。解决方法是为服务账户授予锁定内存页和以服务身份登录权限。4. 配置证书认证在无域环境中我们需要使用证书来替代域认证。首先在两台服务器上创建共享文件夹如C:\gdmk并设置Everyone有读写权限。在主服务器master上执行以下T-SQL命令创建证书USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD YourStrongPassword123!; CREATE CERTIFICATE CERT1 WITH SUBJECT CERT1, START_DATE 2023-01-01, EXPIRY_DATE 2099-12-30; BACKUP CERTIFICATE CERT1 TO FILE C:\gdmk\CERT1.cer; CREATE ENDPOINT [group0_endpoint] AUTHORIZATION [sa] STATESTARTED AS TCP (LISTENER_PORT 5022, LISTENER_IP ALL) FOR DATA_MIRRORING (ROLE ALL, AUTHENTICATION CERTIFICATE CERT1, ENCRYPTION REQUIRED ALGORITHM AES); GO在备份服务器backup上执行类似的命令但要使用不同的证书名称USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD YourStrongPassword123!; CREATE CERTIFICATE CERT2 WITH SUBJECT CERT2, START_DATE 2023-01-01, EXPIRY_DATE 2099-12-30; BACKUP CERTIFICATE CERT2 TO FILE C:\gdmk\CERT2.cer; CREATE ENDPOINT [group0_endpoint] AUTHORIZATION [sa] STATESTARTED AS TCP (LISTENER_PORT 5022, LISTENER_IP ALL) FOR DATA_MIRRORING (ROLE ALL, AUTHENTICATION CERTIFICATE CERT2, ENCRYPTION REQUIRED ALGORITHM AES); GO证书创建完成后需要将证书文件互相拷贝到对方的共享文件夹中然后在每台服务器上导入对方的证书-- 在master服务器上执行 CREATE CERTIFICATE CERT2 FROM FILE C:\gdmk\CERT2.cer; -- 在backup服务器上执行 CREATE CERTIFICATE CERT1 FROM FILE C:\gdmk\CERT1.cer;5. 创建可用性组现在我们可以创建可用性组了。首先在主服务器上创建一个测试数据库CREATE DATABASE MyDemo; GO USE MyDemo; GO CREATE TABLE Product (ID INT PRIMARY KEY, Name NVARCHAR(50)); GO -- 执行完整备份 BACKUP DATABASE MyDemo TO DISK C:\gdmk\MyDemo.bak WITH INIT; GO然后通过SSMS的可用性组向导创建可用性组连接到主服务器右键Always On可用性组选择新建可用性组向导指定可用性组名称如AG1选择刚才创建的MyDemo数据库指定副本添加backup服务器作为次要副本配置监听器使用我们预留的监听器IP192.168.1.204选择完全初始数据同步创建完成后可以通过以下命令验证可用性组状态SELECT ag.name AS [AG Name], ar.replica_server_name, ars.connected_state_desc, ars.synchronization_health_desc FROM sys.availability_groups ag JOIN sys.availability_replicas ar ON ag.group_id ar.group_id JOIN sys.dm_hadr_availability_replica_states ars ON ar.replica_id ars.replica_id;6. 测试故障转移为了验证我们的高可用集群是否正常工作我们需要进行故障转移测试。最简单的方法是手动触发故障转移在SSMS中展开Always On可用性组右键你的可用性组选择故障转移选择backup服务器作为新的主副本完成故障转移向导观察应用程序是否能够无缝切换到新的主副本。你也可以尝试直接关闭主服务器看看集群是否能够自动故障转移。在实际测试中我发现连接字符串需要指向监听器地址192.168.1.204而不是具体的服务器地址这样才能实现透明的故障转移。示例连接字符串如下Data Source192.168.1.204;Initial CatalogMyDemo;User IDsa;PasswordYourPassword;7. 性能优化与监控部署完成后我们需要对集群进行优化和监控。以下是一些实用的优化建议配置适当的同步提交模式。对于要求高可用性的场景使用同步提交对于跨地域的副本可以使用异步提交以提高性能。监控可用性组健康状况。可以创建以下查询来监控延迟SELECT ag.name AS ag_name, ar.replica_server_name, db_name(drs.database_id) AS database_name, drs.synchronization_state_desc, drs.log_send_queue_size, drs.redo_queue_size FROM sys.dm_hadr_database_replica_states drs JOIN sys.availability_replicas ar ON drs.replica_id ar.replica_id JOIN sys.availability_groups ag ON ar.group_id ag.group_id;配置适当的备份策略。可以利用次要副本来分担备份负载-- 在次要副本上执行备份 BACKUP DATABASE MyDemo TO DISK C:\Backup\MyDemo.bak WITH COPY_ONLY;定期测试故障转移流程确保在真正需要时能够正常工作。我建议至少每季度进行一次完整的故障转移测试。8. 常见问题排查在实际部署过程中可能会遇到各种问题。以下是一些常见问题及其解决方法证书认证失败确保两台服务器上的证书已正确交换并且SQL Server服务账户有权限访问证书文件。可以通过以下命令检查端点状态SELECT * FROM sys.database_mirroring_endpoints;同步延迟大如果发现次要副本的redo队列持续增长可能是网络带宽不足或次要副本I/O性能不足。考虑优化网络或升级存储。故障转移不自动触发检查集群仲裁配置和节点投票设置。确保至少有一个节点拥有投票权并且见证配置正确。监听器连接问题确保监听器IP在所有节点上都能正确响应。可以使用以下命令测试Test-NetConnection 192.168.1.204 -Port 1433数据库无法添加到可用性组确保数据库处于完整恢复模式并且已执行完整备份ALTER DATABASE MyDemo SET RECOVERY FULL; BACKUP DATABASE MyDemo TO DISK C:\Backup\MyDemo.bak;记住每次修改集群配置后都应该进行完整的测试包括手动故障转移和模拟节点故障以确保系统在真实故障时能够按预期工作。