我们目前正在整合公司的本地 SQL 资产，我们已经构建了一组集群服务器，这些服务器将容纳多个 SQL Server 2019 实例。已经决定我们将使用 WSFC 为每个实例上的每个数据库设置基本可用性组。

最佳做法是将每个可用性组侦听器设置为拥有自己的 IP 地址，还是可以将其设置为一个实例中所有可用性组的所有侦听器都使用相同的 IP 地址但端口号不同？

举一个数字示例，我们构建了一个基于财务的 2 节点集群，其中包含 3 个实例，每个实例有 3-5 个数据库。这意味着最多需要 15 个 AG 和 15 个侦听器。

我们已经设置了一个 SQL Server 2019 Enterprise High Availability 集群，前面有一个可用性组侦听器 (AGL)。与我们进行手动/计划的故障转移相比，我们在测试自动（脏）故障转移时遇到了奇怪的（？）行为。最紧迫的问题是客户端何时在 Centos 7 上使用 Microsoft ODBC Driver 17.7 for SQL Server。但同样的情况也发生在 .net framework/core 上。

场景

手动/计划故障转移

测试

我们告诉 AG 将集群从主副本故障转移到辅助副本。

AG-行为

AG 故障转移到辅助副本。

客户行为

客户端立即与 AG 断开连接，ODBC 驱动器尝试重新连接，成功并且客户端可以继续工作。

自动/脏故障转移（不像我们预期的那样工作）

测试

我们断言客户端通过 AG 连接到主副本，然后拔下主副本机器上的插头（以模拟断电）。

AG-行为

AG 故障转移到辅助副本。

客户行为

客户端不会断开连接，而是继续等待响应，直到查询超时开始（这需要几分钟，太长了）。

问题

据我们了解，AG 应该在手动/计划和自动故障转移期间断开客户端的连接，但对我们来说，这只发生在手动/计划的故障转移期间。这是此解决方案的预期行为还是我们的 SQL Server/AG 配置有问题？

是否可以在可用性组的主副本上还原数据库备份，然后将其重新植入辅助副本而不复制备份文件？

最好我需要获取执行它的脚本（而不是 GUI）。

到目前为止，我正在这样做

1. 从 AG 中删除数据库
2. 在主数据库上恢复数据库
3. 将数据库添加到主数据库上的 AG

AG 设置为自动播种，但在将数据库添加到 AG 后没有发生播种。它应该如何工作？谢谢您的帮助！

我们有一个带有 10k 表 (4TB) 的生产数据库。它当前位于可用性组中，因此所有数据都流式传输到副本副本 - 主要是为了冗余。我们想用重要的表建立一个专用的数据仓库……建议清理 10k，但需要一段时间。

除了可用性组之外，是否可以使用“复制”将关键的 200 个表推送到数据仓库？关于该主题的 microsoft 文档让我认为他们正在使用与可用性组同义的复制。我的意思是您可以为单个表打开的那种复制......“事务性” - 我认为。

将仓库服务器添加到可用性组不是首选，因为 1. 并不真正需要大量数据 2. 我被告知我将无法在此副本副本上添加/更改索引（这对 DW 需求来说很好) 3. DW 有 12 个核心，AG 中的现有服务器有 28 个。 4. 我被告知如果我有权从 DW 副本读取，我将必须获得从主服务器读取的能力（似乎怀疑） - 他们不希望任何人拥有初级读权限。

客户在应用服务器 (SharePoint Foundation 2010) 上设置了 SharePoint，SharePoint 数据库位于 SQL Server 上，该 SQL Server 是具有三个副本的 AG 的一部分……我们称它们为 DB1、DB2 和 DB3。AG 侦听器名称为 SQLLive

最初设置 SharePoint 时，指定数据库服务器为 DB1。他们现在想要更改它，以便它使用侦听器 (SQLLive) 而不仅仅是直接指向 DB1。

我可以在 SharePoint 管理中心控制台中看到有一个选项可以指定默认数据库服务器的名称（管理中心 => 应用程序管理 => 指定默认数据库服务器）。是否只是将此处指定的值从 DB1 更改为 SQLLive 的情况？如果这样做时有人在使用 SharePoint，这会导致任何中断吗（即是否需要停机）？

谢谢

当我的应用程序尝试使用 AG 侦听器通过 JDBC 连接时，我收到以下错误。Multisubnetfailover=true已添加到连接字符串中，但仍无法正常工作。

与主机的 TCP/IP 连接，端口 1433 失败。错误：“侦听器”：名称或服务未知。验证连接属性。确保 SQL Server 实例正在主机上运行并在端口接受 TCP/IP 连接。

当应用程序尝试使用端口 1433 上的 IP 进行连接时，它正在工作。

这是连接字符串：

我对 AG 的了解非常有限，而且我不是 DBA。

我们有 4 台机器——每台机器都托管两个数据库，比如 DB1 和 DB2。DB1 有自己的 AG（比如 AG1），它被复制到其他 3 台机器上，DB2 也有自己的 AG（比如 AG2），它也被复制到相同的 3 台机器上。DB1 和 DB2 是写副本。其他 3 台机器具有只读副本。

现在如果机器 1 发生故障，通常会发生的情况是机器 1 上的 DB1 可以故障转移到机器 3上的 DB1 （并成为 WRITE 副本），而机器 1 上的 DB2 可以故障转移到机器 4上的 DB2 （并成为 WRITE 副本） ）。

问题 -

如果机器 1 出现故障，是否可以强制 sql server 将两个数据库（DB1 和 DB2）从机器 1 故障转移到同一台机器？意思是，我希望两个数据库的 WRITE 副本始终在一台机器上。谢谢！

我相信部分答案是，它连接到一个侦听器服务器，该服务器重定向到一个真实的数据库。

例如，一个连接字符串是

SQLCL01 是一个监听器，我猜它会路由到该组中的一个真实数据库，但是如果 SQLCL01 死了会发生什么？连接不会中断吗？如果那里存在单点故障，这将如何作为 HA 工作？

我知道有些数据库有 8 台服务器。他们是否担心 SQLCL01 的单个侦听器会宕机？或者我们是否设置了多个侦听器并可以在连接字符串中传递两个？

是否可以将 SQL 托管实例添加为 Azure IaaS 上托管的现有 SQL Always On 可用性组中的只读副本？我们永远不想故障转移到 MI，但希望将数据库复制到它，以便我们可以在那里查询。

我在 SQL Server 2019 中的可用性组上设置了事务复制。当任何事务在发布者/主副本上运行时，日志阅读器正在等待以下消息“复制事务正在等待下一个日志备份或镜像伙伴赶上”。

在主/发布者端完成 t-log 备份之前，日志阅读器无法发送事务。