企业官网建设流程全解析

公司没有域控，SQL Server却想上AlwaysOn，这在几年前基本是个伪需求——AlwaysOn可用性组必须跑在Windows故障转移集群上，而故障转移集群又强依赖Active Directory。但SQL Server 2016推出后，无域AlwaysOn这条路直接被微软铺平了，我也在不少没有专职IT的中小环境里实操过好几轮，今天就把完整方案、核心原理和我踩过的坑一次说清楚。

无域AlwaysOn能帮你解决什么？说白了，就是让两台SQL Server没有域账户也能组成高可用集群，故障自动切换、同步提交、只读副本全部保留。它适合两类人：一类是公司压根不打算上域控、但业务又要求数据库不能挂的；另一类是测试、开发、边缘生产环境，想低成本体验AlwaysOn又不想引入一套AD基础设施的。只要操作系统是Windows Server 2016以上、SQL Server是2016以上，这条路基本都能走通。

1. 项目概述：无域AlwaysOn到底解决了什么问题

1.1 先搞清楚无域AlwaysOn是什么

简单说，无域AlwaysOn就是在没有Active Directory域控制器的工作组环境里，把SQL Server可用性组（AlwaysOn Availability Group）跑起来。可用性组的底层承载是WSFC（Windows Server Failover Clustering），也就是Windows故障转移集群。传统的WSFC要求在域环境里运行，节点之间的身份认证走Kerberos，集群名称对象（CNO）需要预先在AD里创建，各种资源也需要AD来管理。

但问题是，不是所有公司都有域控。我接触到的很多中小客户，IT团队就一两个人，甚至连专门的服务器管理员都没有。让他们搭域控、配DNS、管理组策略，难度和工作量都很大。可数据库高可用的需求非常明确：数据库一旦崩溃，业务就停摆。所以微软在SQL Server 2016里正式支持了无域（工作组）环境下的可用性组部署，核心思路是把节点之间的身份认证从Kerberos换成证书，同时把集群的管理方式调整成适配工作组环境。

注意，无域AlwaysOn不是不受限制。数据同步机制和标准AlwaysOn完全一致，同步模式、自动故障转移、只读路由这些功能都在。区别主要在于：你少了一整套AD基础设施，但相应的，得多花心思处理证书、主机名解析、防火墙这些原本由AD顺带解决的问题。

1.2 无域方案与标准域方案的对比

很多刚接触这个方案的人会担心，无域是不是"阉割版"。我做过对比测试，核心功能没有差异，但部署路径完全不同。

从表里可以看出，无域方案最麻烦的地方集中在三块：证书体系、DNS解析、仲裁配置。这三块也是后面实操里的重头戏。

1.3 版本要求与适用边界

如果你正在规划项目，先确认环境满足这些要求：

• 操作系统：Windows Server 2016或更高版本（2012 R2也能跑，但坑更多，不推荐）
• SQL Server版本：2016及以上（Enterprise和Developer版本都支持；Standard版从2016 SP1开始支持基本AG功能，但有限制，完整能力建议用Enterprise）
• 服务器数量：至少2台，生产建议至少3节点或者2节点+文件共享见证
• 数据库要求：参与AG的库必须开启完整恢复模式

适用场景说白了就两类：一类是"真没有域控也不想上域控"的中小型生产环境；另一类是开发测试环境，想快速搭出高可用架构用来验证代码、做故障演练。如果你的公司已经有成熟的AD域环境、有专职IT团队，那肯定还是走标准域方案更省心。

2. 无域环境的核心原理：证书认证与集群工作机制

2.1 没有活动目录，服务器之间靠什么互认

这是无域AlwaysOn和新手之间最大的认知门槛。要理解这个问题，先得想明白标准环境里AD到底干了什么。

在域环境里，当Node1想和Node2通信，Node1向域控申请一张Kerberos票据，域控确认Node1的账号合法后发放票据，Node2收到并校验票据，通信就建立了。整个过程靠的是节点都有一个"域身份"。没有域控，就没有这个身份认证中心。

无域环境替代方案就是证书。证书的原理相当于每个节点自己写一张"身份证"，大家互相交换身份证，然后建立信任。具体机制如下：

