由于数据库关闭缓慢导致重建出现问题

安装
1

推荐的升级失败了，并且在中断后未能使我的论坛恢复正常。我正在运行 discourse-doctor 来尝试修复它，如果这也失败了，我将使用 VM 快照。

输出：

2023-04-19 18:28:31.298 UTC [42] LOG:  received fast shutdown request
2023-04-19 18:28:33.651 UTC [65] LOG:  shutting down
2023-04-19 18:28:33.974 UTC [42] LOG:  database system is shut down


FAILED
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 59 exit 2>
Location of failure: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap failed with exit code 2
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Command exited with non-zero status 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps
2

您是否在使用 beta 分支？

您可以尝试使用以下命令重启您的容器：

 ./launcher start app

但这应该是 discourse-doctor 的功能。

您需要提供更多输出，因为错误信息超出了您包含的内容范围。

2 个赞
3

是的，我们在 beta 分支上。我一直在 nohup 中运行，所以我有完整的日志。

Discourse-doctor 仍在努力运行，但尚未失败，所以我抱有希望。

https://pastebin.mozilla.org/iw2zc5zd

编辑：Discourse-doctor 使我们恢复了正常运行。

我基本上是自找的，在收到通知一小时后就进行了升级，并且是第一个这样做的。之前没有真正备份，所以我在这里为大家承担了风险。

1 个赞
4
  • 2023-04-19 18:28:26.755 UTC [45] LOG: 数据库系统未正确关闭；正在进行自动恢复

如果您的数据库无法在 60 秒内安全停止，这在大数据库和较慢磁盘上会发生，它将进入此状态，并且如果在 5 秒内无法恢复（这种情况很少见，因为它很大/很慢），则重建会失败。

这与此处列出的更改无关，而是自 2016 年以来 Discourse 中一直存在的问题。

6 个赞
5

啊，谢谢。也许对于我们这样的大型论坛，应该让它等待更长时间。如果你只是终止数据库进程，它在重新启动后需要回滚事务，这可能需要很长时间。

关于 beta 的术语有点令人困惑。管理员仪表板显示我们正在运行 beta 版，我们是否应该查看其他地方？我的理解是，基于发布公告中不建议使用稳定分支的说法，beta 版是推荐用于 discourse 的。

1 个赞
6

默认值实际上是 tests_passed，这被认为是生产就绪的。

1 个赞
7

您的数据库有多大？它在固态硬盘上吗？您有多少内存？

拥有一个单独的数据容器将需要更少的数据库重启。

8

何时决定在 60 秒内安全关闭？现在有多少安装比当时正常情况大得多？

理想情况下，这种 60 秒的等待应该更像是一种闭环等待，并有一个限制。听起来这个限制应该更高，因为现在有很多实例比当时正常情况大得多，而且存在漏洞。

2 个赞
9

它有 105GB，在 SSD 上，16GB VM，我为 postgres 分配了 8GB 的缓冲区。

10

我认为我看到它至少可以追溯到 2016 年。但情况已经改变了。 编辑：这是一个新的提交。

我认为标准安装的并不多，因为这几乎从一开始就是这样了。

呃，是的。这是一个大数据库。我怀疑很少有人拥有如此大的数据库，而不是在 RDS 上，或者至少是一个单独的容器。您可能应该考虑切换到 2 容器安装。

1 个赞
11

我们会考虑的，切换方法有文档记录吗？增加 60 秒计时器还有其他无法提供的优势吗？

12

我昨天将其增加到10分钟

4 个赞
13

太好了，我还以为他是在发布 2016 年的原始提交。那么对我们来说有什么好处吗？

14

你可以查看 Move from standalone container to separate web and data containers

你可以在旧容器继续运行的同时构建一个新容器。你不需要关闭数据库来构建一个新容器。

现在有 10 分钟的时间关闭 postgres，这应该可以解决你目前的问题。一旦你再进行一次重建，你将拥有 10 分钟而不是一分钟。

15

那位家伙刚刚构建了一个全新的两个容器实例，然后从备份恢复。我们绝对不会在没有充分理由的情况下这样做，我只是不得不在大约两个月前这样做，以避免 PG13 升级所需的磁盘空间。

16

如果你不在 PG13 上，你应该修复它。

我会启动一个新服务器并迁移到那里。

17

我们现在，那个最终是不可避免的！除了数据库，我们还需要从不再受支持的 18.04LTS 进行升级。

1 个赞
19

拥有如此庞大的数据库，您应该将其移至专用容器。

这将大大加快重建速度，并使一切变得更简单。

1 个赞
20

如果能有关于如何操作的文档，而无需从头开始完全重建，那么恢复备份我们将肯定考虑。

21

所以您想快速迁移到单独的 Web 和数据容器

1 个赞