Aws*_*ike 13 postgresql containers docker docker-swarm
我试图更好地理解 Docker，但在这样做的过程中，我似乎损坏了我的应用程序的 PostgreSQL 数据库。
我正在使用 Docker Swarm 启动我的应用程序，但在 PostgreSQL 容器中的循环中收到以下错误：
2021-02-10 15:38:51.304 UTC 120 LOG: database system was shut down at 2021-02-10 14:49:14 UTC
2021-02-10 15:38:51.304 UTC 120 LOG: invalid primary checkpoint record
2021-02-10 15:38:51.304 UTC 120 LOG: invalid secondary checkpoint record
2021-02-10 15:38:51.304 UTC 120 PANIC: could not locate a valid checkpoint record
2021-02-10 15:38:51.447 UTC 1 LOG: startup process (PID 120) was terminated by signal 6
2021-02-10 15:38:51.447 UTC 1 LOG: aborting startup due to startup process failure
2021-02-10 15:38:51.455 UTC 1 LOG: database system is shut down
最初，我试图通过转到 FS 中的挂载驱动器来修改容器中的pg_hba.conf文件，该驱动器位于
/var/lib/docker/volumes/postgres96-data-volume/_data
然而，每次我重新启动容器时，我对pg_hba.conf的更改都会被恢复。因此，今天早上我在挂载文件夹中添加了一个名为test的虚拟文件，并重新启动了容器，希望删除该文件以获得视觉验证，即重新启动容器会自动将该挂载中的所有内容替换为其原始格式。再次重新启动后，我开始收到这些错误消息，阻止我的应用程序启动。
我删除了测试文件并再次重新启动容器，但错误消息仍然存在。
我阅读了许多有关如何修复它的解决方案，但我的问题更多的是了解为什么添加文件会导致这种情况？我的卷是否仅仅因为我在其中添加了文件而损坏了？
谢谢
pal*_*alc 15
对于那些直接使用已接受答案中的解决方案的人，这是您的警告：
已接受答案中的解决方案要求删除 docker 卷，这意味着PostgreSQL 实例中的所有数据都将丢失！
如果您想保留数据库实例的数据，请参阅我的回答。
我还使用 docker swarm 来部署容器，最近在尝试扩展 postgres 数据库以创建 2 个副本时遇到了这个问题，两个副本都指向相同的物理卷（使用 docker 安装，使用 NFS 共享）。这是为了使数据在两个副本之间保持同步所必需的。但这导致我犯了和你一样的错误
PANIC：无法找到有效的检查点记录
首先，数据库卷没有损坏，只是事务 WAL 损坏或失去了共识。我对此做了很多挖掘。我发现有两种情况可能会出现这个错误：
数据库正在执行实时事务，但由于某些错误而突然关闭。在这种情况下，WAL 告诉数据库当它意外关闭时它应该做什么。但是，如果 DB 在 WAL 更新期间关闭，WAL 可能会反映一些实际执行的事务，但具有不正确的执行信息。这会导致 DB 数据与 WAL 不一致，或者事务日志损坏，从而导致检查点错误。
您创建指向同一卷的数据库的多个副本。考虑一下我遇到的 2 个副本的情况。当两个副本同时尝试在同一数据库卷上执行事务时，事务 WAL 会失去共识，因为有两个同时检查点。数据库无法执行任何进一步的事务，因为它无法确定哪个检查点被视为正确的检查点。如果两个容器（不一定是副本）指向 PG_DATA 的相同安装路径，也可能会发生这种情况。
最终，数据库无法启动。容器不会启动，因为数据库抛出错误并关闭容器。
您可以重置 WAL 来解决此问题。当 WAL 重置时，您将丢失尚未在 DB 上执行的事务的数据。但是，已写入的数据和已处理的事务将被保留。
Con*_*ech -3
此错误意味着 Postgres 卷已损坏。当两个容器尝试同时连接到同一卷时，可能会发生这种情况。请参阅此答案以获取更多信息。不确定修改文件如何损坏驱动器。不过，您需要删除并重新创建该卷。为此，您可以：
$ docker stop <your_container_name> # stops a running container
$ docker image prune # removes all images that are not attached to a container
$ docker volume ls # list out active volumes
$ docker volume rm <volume_name> # Remove the volume that's corrupted
我必须运行上面的代码来停止容器，清理未附加到任何容器的图像，然后最终删除保存损坏数据的有问题的卷。