• 每个节点用PowerShell生成一张自签名证书
• 所有节点把其他节点的公钥证书导入到"受信任的根证书颁发机构"存储
• 节点间通信时，用证书对通信内容做签名和加密

这样证书就扮演了"迷你域控"的角色——它不验证账号，只验证"你就是你声明的那个节点"。

2.2 集群层证书和SQL端点证书的区分

很多人在实操中会蒙圈，因为证书涉及两个层面：一个是Windows集群层用的证书，另一个是SQL Server数据库镜像端点（Database Mirroring Endpoint）用的证书。

集群层的证书用于节点之间建立WSFC的通信信任；SQL Server端点证书用于可用性组内部的数据同步通道。二者的用途不同、生成方式不同、存储位置也不同。

我见过有人只配置了集群证书，结果在创建可用性组时端点连接失败，折腾半天才发现是SQL端点证书没做。实际操作时，两套证书都要准备。好消息是，集群证书和端点证书可以复用同一张自签名证书，也可以分别生成，看你的管理习惯。我个人建议分开生成，各自维护生命周期，避免后续换证时互相影响。

2.3 无域集群中的"分布式网络名称"机制

标准集群里有一个"集群名称对象"（CNO），它是在AD中注册的计算机对象，由集群服务维护，用于向客户端提供统一的访问入口。无域环境没有AD，微软引入了"DCO"（Distributed Network Name）概念来替代。DCO其实就是集群网络名称资源，当你在无域环境创建集群时，DCO会自己尝试在DNS中注册A记录。

这里有一个很关键的点：无域集群创建后，如果DNS没有正确配置（很多工作组环境根本没有DNS服务器），DCO注册会失败，并报一个警告。很多新手看到这个警告以为集群完蛋了，其实只要Cluster IP能正确绑定、集群资源能上线，这个警告可以忽略。后续配合hosts文件维护名称解析即可。

2.4 数据同步机制—这部分和域环境完全一致

说完认证，再简单提一下数据同步。AlwaysOn可用性组的同步机制和无域/有域无关，它走的是SQL Server日志块级别（Log Block）同步。主副本产生日志后，会通过数据库镜像端点将日志块推送给辅助副本，辅助副本直接重放日志。同步提交模式下，主副本要等辅助副本确认接收并持久化日志后，才提交事务；异步提交模式则不用等。

理解这一点对后续定位问题很有帮助。比如状态显示"不同步"时，第一反应应该是检查端点连通性、证书配置、日志磁盘空间，而不是怀疑集群问题。数据同步本身不依赖AD，但端点认证依赖证书，证书一断，同步就断了。

3. 实操准备：环境配置与证书体系构建

3.1 服务器软硬件配置清单

这部分建议直接照抄配置单，千万别在这些基础项上省事，否则后续集群验证会让你欲仙欲死。

老生常谈但必须提醒：参与AG的所有SQL Server实例必须保持相同的主版本、补丁级别和排序规则。字符集或者排序规则不一致，创建可用性组的时候可能直接给你报错。

3.2 主机名解析与hosts文件处理

工作组环境最大的痛点是名称解析不稳定。默认工作组用NetBIOS解析（通过广播），跨子网或防火墙稍微一挡，解析就失败。而SQL Server AG的所有配置都是用主机名来定义端点的，如果解析不了，一切白搭。

我的建议很简单粗暴：在每台节点上，把对方节点、集群名称、监听器名称全部手工写到hosts文件里。这个方法土，但是在无域环境绝对可靠。

hosts文件位置是C:\Windows\System32\drivers\etc\hosts，内容示例如下：

192.168.10.11 sql-node1 192.168.10.12 sql-node2 192.168.10.20 ag-cluster 192.168.10.30 ag-listener

注意，每个节点上都要写完整的四行，不能只写对方。这样无论节点之间通信、客户端连接监听器，都不依赖任何外部DNS。

我的经验：在无域环境里，把hosts配置做扎实，能减少七成莫名其妙的连接超时问题。别嫌麻烦。

3.3 防火墙端口规划

无域环境没有AD提供的防火墙规则，需要手工放行。端口选择直接决定后续成败。以下是必开端口清单：

