mysql - 数据库架构变更 | MySQL 事务性 DDL 语句

Question

持续交付

我正在为关系存储构建一个带有 MySQL 数据库的应用程序。应用程序被设计为持续交付，为此，应用程序数据库必须就地升级。

基本方法

1. Application -> Transactional Statements -> DB -> Table View (Schema Version) -> Table

单个数据库用于所有应用程序版本。最新的模式版本定义了真实的表结构，以前的模式版本通过模拟以前模式的 TableView 来支持。

2. Application -> Transactional Statements -> DB (Schema Version) -> Table

发布新模式时，将复制数据库并将模式更改应用于新数据库。启动流程后旧数据库上的事务将被跟踪并应用于新数据库。

升级完成后(所有应用程序部署都已切换到新架构)，旧数据库将被转储。

首选选项 1

选项 2 在技术上很简单，因为不需要修改事件数据库的架构。但是，如果数据库增长到相当大的规模，那么资源消耗将变得巨大；因此，这种方法可以支持的应用程序大小存在实际限制。

因此，选项 1 更可取，但它提出了应用事务性 DDL 语句的问题。

事务性DDL语句策略

如何在不冒数据损坏或应用程序访问数据库能力中断的风险的情况下修改数据库表和相应的 TableView ？

我目前的想法是按如下方式处理更改:

1. Apply creations and additions
   1. create new tables
   2. create new columns
2. Apply column renaming
   1. Lock table view (and, by extension, the base tables)
   2. Rename column
   3. Modify table view to use the new target column name
   4. Unlock table view
3. Apply table renaming
   1. Lock table view (and, by extension, the base tables)
   2. Rename base table
   3. Modify table view to use new base table name
   4. Unlock table view

从那里，将创建新的架构 TableView ，以便在部署下一个架构更改时可以使用相同的策略。

注意:任何已删除的列或表都将在转换期间保留，但将被重命名以附加 _deprecate 或其他一些标识后缀

问题

据我了解，事务性 DDL 语句在 MySQL 中不可能，因为这些语句会触发隐式提交。 这是正确的吗？

我上面描述的选项 1 方法是否有效？

具体来说，我有两个顾虑:

1. 表锁导致应用程序中断。这里唯一的问题是单个表锁持续时间太长以至于等待连接超时吗？如果是这样，这应该可以通过在应用程序暂存期间测试每个表锁定的持续时间来管理。

2. 回滚 我显然没有这种安排的自动回滚。但是，我所需要的只是将对基表的任何修改与对 TableView 的更改进行镜像。 是否可以在单个事务中对基表和 TableView 应用更改？如果不能，我将不得不在部署架构更改之前进行非常彻底的测试。

Answer 1

MySQL 不支持事务性 DDL，而且可能永远不会。

你可以使用 different虽然数据库。

您可以使用 liquibase 并处理您的 rollbacks手动。