Npgsql/EFCore.PG 中关于 DNS 解析失败的重试策略探讨

背景介绍

在使用 Npgsql 连接 PostgreSQL 数据库时，特别是在 Azure 云环境中，开发者可能会遇到 DNS 解析失败的异常情况。虽然这类错误通常被认为是永久性的，但在某些云服务场景下，Azure 支持团队确认这实际上是一种暂时性故障。

问题本质

当应用程序通过 Npgsql 连接到 PostgreSQL 数据库时，如果遇到 "No such host is known" (SocketException 11001) 错误，默认的重试策略不会生效。这是因为：

1. 该错误属于底层网络层的 DNS 解析失败
2. 传统上这类错误被视为永久性故障而非暂时性故障
3. 现有的 EnableRetryOnFailure() 方法主要针对 PostgreSQL 特定的错误代码

技术分析

Npgsql 的默认重试策略 NpgsqlRetryingExecutionStrategy 确实会将某些网络异常视为暂时性错误，包括：

• IOException
• SocketException
• TimeoutException
• 以及标记为暂时性的 NpgsqlException

然而，在 Azure 环境中，DNS 解析失败可能是由于 Azure DNS 服务的暂时性问题导致的，这种情况下确实应该进行重试。

解决方案

对于需要处理 DNS 解析失败重试的场景，开发者可以采取以下方案：

自定义执行策略

public class CustomRetryExecutionStrategy : NpgsqlRetryingExecutionStrategy
{
    public CustomRetryExecutionStrategy(ExecutionStrategyDependencies dependencies)
        : base(dependencies)
    {
    }

    protected override bool ShouldRetryOn(Exception exception)
    {
        if (exception is SocketException { SocketErrorCode: SocketError.HostNotFound })
        {
            return true;
        }
        return base.ShouldRetryOn(exception);
    }
}

然后在 DbContext 配置中使用：

optionsBuilder.UseNpgsql(connectionString)
    .UseExecutionStrategy(context => 
        new CustomRetryExecutionStrategy(context.GetService<ExecutionStrategyDependencies>()));

配置建议

1. 合理设置重试间隔和最大重试次数
2. 考虑结合指数退避算法
3. 记录重试日志以便监控和分析

最佳实践

在云原生应用中，特别是使用 Azure 服务时，建议：

1. 将 DNS 解析失败视为暂时性错误
2. 实现更全面的网络异常处理策略
3. 监控和分析失败模式以优化重试参数
4. 考虑使用连接池和健康检查机制

未来展望

EF Core 团队正在考虑是否应该默认将 DNS 解析失败视为暂时性错误，这可能会在未来的版本中实现。在此之前，开发者可以通过上述自定义策略来解决这个问题。

通过这种定制化的重试策略，可以显著提高在云环境中使用 Npgsql 连接 PostgreSQL 数据库的可靠性和弹性。