11

假设有 3 个数据库

  • 生产
  • 分期
  • 开发

据我所知，暂存数据库需要与生产数据库同步但是，

当我们在开发时，我们可以对Dev数据库做任何我们想做的事情并改变模式。现在来了鸡和蛋的问题。

要在 Staging 中进行测试，需要根据在 Dev 数据库中所做的更改来更改Staging数据库架构。但是暂存数据库需要与生产同步。

你们如何解决这个问题？

4

5 回答 5

9

您需要将所有对 dev 数据库的更改编写为按特定顺序运行的 SQL 迁移脚本。除非在脚本中，否则不要更改数据库结构。不要更新、插入或删除任何行，除非它在脚本中。

理想情况下，有一种方法可以跟踪针对您找到的任何版本的数据库运行了哪些脚本。

然后您可以按如下方式更新阶段。

  • 转储生产数据库
  • 使用生产转储填充阶段数据库
  • 在阶段运行迁移
  • 检查迁移工作（单元测试，手动检查）

一旦一切正常...

  • 使用 mysqldump 命令转储 prod 数据库（因为它可能已更改）在服务器上保留备份
  • 在产品上运行迁移
  • 测试迁移已在 prod 上工作
  • 喝啤酒（一边看错误日志）
于 2009-01-16T22:48:47.633 回答
5

暂存需要与生产同步，直到您部署新更改为止。

或者创建一个名为 Test 的第四个环境，在该环境中验证新的升级。我们称之为 UAT/Test，它通常是 Staging 服务器上的第二个数据库。

确切的方法将取决于您如何保持同步。你真的在使用复制吗？还是只是将 Prod 备份/恢复到 Stage？

于 2009-01-16T18:54:00.070 回答
1

“暂存数据库需要与生产同步”不正确。

生产模式（“设计”）与暂存模式同步。舞台在先，生产在后。

有时人们将生产数据转移到暂存区以帮助测试，但这可能很危险，具体取决于您所在的行业。

分期是“纯粹的”。

通过将真实数据放入纯暂存模式中，生产是从暂存构建的。

有些人做的是有两个数据库。

今天#1 是生产，#2 是登台。

明天我们计划对架构进行更改。我们将#2 升级为新设计。然后我们将数据从#1 移动到#2。

然后，当我们完成移动数据时，我们切换应用程序软件以使用#2 作为生产。

我们将#2 作为生产运行，直到进行下一次更改。

于 2009-01-16T18:56:25.480 回答
1

我们仅使用我们的暂存数据库来测试我们的部署机制。它与生产相匹配。

我们在开发中创建我们的更改，并定期将它们部署到 QA。一旦我们准备好投入生产，我们会将所有更改汇总到一个发布包中。该发布包首先在暂存时进行测试，然后如果没有部署问题，则将其推送到生产环境。

于 2009-01-16T18:57:17.133 回答
1

如果您负担得起添加测试环境，您可能需要考虑这一点。

否则，您基本上需要在您的开发环境中进行测试。直到您对发布有足够的信心，您可以在暂存环境中进行架构更改。进行频繁的备份并有一个良好的回滚过程，这样如果在将架构更改推送到暂存时出现问题，您总是可以回滚。

此外，比较数据库模式的好工具是SqlCompare。在推送架构更改之前，您应该始终使用类似的东西。

于 2009-01-16T18:58:22.357 回答