如果你为SQL Server配置了非默认端口，记得替换1433为实际端口。另外，防火墙规则建议作用域限定在AG节点所在的子网，不要对所有网络开放。

建议在每台节点上用同一套防火墙规则，确保从任一节点都能访问其他节点的所有端口。设置完成后可以用PowerShell快速验证端口连通性：

Test-NetConnection -ComputerName sql-node2 -Port 5022

3.4 用PowerShell生成并交换节点证书

准备工作中最核心的就是证书。证书生成和交换这一步做错，后面集群创建基本直接失败。

我会在4.2里用完整的PowerShell命令演示集群证书的做法，这里先讲清楚交换证书的机制。每位节点在本地机证书库（LocalMachine\My）里放自己的证书，然后把证书的公开部分导入到其他人的"受信任的根证书颁发机构"（LocalMachine\Root）。这样每个节点都能验证其他节点的身份。

证书命名建议规范化，比如：

• 集群证书：CN=AGClusterCert-Node1、CN=AGClusterCert-Node2
• SQL端点证书：CN=SQLHADR-Node1、CN=SQLHADR-Node2

证书有效期建议5年起，别弄3个月一换，无域环境重新分发证书的运维成本很高。你也不想生产库跑着跑着突然因为证书过期无法做故障转移吧。

4. 核心步骤：从创建集群到可用性组上线

4.1 整体操作流程梳理

无域AlwaysOn的搭建不是一步到位的，我把全部步骤拆成了五个阶段，每个阶段之间都有明确的验证条件，方便你在中途及时发现问题：

1. 基础环境准备：系统配置、hosts、防火墙、时间同步
2. 证书体系构建：节点证书生成与交换
3. 故障转移集群创建：创建WSFC集群并添加节点
4. SQL Server配置：启用AlwaysOn、创建端点、创建可用性组
5. 验证测试：故障转移演练、连接测试

接下来我按实际执行顺序走一遍，每一步都给命令和解释。

4.2 创建无域Windows故障转移集群（含证书交换）

第一步：在每台节点上生成自签名证书

以Node1为例，打开管理员权限的PowerShell，执行：

# 创建证书（有效期5年） New-SelfSignedCertificate ` -DnsName "AGClusterCert-Node1" ` -CertStoreLocation Cert:\LocalMachine\My ` -KeyAlgorithm RSA ` -KeyLength 2048 ` -NotAfter (Get-Date).AddYears(5)

执行后在证书管理器里确认生成了对应证书。Node2执行同样的命令，把DnsName里的Node1换成Node2。

第二步：导出证书

把每台节点的证书导出成.cer文件，后续分发到其他节点：

# 在Node1上导出 $cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.DnsNameList -like "*AGClusterCert-Node1" } Export-Certificate -Cert $cert -FilePath "C:\Certs\Node1.cer" # 在Node2上导出 $cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.DnsNameList -like "*AGClusterCert-Node2" } Export-Certificate -Cert $cert -FilePath "C:\Certs\Node2.cer"

第三步：互相导入对方证书

Node1上导入Node2的证书到受信任根：

Import-Certificate -FilePath "C:\Certs\Node2.cer" -CertStoreLocation Cert:\LocalMachine\Root

Node2上导入Node1的证书：

Import-Certificate -FilePath "C:\Certs\Node1.cer" -CertStoreLocation Cert:\LocalMachine\Root

这里有一个关键点，证书导入位置一定是LocalMachine\Root，不是LocalMachine\TrustedPeople，也不是LocalMachine\CA。位置错了，集群验证的时候会报无法建立信任关系。

第四步：创建工作组集群

证书交换完成后，在任一节点上创建集群：

New-Cluster ` -Name "AGCluster" ` -Node "sql-node1","sql-node2" ` -NoStorage ` -StaticAddress "192.168.10.20"

这个命令会在工作组模式下创建集群，NoStorage表示暂不添加共享存储（AG本来就不需要），StaticAddress是给集群名称分配一个VIP。

集群创建完成后，把另一方节点加进来（如果New-Cluster时已经指定了全部节点，这步可以跳过；如果是先创建单节点，再用Add-ClusterNode）：

Add-ClusterNode -Cluster "AGCluster" -Name "sql-node2"

