Question

因此，我进行了一次Flyway迁移，几年前已成功将其应用于旧版本的MariaDB。

MariaDB的较新版本现在更加严格，并且在相同的迁移上导致错误。我想解决该迁移的合法性问题，以解决从基线开始的新运行（例如，在我的CI环境中构建，或在新的devleoper的便携式计算机上构建）以及所有现有数据库（在尝试将其升级到之前）较新的MariaDB版本，可能会失败）。

什么是正确的解决方案？

更改迁移，并添加一个新的修复程序（另一个ALTER TABLE ...），该操作实际上对于新创建的DB是无效的，但是将修复我现有的数据库。
在损坏的迁移之前，先按顺序添加新的无序迁移版本，以解决此问题。希望这意味着新的数据库将在中断迁移之前应用此功能，而现有安装将在我的任何较新迁移之前应用它吗？

具体来说，问题是我正在将原来使用ENGINE=MyISAM ROW_FORMAT=FIXED的表迁移到ENGINE=InnoDB － MariaDB 10.1接受，但是除非我也添加{ {1}}。

基线

ROW_FORMAT=DEFAULT

以后的迁移

CREATE TABLE FOO ( ... )
   ENGINE=MyISAM ROW_FORMAT=FIXED;

后一个语句在较新的MariaDB版本上失败（可能对MySQL也是不确定的？）。

此语句有效，但是：

ALTER TABLE FOO
  ENGINE=InnoDB;

问题在于，先前的语句在内部尝试执行以下操作，但失败了：

ALTER TABLE FOO
  ENGINE=InnoDB ROW_FORMAT=DEFAULT;

Answer 1

InnoDB没有ROW_FORMAT = FIXED。在旧版本中，变量innodb_strict_mode设置为0，在这种情况下会发出警告，并且在转换时使用ROW_FORMAT = COMPACT。

ALTER TABLE FOO ENGINE=InnoDB;
Query OK, 0 rows affected, 1 warning (0.07 sec)    
Records: 0  Duplicates: 0  Warnings: 1

mysql [localhost] {msandbox} (test) > SHOW WARNINGS;
+---------+------+--------------------------------------+
| Level   | Code | Message                              |
+---------+------+--------------------------------------+
| Warning | 1478 | InnoDB: assuming ROW_FORMAT=COMPACT. |
+---------+------+--------------------------------------+

在较新的版本中，innodb_strict_mode设置为1，因此返回错误。

ALTER TABLE FOO ENGINE=InnoDB;
ERROR 1005 (HY000): Can't create table `test`.`FOO` (errno: 140 "Wrong create options")

您可以在会话期间设置变量0，以复制旧的行为。

set innodb_strict_mode=0;

参考文献：

Answer 2

处理此问题的最佳方法可能是仔细修改迁移并发出flyway repair以将数据库中的校验和与磁盘上的新校验和重新对齐。

Answer 3

将mariadb 10.1设置为严格模式，让我可以在mariadb 10.3上导出和导入数据

错误的创建表选项错误消息消失了。

set innodb_strict_mode=0;

https://mariadb.com/kb/en/innodb-strict-mode/

如何处理以前的Flyway迁移在更新的DB版本中无效？

基线

以后的迁移

3 个答案: