# 由于数据库重连失败，恢复操作失败

**URL:** <https://meta.discourse.org/t/restore-fails-because-of-non-working-database-reconnect/413615>\
**Category:** Bug\
**Created:** [2026 年9 月 29 日 23:40 UTC](https://meta.discourse.org/t/restore-fails-because-of-non-working-database-reconnect/413615 "2026-09-29T23:40:34Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\
**Post date:** [2026 年10 月 7 日 10:25 UTC](https://meta.discourse.org/t/restore-fails-because-of-non-working-database-reconnect/413615/4 "2026-10-07T10:25:16Z")

</div>

谢谢 @RGJ，我认为这应该能解决这个问题：

> <https://github.com/discourse/discourse/pull/44323>
>
> A restore opens one database connection at the start. \`psql\` and \`rake db:migrat…e\` run in separate processes, which can take a long time. If Rails' connection is dropped for some reason while \`psql\`/\`migrate\` are running, then the restore will fail on the first query after the migration.
> 
> We already had a "Reconnecting to the database..." step, but this step did not actually open a new connection. On a single-site install it did nothing, and on a multisite install it used the cached connection again. Rails automatic reconnection does not take effect because Discourse's \`DB.\*\` uses the raw\_connection.
> 
> \- \`reconnect\_database\` now calls \`reconnect!\`, so the restore continues on a new connection.
> 
> \- A new spec ends the restore's connection while the dump is restored, and checks that the restore still saves its date.
> 
> \- \`execute\_stubbed\_restore\` stubs \`reconnect!\` by default, because a real reconnect drops the test transaction. The multisite spec uses a real reconnect, because its second database is not in a test transaction.
> 
> https://meta.discourse.org/t/413615

---

_[View the full topic](https://meta.discourse.org/t/restore-fails-because-of-non-working-database-reconnect/413615)._