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

【问题标题】：SQL AlwaysOn - What if you don't use it as a cluster/failover?SQL AlwaysOn - 如果您不将它用作集群/故障转移怎么办？
【发布时间】：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。

标签： sql-server sql-server-2012 alwayson

【解决方案1】：

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

不过有几点需要考虑：

AlwaysOn 在主服务器上启用 READ_COMMITED_SNAPSHOT 隔离级别。这意味着 TEMPDB 的开销和每行更改时每行额外 14 个字节
在异步模式的情况下，辅助服务器上的数据新近度可以接近主服务器。
早于 SQL Server 2017 的版本需要 WSFC。

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

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

关于你的问题：

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

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

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

【讨论】：

是的 2017 / vnext ......如果他们在这我会非常震惊。但肯定是失败点。
但是这种情况是好的还是有风险的？有什么缺点吗？
@JosephMorin，补充了一些优点和缺点