我们经常遇到这样的场景:
- 我们有关于生产的数据库。
- 我们意识到(或客户请求)架构更改。
- 我们在本地进行更改。
- 我们需要在不丢失数据的情况下上传新架构。
到目前为止，我注意到我们可以:
- 使用 GUI 进行同步。
- 使用某种颠覆来跟踪数据库更改。
- 创建一个数据库表来跟踪变化。
- 在部署时使用某种自动化任务(我相信 bash 过程？)。
GUI 是一种很好的方法，因为它是一种简单的方法。 但不是自动化的，我们无法恢复到以前的“版本”。
Subversion 我们可以获得不同版本的数据库模式。 但是理解和创建一个可以在一侧包含架构而在另一侧包含数据的工作流非常复杂。
SQL 表的方法似乎很难理解，我什至看不到那里的好与坏。
bash 自动化任务似乎是一种非常好的方法，因为如果配置得当，它可以很好地进入部署工作流程。但似乎我们无法控制旧版本的数据库。
说实话，我认为在任何 Subversion 系统下都没有如此重要的需求，因为希望它不是我们每天都更改的东西，就像我们应用程序中的其他文件一样。
有了这一切，我倾向于寻找一个 bash 进程，它可以在部署时做两件事:
从生产服务器检索数据。 (因为它将存在最多更新数据的地方。)
用本地模式更新远程模式。 (因为我们首先会在本地更改架构。)
你怎么看？你有什么建议？是否有处理这种(在我看来)常见情况的标准方法？
最佳答案
我最喜欢的是 Ruby on Rails 用于数据库迁移的一般方法。在 Rails 中，您创建一个迁移文件，它使用特定领域的语言。但是，想法是每个迁移都有一个版本号。此外，每个迁移都包括实现和回滚步骤。最后，当执行迁移时，数据库中标识模式版本的本地表将更新以标识数据库的当前版本。这些迁移文件已 checkin 源代码管理。
因此，我建议执行以下操作:
- 为每个模式更改创建模式更改实现和回滚脚本
- 给这些脚本一个版本号
- 每个脚本都应验证数据库当前是否为预期版本，以确保以正确的顺序执行架构更改
- 创建一个主脚本来查询当前版本的数据库，接受所需的数据库版本，并执行适当的实现或回滚脚本以使数据库架构达到该版本
因此，如果数据库当前是版本 14，并且您使用所需的版本 17 调用主脚本，它将知道执行版本 15、16 和 17 的架构更改脚本。如果数据库当前是 15 并且所需的版本是 12，它将知道执行版本 15、14 和 13 的回滚脚本。
所有这些脚本绝对应该 checkin 源代码管理。
关于MySQL 同步 - 寻找针对此特定场景的建议，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5530772/