如何使用 pgbackups 将生产数据库转移到 Heroku 上暂存？得到错误

Posted 2023-03-13

【中文标题】如何使用 pgbackups 将生产数据库转移到 Heroku 上暂存？得到错误

【英文标题】：How do I transfer production database to staging on Heroku using pgbackups? Getting error

【发布时间】：2012-05-27 06:25:21

【问题描述】：

在 Heroku 上，我正在尝试使用 pgbackups 插件将生产数据库复制到我的暂存应用程序中。我按照插件页面上的说明进行操作：https://devcenter.heroku.com/articles/pgbackups

首先我捕获了数据库：

heroku pgbackups:capture --app production-app 

成功了：

HEROKU_POSTGRESQL_PURPLE (DATABASE_URL)  ----backup--->  b238

Capturing... done
Storing... done

但是，当我尝试在暂存应用程序上恢复它时：

heroku pgbackups:restore DATABASE `heroku pgbackups:url --app production-app` --remote staging

我收到以下错误消息：

DATABASE_URL does not match any of your databases
 !    Could not resolve database DATABASE
 !    
 !    Available databases: 

我也尝试过输入完整的网址：

 heroku pgbackups:url b238 --app production-app
 heroku pgbackups:restore DATABASE "https://s3.amazonaws.com/..." --remote staging

并尝试命名应用程序（而不是 --remote staging）：

heroku pgbackups:restore DATABASE `heroku pgbackups:url --app production-app` --app staging-app

这些都不起作用。有趣的是，错误消息显示没有“可用数据库”。我假设它指的是确实是空的登台应用程序。如果我输入：

heroku pgbackups

我明白了：

 !    No backups. Capture one with `heroku pgbackups:capture`.

要查找可用的备份（生产），我需要输入：

heroku pgbackups --app production-app

我得到了当前备份的列表。我不知道这是否正常，或者即使它与问题有关，但我认为我应该提一下。

我已经阅读并尝试了关于 SO 的所有答案，但没有任何效果。有什么想法吗？

【参考方案1】：

2017 年年中更新（盗用 Takehiro Mouri 的答案 - 简化 DATABSE_NAME 部分）

2015 年年中更新...

pgbackups 插件已被弃用。没有更多的pgbackups:transfer。

将数据库从 yourapp 复制到 yourapp_staging：

# turn off the web dynos in staging
heroku maintenance:on -a yourapp-staging

# if you have non-web-dynos, do them too
heroku ps:scale worker=0 -a yourapp-staging

# backup the staging database if you are paranoid like me (optional)
heroku pg:backups capture -a yourapp-staging

# execute the copy
heroku pg:copy your-app::DATABASE_URL DATABASE_URL -a yourapp-staging

然后，当它完成后，重新打开暂存：

# this is if you have workers, change '1' to whatever
heroku ps:scale worker=1 -a yourapp-staging

heroku maintenance:off -a yourapp-staging

（来源：https://devcenter.heroku.com/articles/upgrading-heroku-postgres-databases#upgrade-with-pg-copy-default）

【讨论】：

在heroku pg:copy 期间，这个新过程（与将已生成的备份从 prod 应用到 staging 不同）是否会对主数据库施加任何额外压力？

我的用例不够大，无法确定。我在他们的文档中看不到任何关于它的内容（估计该过程每 GB 数据需要 3 分钟）。鉴于不需要现有备份，您必须假设该过程在复制的大部分时间段内将读取 IO 负载放在源数据库上。

我无法在 pg:info 的输出中轻松找到数据库名称。是“附加”字段吗？

... 回答：是的。 db 名称不再像那些颜色了，它们有很长的小写单词和数字

@LucasNelson 有没有办法自动化这个过程并按计划运行？我不能在 Heroku dyno 中这样做，因为那里无法访问 heroku CLI！

【参考方案2】：

更新： 您可以运行此命令将数据库从生产转移到登台： heroku pg:copy your-app::DATABASE_URL DATABASE_URL -a yourapp-staging

它会提示您确认操作，一旦您完成此操作，所有数据都将被迁移。

【讨论】：

这是否意味着数据库结构将与生产中的相同？换句话说，它会只复制数据还是从头开始重新创建数据库.. 表、字段？

它看起来像是对所有表和数据进行了完全迁移，首先将所有数据放在暂存数据库中。

【参考方案3】：

更新：这不再有效。请参考下面@lucas-nelson 的answer。

所以现在事情变得更容易了.. 签出传输命令作为 pgbackups 的一部分

heroku pgbackups:transfer HEROKU_POSTGRESQL_PINK sushi-staging::HEROKU_POSTGRESQL_OLIVE -a sushi

https://devcenter.heroku.com/articles/upgrade-heroku-postgres-with-pgbackups#transfering-databases-between-heroku-applications

这对我将生产代码带回我的暂存站点非常有效。

【讨论】：

按照***.com/questions/3850299/…的说法，会破坏原来的数据库，不是吗？

文档没有明确说明它是否会破坏目标数据库中的部分或全部数据。它对我来说已经足够快了，所以我做了一个替代实现......跨度>

这不再有效，请在下面投票@lucas-nelson 的回答。

【参考方案4】：

