MySQL同步 - 寻找针对此特定方案的建议

Question

我们经常遇到这种情况：

• 我们有关于制作的数据库。
• 我们意识到（或客户端请求）架构更改。
• 我们在当地进行更改。
• 我们需要上传新架构而不会丢失数据。

---

对于我到目前为止所读到的内容，我注意到我们可以：

• 使用GUI进行同步。
• 使用某种subversion来跟踪数据库更改。
• 创建数据库表以跟踪更改。
• 部署时使用某种自动化任务（我相信bash流程？）。

GUI是一种很好的方法，因为它是一种简单的方法。 但不是自动化的，我们无法恢复到之前的“版本”。

Subversion我们可以获得不同版本的数据库模式。 但理解和创建一个工作流程非常复杂，工作流程可以包含一方的架构，另一方面的数据。

SQL表方法似乎很难理解我甚至看不到那里的好坏部分。

bash自动化任务似乎是一种非常好的方法，因为如果配置得当，它可以很好地进入部署工作流程。但似乎我们无法控制旧版本的数据库。

---

说实话，我没有看到在任何颠覆系统下拥有数据库的重要需求，因为希望它不是我们每天都在改变的东西，就像我们应用程序中的其他文件一样。

有了这一切，我倾向于搜索一个bash进程，在部署时可以做两件事：

1. 从生产服务器检索数据。 （因为它将存在最多的更新数据。）

2. 使用本地模式更新远程模式。 （因为它是本地的，我们将首先更改我们的架构。）

你怎么看？你有什么建议？有没有一种标准的方法可以解决这个问题（在我看来）常见的情况？

Answer 1

我最喜欢的是Ruby on Rails用于数据库迁移的一般方法。在rails中，您可以创建一个使用特定于域的语言的迁移文件。但是，这个想法是每个迁移都有一个版本号。此外，每次迁移都包括实现和回滚步骤。最后，执行迁移时，将更新标识架构版本的数据库中的本地表，以标识数据库的当前版本。这些迁移文件将被检入源代码管理中。

因此，我建议您执行以下操作：

1. 为每个架构更改创建架构更改实施和回滚脚本
2. 为这些脚本提供版本号
3. 每个脚本都应验证数据库当前是否为预期版本，以确保以正确的顺序执行架构更改
4. 创建一个主脚本，询问当前版本的数据库，接受所需的数据库版本，并执行正确的实现或回滚脚本以使数据库架构达到该版本

因此，如果数据库当前是版本14，并且您使用所需的版本17调用主脚本，它将知道执行版本15,16和17的架构更改脚本。如果数据库当前是15并且所需版本为12，它将知道执行版本15,14和13的回滚脚本。

所有这些脚本都应该检查到源代码管理中。