Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups/exec_command.rb:132:in `spawn'
exec failed with the params {"cd"=>"$home", "tag"=>"migrate", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
**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.
9e8de06a277d5ac57d1a7ef16b9cde5fc6dd11766c456bccc7ea22b90bf80bb9
```
---
### Author:  [@Heliosurge](https://meta.discourse.org/u/Heliosurge)
#### Post date: [2025 年1 月 5 日 07:49 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/47 "2025-01-05T07:49:45Z")
> [@tisawyer](#):
>
> 供记录，我们的一位聪明人找到了如何使用 rsync 同步容器所需的正确权限，以便 PostgreSQL 能够运行：
>
> ```plaintext
> rsync -rog --delete --perms --numeric-ids root@x.x.x.x:/var/discourse/ /var/discourse
>
> ```
这似乎奏效了。并显示应用程序正在运行，但无法从网络访问。
> **[Xrtropolis.one](https://www.xrtropolis.one)**
>
> Neutral Space to Discuss AR/VR/XR !
会不会是还没有从域名服务器连接？
**注意：** 。我想我找到了。可能需要等待 24 到 72 小时 IP 地址更改才能完全生效。🙁
这是我收到的连接消息。推测必须等待名称服务器更新。
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 13 日 22:59 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/48 "2025-08-13T22:59:13Z")
我只想重申，在使用 rsync 同步到新服务器时，`--numeric-ids` 是 100% 必需的。否则，rsync 将尝试匹配主机之间的用户名，这将更改 Docker 内部的文件所有权。这会导致你遇到大量错误消息，最终发现第一个失败是 Postgres 拒绝启动，因为它不再拥有它认为应该拥有的文件，然后还会引发大量其他混乱（Redis 将尝试绑定它已在监听的 TCP 端口，猫狗同居等），使得诊断问题变得困难。
另外，Discourse 制作的、用于在 Discourse 完全控制的 Docker 容器内运行的实际备份 _可能无法正常工作_，并且显然存在可以追溯到 [数年](https://meta.discourse.org/t/cant-restore-due-to-corrupt-indexes-with-some-clues-on-how-to-deal-with-corrupt-indexes/137400/15) 的、似乎未得到解决的故障，这让我感到非常恐惧，这也是我选择 rsync 来迁移到新硬件的原因。Rsync 成功完成了任务，现在它运行在一个带有每小时快照的镜像 ZFS 文件系统上，并且每天进行远程备份，这很棒……但我确实担心那些认为 Discourse 的自动备份会在灾难中拯救他们而沾沾自喜的管理员，当他们尝试使用备份时，会对着损坏的 SQL 索引以及他们运行了哪些插件而挠头。
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2025 年8 月 14 日 07:49 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/49 "2025-08-14T07:49:24Z")
我对这个损坏的索引问题感到好奇。如果你有一个损坏的索引，rsync 不会只是将这些错误信息传播到你的新实例吗？备份/恢复至少不会检测到有什么问题吗？
我不太清楚如何最好地修复损坏的索引——我看到 PostgreSQL 文档[说](https://www.postgresql.org/docs/current/sql-reindex.html)：
> 如果您怀疑用户表上的索引损坏，您可以使用 `REINDEX INDEX` 或 `REINDEX TABLE` 简单地重建该索引，或表上的所有索引。
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 14 日 08:07 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/50 "2025-08-14T08:07:58Z")
我没有深入研究，所以不能确定，但要么是官方备份方法生成了一个不起作用的 SQL 转储，要么是导入它导致了一个本不必是阻碍性的故障，要么是数据库已经损坏多年，但如果通过 rsync 传输，Postgres 仍然可以运行。
理论上，SQL 索引只是为了加快查询速度，对吧？所以，rsync 过的系统可能只是忽略了它，并且在某些细微方面存在一些我们没有注意到的问题。我真的不知道。
其他线程上的讨论表明，某个版本的 Postgres 破坏了东西，而后续版本修复了它，但我不知道具体的技术细节。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2025 年8 月 14 日 17:13 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/51 "2025-08-14T17:13:41Z")
> [@icculus](#):
>
> 我只想重申，在 rsync 到新服务器时，`--numeric-ids` 是 100% 必需的。
我不确定那是否属实，或者是否总是有效。我认为在某个时候，docker 容器内的用户和/或组 ID 发生了变化。不过，我愿意尝试 `–numberic-ids`。
对于我进行的新服务器迁移，我一直像这样跳过 postgres 文件：
```plaintext
cd /var/discourse
rsync -rav --numeric-ids =old_ip=:/var/discourse/containers/ /var/discourse/containers/
rsync -rav --numeric-ids =old_ip=:/var/discourse/shared/ /var/discourse/shared/ --exclude log --exclude postgres_* --exclude redis_data --exclude log --exclude tmp --exclude state
```
并在新机器上恢复备份。
> [@icculus](#):
>
> 我确实担心所有认为 Discourse 的自动备份会在灾难中拯救他们而沾沾自喜的管理员，他们会因为损坏的 SQL 索引而挠头不已，
是的。损坏的索引问题可能是一个真正的麻烦。不过，我很久没见过一个了。
> [@icculus](#):
>
> 理论上，SQL 索引只是为了加快查询速度，对吧？所以 rsync 过的系统可能只是忽略了它，并且在某些我们没有注意到的细微方面存在一些不足。我真的不知道。
是的，但是（我认为）它们也看到事物是唯一的，并且损坏的索引允许你拥有多个具有本应是唯一值的记录。这对于跟踪链接点击之类的东西来说，如果错了也不是特别关键。
> [@icculus](#):
>
> 其他线程的讨论表明，某个版本的 Postgres 破坏了东西，而稍后的版本修复了它，但我不知道具体的技术细节是什么。
我认为我比你更关注这个问题，而上述内容大致总结了我的理解。🤷 也许问题出在 PG12 上？这可以解释为什么我很久没遇到这个问题了，但我不能假装我确切地记得，如果我曾经确定的话。
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 14 日 18:23 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/52 "2025-08-14T18:23:04Z")
是否有已知的修复此问题的魔法咒语，即使是以一种通用的方式？比如运行 `./launcher enter app` 然后执行 _这个特定命令_，它就会重建所有的数据库索引，无论是否需要？
Discourse 令人惊叹和可怕之处在于，几乎总有一些神秘的魔法可以解决几乎所有问题，但有时很难找到这些知识。 🙂
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 14 日 18:28 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/53 "2025-08-14T18:28:04Z")
> [@pfaffman](#):
>
> 我不确定这是不是真的，或者它是否总是有效。
（另外，是的，我猜这可能并不总是有效，所以我应该少说点……但将文件所有权映射到新主机服务器上的任何内容都只能靠运气，所以你最好在 rsync 时赌一把 Discourse 镜像仍然具有相同的用户 ID 号。）
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2025 年8 月 14 日 21:11 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/54 "2025-08-14T21:11:06Z")
> [@icculus](#):
>
> 有没有已知的魔法咒语可以一劳永逸地解决这个问题？比如运行`./launcher enter app`然后执行_这个特定的命令_？
你可以
```plaintext
./launcher enter app
```
```plaintext
sudo su - postgres
```
```plaintext
psql
```
然后，（编辑：我查了一下，这似乎是实际的命令）
```plaintext
REINDEX CONCURRENTLY DATABASE discourse;
```
这将尝试重建它们，如果成功，你就没问题了。如果失败，你需要去删除那些有重复ID的东西。这比较复杂。
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 17 日 09:36 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/55 "2025-08-17T09:36:16Z")
> 这更复杂。
主啊，这真的应验了！ 🙂
我尝试了一下。请注意，我们的 Discourse 实例导入了大约 15-20 年的邮件列表存档。所以有很多旧帖子看起来像这样……
> **[SDL2 Graphics API, was Re: compiling with SDL\_NO\_COMPAT](https://discourse.libsdl.org/t/sdl2-graphics-api-was-re-compiling-with-sdl-no-compat/18675)**
>
> If we are going to start talking about what features should be in the graphics API for SDL2 I think we should start a new thread. Since this is a 3D API based running on top of modern hardware I’m going to suggest that it should include layers....
……你会在其中看到大量的链接，以及邮件回复，这些回复会引用整个前一封邮件，重复这些链接，还有一些邮件签名链接到不相关的项目，等等。
所以，在某个时候，`topic_links` 表出了问题，开始为它已经拥有的链接创建新行：
所以可能会有一行像这样：
```plaintext
69534 | 18675 | 86333 | 6631 | http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org | lists.libsdl.org | f | | 2017-03-26 12:13:06.365742 | 2017-03-26 12:13:06.365742 | f | 0 | | SDL Info Page | 2017-03-26 13:18:08.491592 | f |
```
该行创建于 2017 年。但后来我在所有这些帖子中发现_数百个_重复项，系统在 2024 年又添加了重复的行，id 值比原来的高出 200000。
所以有很多需要清理。
基本上，我会等待重新索引失败，看看它吐出了什么，找到重复行的 ID，然后调整 URL 字符串以不再重复……看起来系统已经通过在字符串中半随机地插入 `**` 来处理这个问题了。我也这么做了。我不敢直接删除这些行，因为我不知道这些行在其他地方有什么引用。
它似乎只是一小部分主题，可能是同一主题的不同帖子，因为我一遍又一遍地修复同一小部分 URL。这很乏味，我不推荐这样做。 🙂 我可能应该找到一种自动化方法。
还值得注意的是，REINDEX 上的“CONCURRENTLY”选项会构建一个临时索引（在名称后附加 `_ccnew*` 字符串），如果过程失败，它会保留在那里。如果你打算使用 CONCURRENTLY 并需要清理很多东西，那么在你清理完所有东西时，预计会删除_大量_临时索引。（另外，如果你像我一样，从未直接使用过 Postgres，也请注意，在 REINDEX 命令可以使用之前，我必须在开始时发出一个 `\\connect discourse;` 命令。）
我仍在进行这项工作；它似乎并没有让情况变得更糟，所以我将继续努力。
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [2025 年8 月 17 日 13:51 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/56 "2025-08-17T13:51:04Z")
这更像是敷衍了事，而不是真正的帮助，但这里有几个想法。
首先，既然您知道哪个索引已损坏，您可以只重新索引该索引，而不是数据库中的所有索引。您可以向 [https://ask.discourse.com/](https://ask.discourse.com/) 寻求有关如何执行此操作的提示。
[Corrupt indexes in PG12, how do I fix? - #11 by sam](https://meta.discourse.org/t/corrupt-indexes-in-pg12-how-do-i-fix/152570/11) 也有一些提示。
由于您不太关心此链接跟踪（我猜反正已经创建了一个新的），因此删除重复项即可。
应该有一种方法可以执行查询来查找重复项，以便您可以一次性删除它们。
---
### Author:  [@icculus](https://meta.discourse.org/u/icculus)
#### Post date: [2025 年8 月 17 日 22:20 UTC](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812/57 "2025-08-17T22:20:11Z")
我已经完成了这项工作，Postgres（以及 Discourse！）似乎都很满意。
我手动清理了它们，并根据需要使用 `**` 模式使 URL 唯一。这可能只是一个无害的缓存，我可以删除重复项，但我不想冒险。
在我的例子中，只有一个索引，所以重建_所有_索引可能有点过度，但说实话，我感觉好多了，因为我知道我抓住了所有东西。
在几次重建失败的运行之后，每次运行大约需要 30 秒并报告一个问题，这是我的 SQL 魔术，可以立即获得问题项目的完整列表：
```plaintext
discourse=# select topic_id, post_id, url, COUNT(*) from topic_links GROUP BY topic_id, post_id, url HAVING COUNT(*) > 1 order by topic_id, post_id;
topic_id | post_id | url | count
----------+---------+-------------------------------------------------------+-------
19200 | 88461 | http://hg.libsdl.org/SDL/rev/**533131e24aeb | 2
19207 | 88521 | http://hg.libsdl.org/SDL/rev/44a2e00e7c66 | 2
19255 | 88683 | http://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org | 2
19255 | 88683 | http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org | 2
19523 | 90003 | http://twitter.com/Ironcode_Gaming | 2
(5 rows)
```
（此查询中剩余 5 个有问题项，仅作示例。）
然后我会查看每个帖子，看看有什么以及如何修复：
```plaintext
select * from topic_links where topic_id=19255 and post_id=88683
```
然后修复其中一个：
```plaintext
update public.topic_links set url='http://lists.libsdl.org/__listinfo.cgi/**sdl-libsdl.org' where id=275100;
```
直到我把所有需要修复的东西都修完。 🙂
我可能可以用一些内部连接魔术（或者一点 Ruby）在一个查询中完成所有这些工作，但我不是专家，而且手动完成这项工作花费的时间并不_是_几个小时。但说实话，这确实很繁琐。 🙂
然后我运行了 `REINDEX DATABASE discourse;`，没有 `CONCURRENTLY`，只是为了简单起见，删除了我之前遗漏的几个 `ccnew*` 索引，然后我就搞定了。
网站一直在线，没有停机时间。
无论这是否_必要_，我_绝对_觉得我的数据现在更安全了，而且我不会走向某个未宣布的未来灾难。
感谢您给我指明了方向来解决这个问题，@pfaffman！
[Previous page](https://meta.discourse.org/t/move-a-discourse-site-to-another-vps-with-rsync/43812.md?page=2)