我们目前正在运行这个最新的发布版本：
它仍在我们的生产容器中运行（没有问题）。
我正尝试基于此版本进行引导：
今天我尝试了多次，但每次都卡在这里：
检查了数据和待用应用容器（我们正在进行引导）中的日志，没有发现错误或问题。
每次我执行引导时，都会卡在这行命令上：
I, [2021-02-11T10:37:25.133098 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
有什么线索可以帮我调试吗？
我已经查看了所有能想到的日志（在所有容器中），但找不到问题。
谢谢。
附加信息：
每次卡住后，如果我按 Ctrl+C 退出引导过程，似乎会留下一个 postmaster 进程，之后我可以将其终止。
示例如下：
更新：
如果我在 Web 模板中注释掉 “db:migrate” 这一行，引导重建就能正常完成。
“rails db:migrate” 卡住且没有任何错误，这是我从未遇到过的奇怪问题。
我怀疑这次最近的迁移中是否存在错误（或某些底层问题）？
另请参阅：
你好 @neounix，我们已注意到您链接的迁移存在问题，目前正在修复中。
你好 @david
谢谢回复！
我刚才查看了迁移过程，作为“非 Discourse 数据库迁移专家”，我第一反应是这可能就是问题所在？
add_index :dismissed_topic_users, %i(user_id topic_id), unique: true
不过，我没有资格深入探讨 Discourse 迁移问题，所以我将退一步并随时待命。
再次感谢！
我们能否在不造成任何数据丢失的情况下安全地中止迁移并回退几个提交？
它奏效了。
嘿 @neounix，
抱歉将那个庞大且有问题的迁移代码加入了代码库。这些更改已被回滚，因此新的部署应该没问题：
感谢你的更新：
我倾向于同意，这次“大规模迁移”极有可能需要在合并到核心之前，在配置了大型数据库的测试环境中进行额外的审查和严格的开发测试。幸运的是，我们的网站始终采用与生产环境并行的引导方式，因此在迁移失败期间没有遭受任何停机，我们这边不用担心。感谢你们如此迅速地回滚。
仅供参考（仅为技术上的精确性，抱歉如此啰嗦……），我刚才在重建后检查了数据库，发现“回滚”过程并未从数据库中删除该表。这没什么大不了的，仅供参考：
discourse=> \d dismissed_topic_users
Table "public.dismissed_topic_users"
Column | Type | Collation | Nullable | Default
------------+-----------------------------+-----------+----------+---------------------------------------------------
id | bigint | | not null | nextval('dismissed_topic_users_id_seq'::regclass)
user_id | integer | | |
topic_id | integer | | |
created_at | timestamp without time zone | | |
Indexes:
"dismissed_topic_users_pkey" PRIMARY KEY, btree (id)
"index_dismissed_topic_users_on_user_id_and_topic_id" UNIQUE, btree (user_id, topic_id)
再次感谢你们为此付出的辛勤工作，并迅速回滚了此次迁移。
此次迁移基于最新提交现已顺利推进：
此主题已在 6 天后自动关闭，不再允许新回复。