Donc, j'ai une migration Flyway qui s'est appliquée avec succès, il y a des années, à une ancienne version de MariaDB.
Une version plus récente de MariaDB est maintenant plus stricte, et provoque une erreur sur cette même migration. Il y a un problème légitime avec cette migration que je veux résoudre pour les deux nouvelles exécutions à partir de la ligne de base (par exemple, la construction dans mon environnement CI ou sur l'ordinateur portable d'un nouveau devleoper), et pour toutes mes bases de données existantes (avant d'essayer de les mettre une version plus récente de MariaDB, qui risque d'échouer).
Quelle est la bonne solution?
Pour être précis, le problème était que je migrais une table qui utilisait à l'origine ENGINE = MyISAM ROW_FORMAT = FIXED vers ENGINE = InnoDB - MariaDB 10.1 accepte cela, mais les nouvelles versions de MariaDB semblent échouer à moins que j'ajoute également ROW_FORMAT=DEFAULT.
CREATE TABLE FOO ( ... ) ENGINE=InnoDB ROW_FORMAT=FIXED;
ALTER TABLE FOO ENGINE=InnoDB ROW_FORMAT=DEFAULT;
Cette dernière instruction échoue sur une version plus récente de MariaDB (et peut-être aussi pour MySQL, pas sûr?).
Cette instruction fonctionne, cependant:
ALTER TABLE FOO ENGINE=InnoDB;
Le problème est que l'instruction précédente essaie de faire quelque chose comme ça en interne, ce qui échoue:
CREATE TABLE FOO ( ... ) ENGINE=MyISAM ROW_FORMAT=FIXED;
3 Réponses :
InnoDB n'a pas de ROW_FORMAT = FIXED. Dans les anciennes versions, la variable innodb_strict_mode est définie sur 0, auquel cas un avertissement est émis et ROW_FORMAT = COMPACT est utilisé lors de la conversion.
set innodb_strict_mode=0;
Dans les versions plus récentes innodb_strict_mode est défini sur 1, donc une erreur est renvoyée.
ALTER TABLE FOO ENGINE=InnoDB; ERROR 1005 (HY000): Can't create table `test`.`FOO` (errno: 140 "Wrong create options")
Vous pouvez définir la variable 0 pour la durée de la session afin de reproduire l'ancien comportement.
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. |
+---------+------+--------------------------------------+
Références:
Merci, bien que ma question soit plus spécifique sur la façon de gérer cela dans le contexte de Flyway . Je comprends que le comportement autour du "mode strict" a changé, et je veux juste corriger ces migrations passées autrement "immuables" pour qu'elles se comportent correctement dans ce mode strict.
La meilleure façon de gérer cela est probablement de modifier soigneusement la migration et d'émettre une réparation de la voie de migration pour réaligner les sommes de contrôle de la base de données avec les nouvelles sur le disque.
Configurer mariadb 10.1 en mode strict, permettez-moi d'exporter et d'importer les données sur mariadb 10.3
Le mauvais message d'erreur des options de création de table a disparu.
set innodb_strict_mode=0;
Cela ne s'applique pas à mysql - cela implique ROW_FORMAT = DEFAULT si l'option ROW_FORMAT est omise. Par conséquent supprimé la balise mysql.
Je ne suis pas sûr que cela corresponde tout à fait à la situation ici, veuillez consulter mes révisions ci-dessus et me faire savoir si cela vous convient toujours?
Toujours pas de problème sur mysql. La documentation Mysql indique explicitement
Lorsqu'une option ROW_FORMAT n'est pas spécifiée explicitement, ou lorsque ROW_FORMAT = DEFAULT est utilisé, une opération qui reconstruit une table modifie silencieusement le format de ligne de la table au format défini par la variable innodb_default_row_format. L'accent est mis sur le silence, c'est-à-dire pas d'avertissement.