Question

要在本地恢复生产数据库，我将一个Postgres转储添加到Docker构建文件中。直到最近，这还是一个平稳的过程。但是随着分贝稳步增长（现在为+ 80G），似乎我遇到了一个未知的门槛。构建会在Dockerfile中的简单ADD dmp.sql.gz /tmp/dmp.sql.gz行崩溃（因此之前实际上会解压缩或执行文件的内容）

Sending build context to Docker daemon  87.42GB
Step 1/6 : FROM ecr.url/postgres96
 ---> 36f64c15a938
...
Step 5/6 : ADD dmp.sql.gz /tmp/dmp.sql.gz
Error processing tar file(exit status 1): unexpected EOF

Docker守护进程的日志没有给我太多线索：

Aug 15 10:02:55 raf-P775DM3-G dockerd[2498]: time="2018-08-15T10:02:55.902896948+02:00" level=error msg="Can't add file /var/lib/docker/overlay2/84787e6108e9df6739cee9905989e2aab8cc72298cbffa107facda39158b633d/diff/tmp/dmp.sql.gz to tar: io: read/write on closed pipe"
Aug 15 10:02:55 raf-P775DM3-G dockerd[2498]: time="2018-08-15T10:02:55.904099449+02:00" level=error msg="Can't close tar writer: io: read/write on closed pipe"

我跟踪了将文件实际复制到覆盖文件fs的过程，希望看到它在进程中的某处崩溃，但是在整个文件传输后它实际上崩溃了：

root@raf-P775DM3-G:/home/raf# ls /var/lib/docker/overlay2/e1d241ba14524cff6a7ef3dff8222d4f1ffbc4de05f60cd15d6afbdb2bb9f754/diff/tmp/ -lrta
total 85150928
-rw-r--r-- 1 root root 87194526754 Aug 14 00:01 dmp.sql.gz // -> this is the whole file
drwxr-xr-x 3 root root        4096 Aug 14 17:30 ..
drwxrwxrwt 2 root root        4096 Aug 14 17:30 .

当此dmp文件位于70GB范围内时，在不同的OS和Docker版本上，以这种方式进行恢复是一个耗时但平稳的过程。

有人可以帮助您找出问题的要点吗？

当前在Docker version 18.06.0-ce, build 0ffa825上遇到此问题

Ps：我读到一个tar标头限制为8GB，这会导致EOF异常（https://github.com/moby/moby/issues/37581），但同样，我们正在恢复70GB +的转储而没有问题。

Answer 1

尝试升级到18.09。他们更改了可解决此问题的tar后端。至于70GB文件为何起作用的原因，我怀疑它与图层压缩有关，因为您无法使用零的8GB文件触发此问题。参见https://github.com/moby/moby/pull/37771。

向Docker构建中添加大文件会导致EOF异常

1 个答案: