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 回答