2014-09-26 33 views
0

我现在正在使用PostgreSQL几个月。现在,我们通常使用实时数据库来处理几乎所有事情(在实时数据库表中创建新列,执行更新和插入查询等)。但是现在我们想要活下去,我们必须以不同的方式做事。最好的方法是拥有测试数据库和实时数据库。PostgreSQL在线和测试数据库

现在我创建了一个实时数据库的副本,所以我们有一个测试数据库来运行测试。问题在于数据在24小时后仍然旧,所以我们实际上需要每24小时创建一次全新的副本,这对于手动操作来说并不聪明。

所以我的问题是,是否有人在这里谁知道一个正确的方法来处理这个问题?

我认为最理想的方法是: - 将实时数据库中的表格选择复制到测试数据库(跳过表格,如用户)。 - 可以添加列,重命名它们,甚至删除它们,当我们部署新版本的网站时,将这些更改从测试数据库传输到实时数据库(净necassary,但是会是一个很好的功能)。

+1

使用您确实为实时系统实施的备份/恢复功能,每天在半夜恢复测试系统一次。 – 2014-09-26 15:36:11

+0

我刚刚在dba.SE上回答了一个非常类似的问题。见http://dba.stackexchange.com/q/77711/7788 – 2014-09-26 16:44:41

回答

0

如果你的数据库结构正在改变,你可以做不是想自动。你吹走开发工作和数据。你想要它手动。


我曾经管理一个团队,也有类似的情况:多的TiB数据库,每日更新,并需要做测试和开发针对了最新数据。这是我们解决它的方式:

在我们的数据库中,我们定义了一个函数,称为TODAY()。在我们的现场系统中,这是一个NOW()的包装。在我们的测试系统中,它调用了一个只有一行是我们可以设置的日期的单列表。这意味着我们的测试系统是一个时间机器,可以假装任何日期是当前的。

这意味着我们写的每个函数或过程都必须具有时间意识。我应该关心未来计划的事件吗?未来有多远?这使得我们的功能非常强大,并且使它变得非常简单,可以根据各种各样的历史数据进行测试。这有助于捕获大量我们从未想过会发生的错误,但我们看到确实发生在我们的历史数据中。这就像数据库的函数式编程!

我们仍然会安排大约每个月左右的实时备份数据库更新。这有更多的数据和测试我们的备份/恢复程序的好处。我们的DBA会运行一个“测试后同步”脚本,为开发人员设置权限,所以我们肯定比我们在测试系统上运行的任何东西都能在活动中工作。这是帮助我们构建部署数据库脚本的原因。

+0

谢谢你的明确答案。所以你在哪里编写使用TODAY()而不是NOW()的脚本。在您的实时数据库中,TODAY()仅仅是NOW()的包装,而在您的测试数据库中,TODAY()函数只是另一个日期?你还可以设置日期范围吗?这确实是一个很好的解决方案 – 2014-10-01 11:55:43