从 BLOB 到 Azure Postgres Gen5 8 内核的 MS Azure 数据工厂 ADF 复制活动失败，连接因主机错误而关闭答案

【问题标题】：MS Azure Data Factory ADF Copy Activity from BLOB to Azure Postgres Gen5 8 cores fails with connection closed by host error从 BLOB 到 Azure Postgres Gen5 8 内核的 MS Azure 数据工厂 ADF 复制活动失败，连接因主机错误而关闭
【发布时间】：2019-12-28 14:48:57
【问题描述】：

我正在使用 ADF 复制活动将 azure blob 上的文件复制到 azure postgres .. 我在做递归复制，即文件夹中有多个文件.. 很好.. 我必须复制的 5 个文件的大小总计约为6GB。运行 30-60 分钟后活动失败。使用了 100-500 的写入批量大小，但仍然失败。使用 4 或 8 个或自动 DIUS，类似地尝试使用 1、2、4、8 或自动并行连接到 postgres。通常它似乎每个源文件使用 1 个。 azure postgres 服务器有 8 个内核，临时缓冲区大小为 8192 kb。允许的最大值是 16000 kb。甚至尝试使用它，但我一直在遇到 2 个错误。 ms 支持团队建议使用重试选项。如果我得到一些但低于 r 的错误，仍在等待 pg 团队的回复。

答案：{ '错误代码'：'2200'， 'message': ''Type=Npgsql.NpgsqlException,Message=Exception while reading from stream,Source=Npgsql,''Type=System.IO.IOException,Message=Unable to read data from the transport connection: 强制现有连接被远程主机关闭。,Source=System,''Type=System.Net.Sockets.SocketException,Message=一个已存在的连接被远程主机强行关闭,Source=System,'', “故障类型”：“用户错误”， 'target': 'csv 到 pg 暂存数据迁移', '细节'： [] }

或

目标 csv 到 pg 暂存数据迁移的操作失败：'Type=Npgsql.NpgsqlException,Message=Exception while flushing stream,Source=Npgsql,''Type=System.IO.IOException,Message=Unable to write data to the transport connection: 已存在的连接被远程主机强行关闭。,Source=System,''Type=System.Net.Sockets.SocketException,Message=已存在的连接被远程主机强行关闭,Source=System

【问题讨论】：

该错误表明 PostgreSQL 服务器由于某些原因关闭了连接。您应该有权访问日志，其中一些消息应该会有所启发。
感谢您的回复，但我需要更多详细信息。 Azure postgres 日志（我什至将服务器属性 log_error_verbosity 更改为 Verbose）只是给出了我在上面粘贴的类似错误消息。您知道我需要更改哪些其他服务器属性才能查看详细日志吗？ postgres 关闭连接的任何原因.. 我看到指标 .. 最大内存利用率
有没有机会在开发机器上的常规 PostgreSQL 上重现这个？
不，因为我正在使用 ADF 从 Blob 复制到 Azure Pg。我正在等待 MS 支持 PG 团队的回复。问题很简单。连接被杀死。谁杀死了它，为什么？ ADF 是否无法处理如此大容量的负载。对于大约 10 GB 的源中的多个 csv 文件中的 2000 万条记录，它可以正常工作，但对于其他任何内容都失败了。我使用最大允许的 DIU 和并行副本。我尝试启用日志，但没有提供更多详细信息，说明了一些前端错误……对我来说，这意味着 conn 已关闭。我也删除了 SSL 和 vnet。 adf 在欧洲。其他地区的 blob & pg
MS 支持向产品工程师确认这是一个已知问题，当数据量太大或需要很长时间复制时，ADF 复制活动可能会出现此问题。他们计划最早在下月初的某个时候提出解决方案。问题是由于他们使用的底层驱动器 Npgsql ......悲伤的部分是在 ms 文档中，他们说默认写入批处理是 10000 .. 对于这个问题，他们建议尝试使用较小的批处理大小可能是 10这行得通。我试过了。它随机工作。对于源和接收器中的相同数据，有时 1000 个批量大小有效，有时甚至 100 个失败。将尝试 10 个，但可能需要数周时间

标签： azure copy connection npgsql socketexception

【解决方案1】：

我最近也遇到了这个问题，并联系了我们的微软代表，他们在 2020 年 1 月 16 日回复了我以下更新：

“这是我们在驱动程序中发现的另一个问题，我们刚刚完成了昨天部署通过升级驱动程序版本来解决这个问题。现在客户可以在一个批次中拥有多达 32767 列数据（其中是 PostgreSQL 的限制，我们不能超过）。

请让客户确定（写入批量大小*列大小）

“列大小”是指表中的列数。 “面积”（行写入批量大小 * 列数）不能大于 32,767。

我能够将复制活动的 ADF 写入批量大小更改为动态公式，以确保每个表的最佳批量大小，具体如下：

@div(32766,length(pipeline().parameters.config)

pipeline().parameters.config 指的是包含有关表列信息的数组。数组的长度 = 表格的列数。

希望这会有所帮助！我能够通过 ADF 填充数据库（尽管速度很慢）...更喜欢基于 COPY 的方法以获得更好的性能。

【讨论】：

感谢发帖。因为它影响了我们的项目时间表，所以我升级了很多时间，并且得到了 MS 支持的相同响应。他们在几天内修复了相同的问题。由于工作忙，我很抱歉迟到了一点，但是是的，这是他们的司机的问题。他们部署了修复程序，此后，ADF 运行顺利。他们最初建议我使用 100 或 10 这样的小批量，但修复后，我什至可以使用 2000，并且复制速度非常快。 @dabears318 .. 您动态使用写入批量大小的解决方案很棒。感谢并感谢。
感谢 dabears318，我试图按照您的建议动态提供写入批量大小，但无法理解如何通过，实际上我们不应该通过，但它应该能够自动从目标表中获取 col 信息即没有。 cols .. 你能解释一下你的代码是如何获得配置参数的价值的吗？
嗨 Harsh，我正在为 PostGres 目标副本执行 SQL 服务器源，在该副本中我运行“查找”ADF 函数，该函数利用源表服务器上的内省 SQL 查询返回有关表的数据（列表列，它们的类型，它们是主键等）然后我将它们作为 JSON 对象输入到复制脚本中。我可以从中获得长度（列数）。不确定这是否有帮助。
嗨@HarshKishore，请考虑接受这个作为答案 - 虽然不完美，但我相信这正确地总结了问题并通过改进性能的建议解决。
@HarshKishore 这仍然是 ADF 的问题吗？我遇到了同样的问题，听起来像同样的问题。