Rac*_*SQL 3 sql-server clustering failover availability-groups sql-server-2016
停止 SQL Server 服务时的行为：
可用性组失败（在 SECONDARY SQL SERVER 上解析并在集群管理上失败）。
SQL Server 不与集群 ip 连接（我在软件内部使用固定的集群 ip 以便它在 SQL1 和 SQL2 上x.x.x.10连接。使用应该在x.x.x.9（SQL1）和x.x.x.8（SQL2）上连接我，因为windows failover cluster.
right click > failover）。要按原样返回所有内容，我需要SQL1 SERVICE手动启动、连接SQL1 SSMS和right click > failover手动。停止集群管理上的 NODE2 服务，使其再次将 SQL1 节点变为主节点。
停止主集群节点时的行为：
可用性组转到 SQL2/NODE 2（辅助现在是主要的）。
主 AG 未解决...
SQL Server 与集群 ip 连接（我说的是 SSMS 。与 ipX.x.x.10连接x.x.x.8，在杀死节点x.x.x.9（ Primary ）后将我连接到辅助节点。
当我再次启动集群节点（主）时，它会自动返回 do SQL1（主）。连接x.x.x.10仍然将我与辅助节点连接起来。
如果我想再次使 SQL1 成为主要的，我需要重新**stop** node2 cluster service启动它。这样，SQL1（主）再次与集群 IP 连接为主。
这完全不是我认为我会自动拥有的。我认为如果 SQL Server 死机，所有连接都会自动转到辅助if the primary NODE is down服务器，但它只是故障转移（不是 sql server 服务）。然后要返回主服务器，我需要停止 SQL2 集群服务，因此主服务器再次成为主服务器。
有什么我想念的吗？
我们没有使用具有共享存储的故障转移群集。有 2 台服务器有自己的磁盘。
您在此设置中存在仲裁问题。集群中只有两个参与者：
如果 SQL1 出现故障，则 SQL2 无法知道它应该是主要的。就所有 SQL2 所知，网络已经瘫痪，SQL1 仍然作为主节点运行。因此，SQL2 进入 RESOLVING 状态（不确定要做什么）。这是为了防止“裂脑”场景。
对于双节点集群，一般需要在WSFC集群中添加一个File Share Witness作为资源。这将允许剩余的实例 SQL2 与 FSW 建立仲裁，并作为主实例接管。
此外，AG 的行为不会在“原始主节点”备份后立即自动故障回复到“原始主节点”。自动故障转移仅在当前主服务器中断的情况下使用，它不打算“自动故障恢复”。
请注意，您描述的另一个场景（停止主集群节点）并不是您希望 AG 进行故障转移的方式。 不要那样做：
不要使用故障转移群集管理器来操作可用性组，例如：
不要在可用性组的群集服务（资源组）中添加或删除资源。
不要更改任何可用性组属性，例如可能的所有者和首选所有者。这些属性由可用性组自动设置。
不要使用故障转移群集管理器将可用性组移动到不同的节点或故障转移可用性组。故障转移群集管理器不知道可用性副本的同步状态，这样做会导致停机时间延长。您必须使用 Transact-SQL 或 SQL Server Management Studio。