Как сделать предыдущую миграцию Flyway недействительной в новых версиях БД? - PullRequest
Новая
       16

Как сделать предыдущую миграцию Flyway недействительной в новых версиях БД?

2 голосов
/ 01 мая 2019

Итак, у меня есть миграция с Flyway, успешно примененная много лет назад к более старой версии MariaDB.

Более новая версия MariaDB теперь более строгая и вызывает ошибку при той же миграции. Существует законная проблема с этой миграцией, которую я хочу исправить как для новых запусков с базовой линии (например, сборка в моей среде CI или на ноутбуке нового devleoper), так и для всех моих существующих баз данных (до того, как я попытаюсь обновить их до более новая версия MariaDB, которая может просто потерпеть неудачу).

Какое правильное решение?

  • Измените миграцию и добавьте новую, которая выполняет то же самое исправление (еще одну ALTER TABLE ...), которая фактически будет пустяком для вновь созданных БД, но исправит мои существующие вещи.
  • Добавить новую версию с миграцией, вышедшую из строя, непосредственно перед сломанной, что решает проблему. Надеемся, что это означает, что новые БД будут применяться так же, как и перед прерванной миграцией, а существующие установки будут применять их перед любой из моих новых миграций?

Если говорить точнее, проблема заключалась в том, что я переносил таблицу, которая первоначально использовала ENGINE=MyISAM ROW_FORMAT=FIXED в ENGINE=InnoDB - MariaDB 10.1 принимает это, но более новые выпуски MariaDB, по-видимому, терпят неудачу, если я также не добавлю ROW_FORMAT=DEFAULT.

Базовый 

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

Поздняя миграция 

ALTER TABLE FOO
  ENGINE=InnoDB;

Этот последний оператор не выполняется в более новой версии MariaDB (и, возможно, для MySQL, не уверен?).

Это утверждение работает, хотя: 

ALTER TABLE FOO
  ENGINE=InnoDB ROW_FORMAT=DEFAULT;

Проблема в том, что предыдущий оператор внутренне пытается сделать что-то вроде этого, что не получается: 

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

Ответы [ 2 ]

0 голосов
/ 02 мая 2019

Лучший способ справиться с этим, вероятно, - тщательно изменить миграцию и ввести flyway repair для выравнивания контрольных сумм в базе данных с новыми на диске.

0 голосов
/ 01 мая 2019

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;

Ссылки:

...