这是一个使用 Heroku 的附加附件和分叉的简单而安全的解决方案。它不需要备份，不需要停机，也不会覆盖任何数据库。

您需要先将生产数据库附加到 staging 应用，然后在 staging 应用上 fork。 如果您在生产应用上 fork，然后附加到 staging 应用，计费应用将是生产应用程序，您将无法从中分离叉子。

1.首先找出你的生产数据库的插件名称（这里是postgres-prod-123）：

$ heroku addons --app myapp-production
heroku-postgresql (postgresql-prod-123)  standard-0  $50/month
 └─ as DATABASE

2. 然后将attach 生产数据库附加到您的登台应用程序。给它起一个像PRODUCTION_DB 这样的名字，以便于识别：

$ heroku addons:attach postgresql-prod-123 --app myapp-staging --as PRODUCTION_DB

3. 然后create a fork 暂存应用程序上的生产数据库：

$ heroku addons:create heroku-postgresql:standard-0 --fork PRODUCTION_DB_URL --as STAGING_DB --app myapp-staging

4. 最后将 fork 提升为暂存应用的主数据库：

$ heroku pg:promote STAGING_DB --app myapp-staging

完成！您的暂存应用程序现在正在使用您的生产数据库的副本。 请注意，您之前的暂存数据库仍然存在，您可能希望在确保一切正常后将其销毁。

要清理，请将生产数据库从暂存应用程序中分离出来：

$ heroku addons:detach postgresql-prod-123 --app myapp-staging

【讨论】：

最好的方法 IMO

这很有帮助。看起来您现在也可以在 UI 中分叉（在资源的 Heroku 数据库页面中）。

@BradBumbalough 是的，您可以在 UI 中分叉，但是当我尝试分叉但将计费应用程序保留在原始应用程序上时，这不起作用。您可以在 UI 中完成大部分步骤，但分叉步骤似乎需要在 CLI 中完成

分叉仅适用于生产层服务器。爱好者，请注意

【参考方案5】：

这对我有用： heroku pg:copy you-app-production::DATABASE DATABASE -a you-app-staging

【讨论】：

只是为了澄清只需要替换you-app-production和you-app-staging。 “DATABASE”不需要替换成任何东西。

【参考方案6】：

你可以使用下面的命令来做到这一点

heroku pg:copy <production_app_name>::HEROKU_POSTGRESQL_BLACK_URL OLIVE -a <staging_app_name> --confirm <staging_app_name>

【参考方案7】：

我在同样的问题上苦苦挣扎。根据this question 的回答，问题可能出在您的heroku gem 版本上。我刚刚升级了我的版本（从 2.26.2 到 2.26.6），现在它可以工作了。

【讨论】：

我可以通过升级数据库来解决这个问题。看来默认的 5MB 还不够。

【参考方案8】：

首先创建一个最新的生产备份：

heroku pgbackups:capture -a productionappslug --expire

找出 Heroku 为您的数据库命名的颜色。

https://postgres.heroku.com/databases 要么 https://dashboard.heroku.com/apps/STAGINGAPPSLUG/resources

然后将生产数据库备份加载到暂存中（将 RED 更改为您的颜色）：

heroku pgbackups:restore HEROKU_POSTGRESQL_RED -a stagingappslug `heroku pgbackups:url -a productionappslug`

stagingappslug 和 liveappslug 是您的 heroku 应用的简称。

【参考方案9】：

将生产数据库（source数据库）转移（复制）到staging数据库（target数据库) 您需要从 target 应用程序调用 pg:copy，引用 source 数据库。

heroku pg:copy source-application::OLIVE HEROKU_POSTGRESQL_PINK -a target-application

另一个例子：

heroku pg:copy my-production-app::HEROKU_POSTGRESQL_OLIVE HEROKU_POSTGRESQL_PINK --app my-staging-app

要获取数据库的颜色名称，请使用：

heroku pg --app my-production-app
heroku pg --app my-staging-app

见pg:copy

【参考方案10】：

没有运气之后。 （我使用heroku gem 2.31.4） 我做了以下（疲倦的帮助）

登录 Heroku 数据库控制台

登录到 staging > 'settings' > PGRestore > 将“Connection Settings”复制到一个文本文件中。

登录到生产环境> 快照，按“+”立即进行新备份。然后按下载。下载 进入应用程序 /tmp 文件夹或任何你想要的地方。

将登台设置为维护模式

$ heroku 维护：开启

像这样运行命令，末尾带有连接设置文本和转储文件：PGPASSWORD=...bits of stuff here... -p 5432 'tmp/b048.dump.dump'

运行后：

$ heroku 维护：关闭

登录到暂存并检查内容是否匹配。 如果可以通过，找到您知道正在生产中的最近交易。 $ heroku 为两个应用程序运行控制台并检查 ids 是否匹配。

【参考方案11】：

我认为它不是 --remote 它的 --app 试试这个：

heroku pgbackups:restore DATABASE `heroku pgbackups:url --app production-app` --app staging-app

【参考方案12】：

这对我有用

从heroku控制台下载备份并上传到s3。 heroku pg:backups restore 'DUMP_FILE_URL_FROM_S3' DATABASE --app MY_APP