大规模还原中途失败

支持
1

你好！我重新拾起了之前提到的迁移工作。由于原始安装所在的（过时的）主机出现了一些问题，这件事变得更加紧迫。

背景：在迁移到新实例的过程中，我决定迁移到一个外部的 PG 和 Redis 实例。新安装的设置很顺利，我计划通过命令行进行备份 + 恢复来完成迁移。目前我正试图测试工作流程，确保新恢复的实例按预期工作，然后再将原始实例设置为只读并继续进行，特别是考虑到这是一个相当老旧/庞大的实例。

旧实例：简单的自托管设置，一个实例，带有标准的共置 PG、Postgres 和 Redis。
新实例：相同的 app.yml，但使用外部托管的 PG + Redis（DigitalOcean）。

恢复命令似乎运行了很长时间。然后，在相当长一段时间后，我一直收到一个看起来像这样的错误（包括一些成功的日志作为参考）：

COPY 99820
COPY 3216770
COPY 3251307
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
invalid socket
connection to server was lost
EXCEPTION: psql failed: connection to server was lost
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'

在运行过程中，它发生在不同的具体复制点，所以我认为这与迁移本身无关。考虑到数据库连接显然都正常工作，我认为可以安全地假设这是与 DigitalOcean 的行为有关的问题，但我希望社区里有人遇到过类似的情况，并能指引我方向。

2

由于这是一个托管的 PG 实例，您需要检查该服务的日志。

（请务必查看日志！）

您可能会发现日志会告诉您发生这种情况的原因，例如，也许它配置了最大连接生命周期，而恢复所需的时间比预期的要长。

2 个赞
3

嗯……我……检查了日志，其中大部分信息与我在 Discourse 日志中看到的一样，但深入查看日志让我实际上检查了那个时间点的历史图表……我低估了测试数据库的大小 :facepalm:，所以它满了，DO 直接断开了连接。笨蛋。

调整了大小后，我们感觉很蠢，但又回到了正轨。

2 个赞
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.