第五步：验证集群状态

创建完成后，用以下命令检查集群当前状态：

Get-Cluster -Name "AGCluster" | Format-List Get-ClusterNode -Cluster "AGCluster"

Get-ClusterNode的输出中，每个节点的State应该是Up。如果某个节点显示Down，优先排查证书信任和防火墙端口。另外，运行Test-Cluster验证向导时不要慌，无域环境下不少检查项会返回警告或失败，比如"Active Directory"相关测试一定会失败，这是正常的，重点只看集群服务和节点状态。

第六步：配置文件共享见证

无域集群强烈建议配置见证，否则两个节点之间发生网络分区时，无法确定谁持有法定数量，集群就会停摆。文件共享见证是最通用的方案。

准备一个共享文件夹（可以用第三方轻量NAS或一台Windows服务器），共享名如AGWitness，设置权限允许节点计算机账户有读写权限。

然后在集群上设置：

Set-ClusterQuorum -Cluster "AGCluster" ` -FileShareWitness "\\witness-server\AGWitness"

配置后检查：

Get-ClusterQuorum -Cluster "AGCluster"

这里有一个无域环境特别要注意的：文件共享见证服务器的名称解析也必须可靠。如果见证服务器和工作组节点间存在名称解析问题，直接在测试机器的hosts里加上见证服务器的映射，别犹豫。

4.3 配置SQL Server服务并启用AlwaysOn

集群就绪后，进入SQL Server层面。

首先确保每台节点上的SQL Server服务账户是一个本地账户，并且两台节点的这个账户用户名和密码必须完全相同。比如在Node1和Node2上都创建名为sqlagent的本地用户，密码设置成一样的。这样节点故障转移后，新主节点上用相同密码启动SQL Server服务才不会有问题。

启用AlwaysOn：打开SQL Server配置管理器，点击SQL Server服务，右键实例选择属性，切到AlwaysOn高可用性选项卡，勾选"启用AlwaysOn可用性组"，重启服务。两个节点都要操作。

启用后可以用T-SQL确认：

SELECT servicename, is_hadr_enabled FROM sys.dm_server_services WHERE servicename LIKE 'MSSQL%';

返回is_hadr_enabled = 1就对了。

4.4 创建数据库镜像端点并绑定证书

这一步是无域AlwaysOn的数据同步基础。SQL Server通过数据库镜像端点（默认端口5022）来传输日志块。前面说过，SQL Server端点的认证方式是证书，所以这里要用T-SQL来创建证书并挂到端点上。

Node1上执行：

USE master; GO -- 创建主密钥（每个实例一个） CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeyP@ssw0rd_2024'; GO -- 创建端点证书 CREATE CERTIFICATE SQL_HADR_Cert_Node1 WITH SUBJECT = 'SQL_HADR_Cert_Node1', START_DATE = '01/01/2024', EXPIRY_DATE = '01/01/2029'; GO -- 备份证书和私钥 BACKUP CERTIFICATE SQL_HADR_Cert_Node1 TO FILE = 'C:\Certs\SQL_HADR_Cert_Node1.cer' WITH PRIVATE KEY ( FILE = 'C:\Certs\SQL_HADR_Cert_Node1.pvk', ENCRYPTION BY PASSWORD = 'Kev@2024_Private' ); GO

Node2上执行类似命令，证书名字和文件名换成Node2。

然后把证书文件拷贝到对端节点。在Node2上创建Node1的证书：

USE master; GO CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MasterKeyP@ssw0rd_2024'; GO CREATE CERTIFICATE SQL_HADR_Cert_Node1 FROM FILE = 'C:\Certs\SQL_HADR_Cert_Node1.cer' WITH PRIVATE KEY ( FILE = 'C:\Certs\SQL_HADR_Cert_Node1.pvk', DECRYPTION BY PASSWORD = 'Kev@2024_Private', ENCRYPTION BY PASSWORD = 'Kev@2024_Private' ); GO

在Node1上同样反向创建Node2的证书。

证书就位后，创建端点：

-- Node1 CREATE ENDPOINT [AG_Endpoint] STATE = STARTED AS TCP ( LISTENER_PORT = 5022, LISTENER_IP = ALL ) FOR DATABASE_MIRRORING ( AUTHENTICATION = CERTIFICATE SQL_HADR_Cert_Node1, ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES ); GO

Node2执行同样命令，证书名换成SQL_HADR_Cert_Node2。端点的ROLE要设成ALL，表示既能当主也能当辅助副本，这样后续故障转移时不用来回改端点权限。

检查端点状态：

SELECT endpoint_id, name, state_desc FROM sys.database_mirroring_endpoints;

state_desc必须是STARTED。

4.5 创建可用性组并加入辅助副本

准备数据库：完整备份

AG要求参与同步的数据库必须是完整恢复模式，并且至少做过一次完整备份。否则创建时会把数据文件状态不符的库直接拒绝。

ALTER DATABASE YourDB SET RECOVERY FULL; GO BACKUP DATABASE YourDB TO DISK = 'C:\Backup\YourDB_Full.bak' WITH INIT;

在Node1上创建可用性组

CREATE AVAILABILITY GROUP [AGTest] WITH ( AUTOMATIC_FAILOVER = ON, DB_FAILOVER = ON, FAILURE_CONDITION_LEVEL = 2, HEALTH_CHECK_TIMEOUT = 30000 ) FOR DATABASE [YourDB] REPLICA ON N'sql-node1' WITH ( ENDPOINT_URL = N'TCP://sql-node1:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC, BACKUP_PRIORITY = 50, PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE), SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) ), REPLICA ON N'sql-node2' WITH ( ENDPOINT_URL = N'TCP://sql-node2:5022', AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, FAILOVER_MODE = AUTOMATIC, SEEDING_MODE = AUTOMATIC, BACKUP_PRIORITY = 50, PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE), SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) ) WITH (LISTENER_URL = N'TCP://ag-listener:1433');

我解释一下几个关键选择：

• AVAILABILITY_MODE = SYNCHRONOUS_COMMIT：同步提交，保证主备数据强一致，也是自动故障转移的前提
• FAILOVER_MODE = AUTOMATIC：自动故障转移，两台节点都在线才可用
• SEEDING_MODE = AUTOMATIC：自动初始化，辅助副本会自动从主副本拉取全量备份，省去手动还原
• FAILURE_CONDITION_LEVEL = 2：默认值，SQL Server大概30秒检测不到健康就触发故障转移

创建成功后，Node2作为辅助副本会自动加入。但注意，Node2上的数据库副本默认是RESTORING状态，这个不要惊慌，这是正常的。

在Node2上加入可用性组

如果辅助副本没有自动加入（比如网络问题），在Node2上手动执行：

ALTER AVAILABILITY GROUP [AGTest] JOIN; GO ALTER AVAILABILITY GROUP [AGTest] GRANT CREATE ANY DATABASE;

GRANT CREATE ANY DATABASE这一句是自动种子初始化（automatic seeding）所需要的权限，不加的话同步不会启动。

配置监听器

可用性组监听器给客户端提供一个统一入口，无论主副本切到哪台节点，连接串不变。无域环境需要手工指定IP：

ALTER AVAILABILITY GROUP [AGTest] ADD LISTENER 'ag-listener' ( WITH IP (('192.168.10.30', '255.255.255.0')), PORT = 1433 );

监听器创建后，确认状态：

SELECT * FROM sys.dm_tcp_listener_states;

然后记得在所有客户端机器的hosts文件里加上：

192.168.10.30 ag-listener

否则客户端解析不了监听器名称，连接延时和失败的概率会很高。

检查副本同步状态：

SELECT replica_server_name, synchronization_state_desc, synchronization_health_desc FROM sys.dm_hadr_database_replica_states;

SYNCHRONIZED和HEALTHY就是我希望看到的结果。

4.6 启动自动种子同步前的要点

当使用SEEDING_MODE = AUTOMATIC时，Node2会直接从Node1拉取全量备份并恢复，这个环节容易在恢复阶段卡住。我在实践中遇到自动种子失败的情况，排查方向主要看SQL Server错误日志中是否有"failed to start automatic seeding"之类的报错。

自动种子初始化失败后，可以先手动做一个还原：

-- Node2上执行，将Node1的完整备份和日志备份还原到临时状态 RESTORE DATABASE [YourDB] FROM DISK = 'C:\Backup\YourDB_Full.bak' WITH NORECOVERY;

然后把种子模式改回手动，再在Node2上加入：

ALTER AVAILABILITY GROUP [AGTest] ADD DATABASE [YourDB];

这样数据链路会从当前差异点继续同步，能少走弯路。自动种子模式确实方便，但在网络不稳或防火墙策略较严的环境里，手动还原有时反而更可靠。

5. 验证测试与常见问题排查

5.1 故障自动切换与数据一致性验证

所有配置完成后，做一次完整的故障切换演练，确认故障转移真的能用。

方法一：任务管理器层重启SQL Server服务。这一步模拟的是实例级故障，重启后观察主副本是否自动切到备用节点。

Restart-Service -Name 'MSSQLSERVER' -Force -ComputerName sql-node1

方法二：使用T-SQL强制故障转移。

ALTER AVAILABILITY GROUP [AGTest] FAILOVER;

切换完成后检查：

SELECT role_desc FROM sys.dm_hadr_availability_group_states;

验证当前角色是否变为PRIMARY。然后从客户端用监听器连接，执行插入、查询，确认数据一致。

切换后建议再切回来一次，确保双向都能转。我在实际工作里见的故障转移失败案例，大多是第一次切换没问题，但切回去的时候卡住了，究其原因经常是辅助副本上还有活动连接，或者会话持有数据库锁。故障转移前先杀掉对辅助副本的只读连接，成功率会高很多。

5.2 高频故障现象与排查方法速查表

5.3 无域AlwaysOn日常维护与监控要点

无域环境维护的核心：证书到期时间必须纳入监控，这是AV方案里最大的"定时炸弹"。证书一旦过期，节点间通信会瞬间断开，所有副本进入"不同步"状态，故障转移能力直接归零。建议在证书快到期前完成换证流程：

# 列出所有节点上即将过期的证书 Get-ChildItem Cert:\LocalMachine\My | Select-Object DnsNameList, NotAfter

另外，每季度跑一次故障转移演练。无域环境配置变更频繁，hosts、防火墙、服务账户密码都可能导致悄无声息的状态退化。演练能第一时间暴露隐藏问题。

监控指标方面，除了常规的同步状态，重点关注：

• sys.dm_hadr_database_replica_states中的同步健康状态
• 日志发送队列长度（log_send_queue_size）和日志重做队列（redo_queue_size）
• 集群核心事件日志（事件ID 1135、1593）

5.4 卸载/重建可用性组时的小技巧

测试环境经常要把AG拆掉重新搭。删除顺序很重要，顺序错了会残留脏对象。

正确顺序：

-- 1. 先从主副本删除可用性组 DROP AVAILABILITY GROUP [AGTest]; GO -- 2. 然后在每个副本上把数据库恢复到独立状态 ALTER DATABASE [YourDB] SET HADR OFF; GO RESTORE DATABASE [YourDB] WITH RECOVERY;

如果直接在主副本DROP了AG而没在辅助副本上做SET HADR OFF，辅助副本的数据库会卡在还原状态，这时候恢复会比较费劲。我的习惯是：能不用脚本重建就尽量在图形界面里手动删除，多花两分钟但干净利索。

最后再分享一点个人体会

无域AlwaysOn这套方案，技术上完全可行，但它的价值边界取决于你对证书和名称解析这些基础工作的投入程度。有域环境下AD帮你扛了太多事情，无域环境把这些负担交还给你，这是好事也是坏事——好在逼你弄懂底层机制，每次排障都能定位到具体的信任链、端口、解析环节；坏在没有捷径，每套环境都得老老实实把基础做好。

我做过的无域AG部署里，凡是后面出过大问题的，几乎都栽在同样几个地方：证书过期没监控、hosts配置不齐全、见证服务器没有在hosts里加映射、故障转移演练从没做过。反过来，基础工作做扎实的几套环境，跑了一两年都很稳。

如果你正打算在生产环境落地，我的建议是先在虚拟机上完整演练一遍这套流程，把证书生成、集群创建、AG创建、故障转移全部走通，再去动生产库。有了一套熟练的流程，上线操作心里才有底。