在 ConnectionStrings 中为每个应用程序使用 DNS

Question

最近，当我不得不将大量内部应用程序迁移到新的 SQL 服务器时，我遇到了一个想法。我看的越多，它听起来就越完美，但我想向社区征求反馈意见。它使用 SQL0216 和 AlwaysOn。

告诉我的开发人员使用 DNS 条目在他们的 ConnectionStrings 中指向他们各自的数据库有什么缺点？

示例：DNS:App1_SQL 指向 Servr1，DNS:App2_SQL 指向 Servr1。服务器=App1_SQL；数据库=App1；Trusted_Connection=True；服务器=App2_SQL；数据库=App2；Trusted_Connection=True；

这样，当我迁移数据库时，我可以一次完成一个应用程序，确保在继续之前一切正常。无需重新编译代码，也无需处理任何配置文件。我只需要复制数据库并更新应用程序的 DNS 条目。

如果特定应用程序使用外部数据库引用，我会训练我的开发人员始终使用同义词。这样，我为旧数据库创建了一个链接服务器，并在迁移时相应地更新同义词。

除了必须一个一个地管理大量 DNS 条目之外，我仍然认为这是一种减轻与数据库迁移相关的压力的方法，能够通过小块而不是整个服务器一次性完成。

现在，我看不到的警告是什么？因为这听起来太容易和有益，而不是一个非常标准化的做法，但我从来没有遇到过这个建议。Kerberos 会成为问题吗？

提前致谢

Answer 1

告诉我的开发人员使用 DNS 条目在他们的 ConnectionStrings 中指向他们各自的数据库有什么缺点？

从技术上讲，现在的缺点之一是它们不会更改它们的连接字符串……比如说，它们何时应该添加特定于连接的关键字，例如MultiSubnetFailover.

您还将有大量的 DNS 项目需要监管，这听起来很容易——总的来说，确实如此。不过，我确实倾向于认为它会导致网络名称重复。

这样，当我迁移数据库时，我可以一次完成一个应用程序，确保在继续之前一切正常。无需重新编译代码，也无需处理任何配置文件。我只需要复制数据库并更新应用程序的 DNS 条目。

这实际上很常见，尤其是在使用大量 3rd 方应用程序的环境中，其中连接字符串信息未知或许可代码阻止重命名连接（呃）。

因为这听起来太容易和有益，而不是一个非常标准化的做法，但我从来没有遇到过这个建议。

看上面。由于这个原因，我认识的许多公司都有别名政策。这也是 AG 为侦听器工作的方式，因为它是网络层间接。

Kerberos 会成为问题吗？

如果您使用的是 CNAME，它只会指向实际的主机，因此您不会在那里遇到任何问题。如果您放入新的 A 记录，则会导致问题，您需要为新的 A 记录设置 SPN。否则，对于 CNAME，SPN 应该是主机的名称。