无痛的数据库架构更改答案

【问题标题】：Painless database schema changes无痛的数据库架构更改
【发布时间】：2012-01-22 11:25:15
【问题描述】：

看到这个：Need a better way to manage database schema changes

可以为 MySQL 做些什么？

现在，如果有架构更改，我必须暂时取消 prod，查看差异，手动应用更改，然后运行数据迁移/转换脚本。

很想知道是否有可以减轻痛苦的方法/工具。

【问题讨论】：

试试 liquibase：liquibase.org

标签： mysql database deployment schema

【解决方案1】：

为什么不在更新脚本中累积对开发模式的更改，然后在下一个版本中运行该脚本。

确实有不同的模式比较工具，但在我看来，它们应该只用于检查更新脚本是否正确，而不是生成脚本。

在发布时，您应该将生成新架构的脚本和更新脚本作为空提交到版本控制系统。

假设这是您的架构：

-- schema.sql
CREATE TABLE t1 (
  `t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `t_data` VARCHAR(45) NOT NULL,
  PRIMARY KEY (`t_id`)
) ENGINE = InnoDB COLLATE utf8_feneral_ci;

提交 1

现在您的生产表中有大量重复数据，您想进行一些规范化：

将不同的数据放到单独的表中
在 t1 表中使用引用：

脚本：

-- updates.sql
CREATE TABLE t2 (
  `d_hash` CHAR(32) NOT NULL COLLATE ascii_general_ci,
  `t_data`  VARCHAR(45) NOT NULL,
  PRIMARY KEY (`d_hash`)
) ENGINE = InnoDB COLLATE utf8_general_ci;

ALTER TABLE t1
  ADD COLUMN `d_hash` CHAR(32)COLLATE ascii_general_ci AFTER `t_data`;

UPDATE t1 SET d_hash = MD5(UPPER(t_data));

INSERT IGNORE INTO t2 (t_data, d_hash)
SELECT t_data, d_hash
FROM t1;

ALTER TABLE t1 DROP COLUMN `t_data`,
MODIFY COLUMN `d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
ADD CONSTRAINT `FK_d_hash` FOREIGN KEY `FK_d_hash` (`d_hash`)
REFERENCES `t2` (`d_hash`) ON DELETE CASCADE ON UPDATE CASCADE;

提交 2

发布

-- schema.sql
CREATE TABLE  t1 (
  `t_id` INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
  `d_hash` CHAR(32) COLLATE ascii_general_ci NOT NULL,
  PRIMARY KEY (`t_id`),
  KEY `FK_d_hash` (`d_hash`),
  CONSTRAINT `FK_d_hash` FOREIGN KEY (`d_hash`)
  REFERENCES `t2` (`d_hash`)
    ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB COLLATE utf8_general_ci;

-- updates.sql
-- Empty

提交 3

我想看看一个比较工具，它可以让你做这件事变得更简单。

【讨论】：

我建议调查 flyway 工具来控制升级脚本的执行。

【解决方案2】：

我认为一个好的方法是像更改代码一样更改数据库。将它们置于源代码控制中，并使部署良好且可重复。

我在这类事情上的理念就像 DevOpsWire 上的这种模式：https://web.archive.org/web/20111025093215/http://devopswire.com/patterns/database-changes-as-code

工具方面，看看 DB-Deploy 和 Liquibase 之类的东西。

【讨论】：

第二。将您的数据库更改置于版本控制之下，然后使用 liquibase 或 Flyway 等工具来控制数据库的升级。这些工具是必不可少的，因为它们将确保脚本以正确的顺序运行。在工具推荐方面，我建议为完整起见使用 liquibase，为简单起见建议使用 flyway
devopswire 链接当前被重定向到网络钓鱼攻击（根据 Chrome）。您已收到警告。

【解决方案3】：

Need a better way to manage database schema changes Compare two MySQL databases 上定义的相同方法可以完美运行。

您也可以查看比较相关的帖子here。

更重要的是维护您在暂存或预部署时可能制作的更改脚本并在移至生产时一次性执行它们。

【讨论】：