创建我的应用程序的沙盒版本。数据库复制?或者另一种方式

发布于 2024-11-08 07:21:25 字数 668 浏览 3 评论 0原文

我计划创建一个生产 Rails 应用程序的沙盒系统,供潜在客户使用。

制作系统不断更新新内容,我想将这些内容带到沙盒中,使其尽可能真实。但是,我不想通过执行完整的数据库转储/恢复来破坏沙箱,因为我想保留该系统上的用户帐户(只需使用新内容进行更新)

我已经检查了几个选项,但是我可以使用一些建议...

1-数据库转储/恢复

虽然它的工作原理很简单,但配置 cron 作业并在服务器之间传输整个数据库有点痛苦,即使我可能不需要它。我想我可以转储某些表,但这仍然可能会传输比所需更多的数据。

2- 数据库复制

在每个表的基础上设置主从复制。据我所知,这可能是我想做的事情。仅复制新内容表并忽略帐户表。

3-另一种方式?

我不确定...有更好的方法吗?

但是等等,还有更多!

沙箱系统并不总是运行(它仅在特定时间内可用),因此我需要一些在无法连接时不会感到太沮丧的东西。只是静静地失败,稍后再试。

我对复制还很陌生,所以有人建议从哪里开始吗? Slony-I、Bucardo、rubyrep?

详细信息

  • Rails 3 应用程序
  • PostgreSQL DB
  • Ubuntu 服务器

I'm planning on creating a sandbox system of a production rails app for potential clients to mess around with.

The production system is continuously being updated with new content which I'd like to bring over to the sandbox to make it as real as possible. However, I don't want to nuke the sandbox by doing a full db dump / restore as I'd like to preserve the user accounts on this system (just update with the new content)

I've checked out a couple of options but I could use some advice...

1- DB Dump / Restore

While it's simple in terms of how it works it's a bit of a pain to configure with cron jobs and transferring the whole db between servers even though I may not need it. I guess I can just dump certain tables but this will still probably transfer more data than required.

2- DB Replication

Setting up master-slave replication on a per table basis. From what I can see, this might be want I want to do. Replicate just the new content tables and ignore account tables.

3- Another way?

I'm not sure... is there a better way to be doing this?

But wait, there's more!

The sandbox system is not always running (it's only available during certain hours) so I need something that won't get too upset if it can't connect. Just quietly fail and try again later.

I'm pretty new to replication so does anyone have a recommandation of where to get started? Slony-I, Bucardo, rubyrep?

Details

  • Rails 3 app
  • PostgreSQL DB
  • Ubuntu server

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

云仙小弟 2024-11-15 07:21:25

您应该只进行转储/恢复。主/从设置将不起作用,因为从属将处于只读状态。有两种方法可以做到这一点:

1) 通过 - 删除数据库c 标志,然后通过 psql 恢复:

pg_dump -c ... | psql some_host dba_user staging_db

2 )加载到临时数据库,然后执行 ALTER DATABASE ... RENAME至

pg_dump ... | psql -c some_host dba_user staging_db_tmp
# In psql while connected to template1 (and no one is connected to prod):
ALTER DATABASE staging_db RENAME TO staging_db_tmp;
ALTER DATABASE staging_db_tmp RENAME TO staging_db;

无论哪种情况,编写脚本都很容易。查看 psql 的“-1”或“--single-transaction”命令。

You should only do a dump/restore. A master/slave setup will not work because the slave will be in a read-only state. There are two ways you could do this:

1) Drop the database via the -c flag, then restore via psql:

pg_dump -c ... | psql some_host dba_user staging_db

2) Load in to a temporary database, then do a ALTER DATABASE ... RENAME TO.

pg_dump ... | psql -c some_host dba_user staging_db_tmp
# In psql while connected to template1 (and no one is connected to prod):
ALTER DATABASE staging_db RENAME TO staging_db_tmp;
ALTER DATABASE staging_db_tmp RENAME TO staging_db;

In either case, they're pretty easy to script. Look at the '-1' or '--single-transaction' command for psql.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文