3

我为我的 .NET 程序创建了一个 Dockerfile。该程序在我的桌面和没有 Docker 的 Windows Server 2016 (Azure VM) 上运行良好。当我尝试将它作为容器（基于microsoft/windowsservercore）在内部运行时，连接到我的 Azure SQL 实例时经常会遇到数据库错误。

我有两个 Azure SQL 实例正在运行（P1 和无负载）。当可以建立连接时，它们非常快，但问题是通常无法建立连接。看起来网络很不稳定。这些是向我抛出的典型错误：

System.Data.SqlClient.SqlException：建立与 SQL Server 的连接时发生与网络相关或特定于实例的错误。服务器未找到或无法访问。验证实例名称是否正确以及 SQL Server 是否配置为允许远程连接。（提供者：命名管道提供者，错误：40 - 无法打开与 SQL Server 的连接）

内部异常报告The network path was not found。起初我以为它可能是我的本地机器，但它在 Azure 中的 Windows Server 2016（带有容器）VM 实例上也存在问题。

为了查明问题，我创建了一个测试程序，它每 5 秒（并运行一次SELECT COUNT(*) from sysobjects）连接到我的数据库。这个程序总是成功地找到数据库。

似乎我的其他程序在启动过程中经常失败，但在初始化过程中有很多数据库调用。我怀疑线程、连接池、......

任何人的线索？

4

2 回答 2

3

目前，我们还遇到了更多与 Windows Container 相关的网络问题。但是对于像您在 Azure/Containers 中使用的软件定义的网络，一般建议使用一些重试逻辑。

如果您使用的是实体框架，则可以插入不同的弹性和重试策略“SqlAzureExecutionStrategy”。这通常不仅适用于容器，而且有助于减少异常。

本文介绍了如何： https ://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx

于 2017-01-03T15:28:40.040 回答
2

错误消息来自Named Pipes Provider似乎很奇怪，因为 Azure SQL 只能通过 TCP/IP 连接。不知何故，它似​​乎回到了命名管道，这可以通过在主机名前加上tcp:. 所以，我的连接字符串看起来像：

Server=tcp:example.database.windows.net;Database=<dbname>;User Id=...

这可以防止服务器回退到尝试使用命名管道，我再也没有看到这个问题了。

不幸的是，我还没有找到在某些情况下使用命名管道提供程序的原因。应该是microsoft/windowsservercore镜像中的一些配置导致的，因为我从来没有看到过 Docker 镜像之外的错误信息。否则，我会怀疑 Azure SQL 的限制机制（尽管负载非常低）。

于 2017-01-03T14:25:04.620 回答