SQL AlwaysOn - 如果您不将它用作集群/故障转移怎么办？

Posted 2023-03-23

【中文标题】SQL AlwaysOn - 如果您不将它用作集群/故障转移怎么办？

【英文标题】：SQL AlwaysOn - What if you don't use it as a cluster/failover?

【发布时间】：2019-02-27 16:19:43

【问题描述】：

有人向我提出了一个概念，即使用两个使用 AlwaysOn 作为复制形式的 SQL 服务器。

主服务器接收所有数据，辅助服务器是报告源的只读服务器。

由于感觉提案是不确定的，因为没有关于配置这样的东西的信息，有人知道这是一个好主意还是坏主意？

添加注意：没有集群或 AG 侦听器。服务器是分组的，但可以直接访问和寻址。

【问题讨论】：

这正是我们使用 AlwaysOn 可用性组的方式，关于这个的各种文章都有吗？

所以每个服务器都指向特定的服务器而不是 AG 侦听器或集群角色？

这是一种进行日志传送或镜像恕我直言的昂贵方式。你是什​​么意思没有聚类？据我所知，it's a requirement 在 WSFC 中。

什么服务器？你的意思是连接字符串？标准读/写连接使用AG监听器，只读连接字符串也指向监听器但被ApplicationIntent重定向。

是的。这就是我期望的实施“应该”。但有人向我提出了一些不同的建议。 IE，据我了解，您可能有 2 个 SQL 服务器，分别是 SQL01 和 SQL02。您创建一个名为 SQLAG 的 AG 组和侦听器。您连接到 SQLAG，一切都会得到处理。我的建议是创建可用性组，而不是创建侦听器并直接连接到 SQL01 和 SQL02。

【参考方案1】：

从 SQL Server 2017 开始，不再需要集群或侦听器来为您的方案提供解决方案。

不过有几点需要考虑：

AlwaysOn 在主服务器上启用 READ_COMMITED_SNAPSHOT 隔离级别。这意味着 TEMPDB 的开销和每行更改时每行额外 14 个字节 在异步模式的情况下，辅助服务器上的数据新近度

可以

接近主服务器。 早于 SQL Server 2017 的版本需要 WSFC。

因此，与日志传送相比，AlwaysOn AG 可读辅助设备各有利弊：

优点： 无需中断连接，因为无需恢复日志 数据可以具有近乎实时的新近度 缺点： 仅限企业版 主副本上每个更改行的开销为 14 字节，因此考虑将填充因子从 100 更改为 90 以避免页面拆分开销 更难维护

关于你的问题：

有人知道这是个好主意还是坏主意？

AG 可读二级绝对值得 POC 试用，特别是如果您的公司需要技能/资源

（免责声明：本文基于我的个人观点）

【讨论】：

是的 2017 / vnext ......如果他们在这我会非常震惊。但肯定是失败点。

但是这种情况是好的还是有风险的？有什么缺点吗？

@JosephMorin，补充了一些优点和缺点