Pouvoir utiliser InnoDB à la place de MyISAM (patch) #4277

Closed
opened 4 years ago by RealET · 34 comments
RealET commented 4 years ago

Bonjour,

Contexte : 3 serveurs MySQL avec réplication des bases depuis chaque serveur vers les autres (pas de notion esclave/maître).
Ça ne marche pas car la réplication nécessite des bases au format InnoDB.
Or SPIP dans ecrire/req/mysql.PHP indique explicitement que la création des tables utilise le moteur MyISAM.
Ligne 702 (en 3.2.3), le type de moteur mysql est en dur :

Proposition : utiliser un define par défaut à MyISAM pour pouvoir déclarer l'usage d'un autre moteur de base MySQL.

Résolution : patch ci-joint (testé avec SPIP 3.2.3).
J'ai regardé le code de SPIP 3.3 : c'est le même, donc patch applicable de la même manière.

Merci d'avance ;-)

Bonjour, *Contexte* : 3 serveurs MySQL avec réplication des bases depuis chaque serveur vers les autres (pas de notion esclave/maître). Ça ne marche pas car la réplication nécessite des bases au format InnoDB. Or SPIP dans ecrire/req/mysql.PHP indique explicitement que la création des tables utilise le moteur MyISAM. Ligne 702 (en 3.2.3), le type de moteur mysql est en dur : ```. " ENGINE=MyISAM" ``` *Proposition* : utiliser un define par défaut à MyISAM pour pouvoir déclarer l'usage d'un autre moteur de base MySQL. *Résolution* : patch ci-joint (testé avec SPIP 3.2.3). J'ai regardé le code de SPIP 3.3 : c'est le même, donc patch applicable de la même manière. Merci d'avance ;-)
Poster

Remarque : FullText fonctionne avec

  • MySQL depuis la version 5.6
  • MariaDB depuis la version 10.0.15
Remarque : FullText fonctionne avec * MySQL depuis la version 5.6 * MariaDB depuis la version 10.0.15

+1

+1
b_b commented 4 years ago
Owner

Version cible 3.3 amha, on verra ensuite s'il faut reporter. Des avis à propos du patch ?
Version cible mise à 4.0
Statut changé à En cours

Version cible 3.3 amha, on verra ensuite s'il faut reporter. Des avis à propos du patch ? **Version cible mise à 4.0** **Statut changé à En cours**
Poster

Bonjour,

Pour info, une quarantaine de sites de l'académie de Rennes tournent avec ce patch en 3.2.4.

;-)

Bonjour, Pour info, une quarantaine de sites de l'académie de Rennes tournent avec ce patch en 3.2.4. ;-)
Poster

Maintenant, c'est 200...

Maintenant, c'est 200...
b_b commented 3 years ago
Owner

Pour info, chez un hébergeur associatif on utilise aussi mariadb en mode cluster avec innodb et le SPIP que je viens d'y installer a bien toutes ses tables en innodb. J'ai vérifié sur mon serveur local, idem les tables des bases de mes SPIP sont toutes en innodb. Il semble donc que l'instruction ENGINE=MyISAM peut être ignorée par le serveur, et que dans ce cas le define ne serait pas utile ?

Pour info, chez un hébergeur associatif on utilise aussi mariadb en mode cluster avec innodb et le SPIP que je viens d'y installer a bien *toutes* ses tables en innodb. J'ai vérifié sur mon serveur local, idem les tables des bases de mes SPIP sont toutes en innodb. Il semble donc que l'instruction ENGINE=MyISAM peut être ignorée par le serveur, et que dans ce cas le define ne serait pas utile ?
Poster

Effectivement, si c'est possible, le define ne serait pas utile.
Mais est-ce que tu pourrais indiquer quel est le paramètre MariaDB à modifier pour avoir ce comportement ?

Et pour en revenir au define, c'est vraiment un truc sans risque, non ?

Effectivement, si c'est possible, le define ne serait pas utile. Mais est-ce que tu pourrais indiquer quel est le paramètre MariaDB à modifier pour avoir ce comportement ? Et pour en revenir au define, c'est vraiment un truc sans risque, non ?
Owner

J’allais dire attention avec Innodb et Fulltext, mais en fait c’est pris en compte depuis mysql 5.6 & mariadb 10… donc je dis rien :)
Y a pas un autre ticket qui disait que ça serait bien Innodb par défaut ?

J’allais dire attention avec Innodb et Fulltext, mais en fait c’est pris en compte depuis mysql 5.6 & mariadb 10… donc je dis rien :) Y a pas un autre ticket qui disait que ça serait bien Innodb par défaut ?
Owner

Une vieille histoire : #2727
Sachant que Fulltext est pris en compte sur Innodb, je vois pas trop ce qui nous retiendrait à utiliser MyISAM en fait encore (à part l’espace disque ?).
Innodb semble être devenu la norme sous mysql.

Une vieille histoire : #2727 Sachant que Fulltext est pris en compte sur Innodb, je vois pas trop ce qui nous retiendrait à utiliser MyISAM en fait encore (à part l’espace disque ?). Innodb semble être devenu la norme sous mysql.
Owner

Salut

Vu que spip est agnostique sur le moteur mysql, on devrait laisser au serveur de gérer de lui même le moteur.
Le patch serait simplement enlever la règle ENGINE.

Salut Vu que spip est agnostique sur le moteur mysql, on devrait laisser au serveur de gérer de lui même le moteur. Le patch serait simplement enlever la règle ENGINE.
Owner

Tester sur un serveur strech avec mariadb 10.1 avec les configurations autorisant les index long via SET global.innodb_large_prefix = 1; et set global.innodb_default_row_format=dynamic;

Si on laisse le moteur myisam une montée de version depuis 1.9.2 ne fonctionne pas, par exemple le plugin url_etendues utilsent des index long. Avec la configuration par défaut, la table sera créé en myisam ce qui sera refusé. En laissant le serveur gérer de lui même le moteur, cela fonctionne.

La PR est sur : #29

Tester sur un serveur strech avec mariadb 10.1 avec les configurations autorisant les index long via SET ``global.innodb_large_prefix = 1; et set ``global.innodb_default_row_format=dynamic; Si on laisse le moteur myisam une montée de version depuis 1.9.2 ne fonctionne pas, par exemple le plugin url_etendues utilsent des index long. Avec la configuration par défaut, la table sera créé en myisam ce qui sera refusé. En laissant le serveur gérer de lui même le moteur, cela fonctionne. La PR est sur : https://git.spip.net/spip/spip/pulls/29
Poster

marcimat 🌻 a écrit :

Une vieille histoire : #2727
Sachant que Fulltext est pris en compte sur Innodb, je vois pas trop ce qui nous retiendrait à utiliser MyISAM en fait encore (à part l’espace disque ?).
Innodb semble être devenu la norme sous mysql.
Il y a une chose qui peut retenir : la version de MySQL ou MariaDB pour Gis qui a besoin de Spacial-index qui ne sont pas disponibles avant :

marcimat 🌻 a écrit : > Une vieille histoire : #2727 > Sachant que Fulltext est pris en compte sur Innodb, je vois pas trop ce qui nous retiendrait à utiliser MyISAM en fait encore (à part l’espace disque ?). > Innodb semble être devenu la norme sous mysql. Il y a une chose qui peut retenir : la version de MySQL ou MariaDB pour Gis qui a besoin de Spacial-index qui ne sont pas disponibles avant : - https://mariadb.com/kb/en/spatial-index/ MariaDB 10.2.2 - https://mysqlserverteam.com/geographic-indexes-in-innodb/ MySQL 5.7 (si j'ai bien lu)
Poster

Une remarque un peu hors sujet : avec l'académie de Rennes, il y a donc plus de 200 sites qui tournent avec ce patch.

Tant que nous utilisions svn up, le merge se faisait automatiquement et conservait le patch.

Avec le passage à git où git pull ne conserve pas les modifications locales, il va nous falloir trouver autre chose.

==> si quelqu'un a déjà une méthode pour conserver un patch local lors d'un checkout, ça m'intéresse ;-)

Une remarque un peu hors sujet : avec l'académie de Rennes, il y a donc plus de 200 sites qui tournent avec ce patch. Tant que nous utilisions svn up, le merge se faisait automatiquement et conservait le patch. Avec le passage à git où git pull ne conserve pas les modifications locales, il va nous falloir trouver autre chose. ==> si quelqu'un a déjà une méthode pour conserver un patch local lors d'un checkout, ça m'intéresse ;-)

faut changer vos mises à jour à minima : git stash, git pull origin master, git stash pop… c'est tout ça fera le merge pareil si aucun conflit

faut changer vos mises à jour à minima : git stash, git pull origin master, git stash pop… c'est tout ça fera le merge pareil si aucun conflit
Owner

On vient de découvrir un truc avec Rastapopoulos : innodb en mysql8 a par défaut les tables en utf8mb4, et les varchar semblent limités à 191 caractères, au lieu de 255 !
Ça sent un piège à venir : https://stackoverflow.com/a/31474509
J'en cause pour pas oublier, parce qu'on a des déclarations abondantes de varchar(255) dans SPIP et les plugins, avec des index dessus.

On vient de découvrir un truc avec Rastapopoulos : innodb en mysql8 a par défaut les tables en utf8mb4, et les varchar semblent limités à 191 caractères, au lieu de 255 ! Ça sent un piège à venir : https://stackoverflow.com/a/31474509 J'en cause pour pas oublier, parce qu'on a des déclarations abondantes de varchar(255) dans SPIP et les plugins, avec des index dessus.
Poster

Pour utf8mb4 et index, voir aussi : #4342

Pour utf8mb4 et index, voir aussi : #4342
Owner

cf donc aussi #29
et je repousse à 4.1
Version cible mise à 4.1

cf donc aussi https://git.spip.net/spip/spip/pulls/29 et je repousse à 4.1 **Version cible mise à 4.1**
Collaborator

lors de l'import de redmine, le patch de RealET n'a pas été transféré, le voici.
Par contre, j'ai du le zipper, sinon l'extension patch n'est pas acceptée

lors de l'import de redmine, le patch de RealET n'a pas été transféré, le voici. Par contre, j'ai du le zipper, sinon l'extension patch n'est pas acceptée
Owner
https://discuter.spip.net/t/alwaysdata-installation-de-spip-4/158032/7

Plutôt que graver en dur une option qui n'est pas toujours la bonne, serait il possible de basiquement permettre au webmestre-qui-sait d'indiquer le moteur à utiliser ?

Plutôt que graver en dur une option qui n'est pas toujours la bonne, serait il possible de basiquement permettre au webmestre-qui-sait d'indiquer le moteur à utiliser ?
Owner

Plutot que de recommencer éternellement la même discussion (ou alors c'est le jour de la marmotte ?) serait-il possible de proposer une PR complète ?
#29

Plutot que de recommencer éternellement la même discussion (ou alors c'est le jour de la marmotte ?) serait-il possible de proposer une PR complète ? https://git.spip.net/spip/spip/pulls/29

#5166 est un merge du patch de realet et de #29

#5166 est un merge du patch de realet et de #29
Owner

tu as lu la PR #29 dans son ensemble ?

je refais pas la discussion ici. Si le patch c'était juste de changer la ligne de déclaration mysql on aurait intégré depuis longtemps. Mais ensuite il y a des problèmes à régler en innodb, tout ça a été longuement expliqué dans #29, mais personne à fini le travail pour que ce soit propre.

tu as lu la PR #29 dans son ensemble ? je refais pas la discussion ici. Si le patch c'était juste de changer la ligne de déclaration mysql on aurait intégré depuis longtemps. Mais ensuite il y a des problèmes à régler en innodb, tout ça a été longuement expliqué dans #29, mais personne à fini le travail pour que ce soit propre.

C'est pas l'idéal de permettre au webmestre de choisir entre 2 solutions qui ne sont pas idéales dans tous les cas, mais c'est mieux que de lui en imposer une qui peut ne pas du tout convenir et carrément empêcher d'installer spip - par exemple sur alwaysdata.

C'est pas l'idéal de permettre au webmestre de choisir entre 2 solutions qui ne sont pas idéales dans tous les cas, mais c'est mieux que de lui en imposer une qui peut ne pas du tout convenir et carrément empêcher d'installer spip - par exemple sur alwaysdata.
Owner

C'est pas l'idéal d'avoir des PR qui échangent un bug pour un autre au pretexte de "au moins ça résout mon problème, débrouillez vous avec l'autre bug", parce qu'au final, il va bien falloir que quelqu'un se fade le correctif complet.

On discute sur le sujet depuis 2 ans, et ça semble une tâche insurmontable que de tester proprement et corriger les cas où l'utilisation d'une base innodb provoque des erreurs ou warning...

Donc on en est toujours au même point, et ta nouvelle PR ne fait rien avancer

C'est pas l'idéal d'avoir des PR qui échangent un bug pour un autre au pretexte de "au moins ça résout mon problème, débrouillez vous avec l'autre bug", parce qu'au final, il va bien falloir que quelqu'un se fade le correctif complet. On discute sur le sujet depuis 2 ans, et ça semble une tâche insurmontable que de tester proprement et corriger les cas où l'utilisation d'une base innodb provoque des erreurs ou warning... Donc on en est toujours au même point, et ta nouvelle PR ne fait rien avancer

À part les avertissements dans la page spip pour "repair" les tables, je vois pas de problème ni "d'autre bug".

À part les avertissements dans la page spip pour "repair" les tables, je vois pas de problème ni "d'autre bug".
Owner

oui il y a "juste ça" à faire, et si la PR ne le fait pas il faudra bien que quelqu'un le fasse...

oui il y a "juste ça" à faire, et si la PR ne le fait pas il faudra bien que quelqu'un le fasse...

Est-ce que c'est l'absence de ce repair qui est gênant pour les tables innodb ou bien l'affichage d'un avertissement qui peut faire peur alors que tout va bien ? Selon, il faut trouver un succédané ou juste arrêter de faire peur.

Déjà, admin_repair_tables() ne fait le repair QUE « si le serveur SQL l'accepte. » (cf phpdoc).

On peut étendre cette restriction et ne faire le repair que « si le serveur SQL l'accepte et que le type de la table le permet ». Et donc tester le type de la table reçue dans spip_mysql_repair

C'est cela ?

Si non, on peut émuler un repair pour innodb. Repair Innodb_table suggère un succédané :

create table <new_table> like <old_table>;
insert <new_table> select * from <old_table>;
truncate table  <old_table>;
insert <old_table> select * from <new_table>;

Ou bien

create_table <new_table> like <old_table>;
insert <new_table> select * from <old_table>;
drop table  <old_table>;
create table <old_table> like <new_table>;
insert <old_table> select * from <new_table>;

Mais on pourrait aussi :

create table <new_table> like <old_table>;
insert <new_table> select * from <old_table>;
drop table  <old_table>;
rename table <new_table> <old_table>;

qui pourraient s'appliquer en vérifiant que chaque étape se passe bien pour éviter de perdre une table...

Est-ce que c'est l'absence de ce repair qui est gênant pour les tables innodb ou bien l'affichage d'un avertissement qui peut faire peur alors que tout va bien ? Selon, il faut trouver un succédané ou juste arrêter de faire peur. Déjà, `admin_repair_tables()` ne fait le repair QUE « si le serveur SQL l'accepte. » ([cf phpdoc](https://git.spip.net/spip/spip/src/branch/master/ecrire/base/repair.php#L59)). On peut étendre cette restriction et ne faire le repair que « si le serveur SQL l'accepte et que le type de la table le permet ». Et donc tester le type de la table reçue [dans spip_mysql_repair](https://git.spip.net/spip/spip/src/branch/master/ecrire/req/mysql.php#L883) C'est cela ? Si non, on peut émuler un repair pour innodb. [Repair Innodb_table](https://stackoverflow.com/a/3322930/2897835) suggère un succédané : ``` create table <new_table> like <old_table>; insert <new_table> select * from <old_table>; truncate table <old_table>; insert <old_table> select * from <new_table>; ``` Ou bien ``` create_table <new_table> like <old_table>; insert <new_table> select * from <old_table>; drop table <old_table>; create table <old_table> like <new_table>; insert <old_table> select * from <new_table>; ``` Mais on pourrait aussi : ``` create table <new_table> like <old_table>; insert <new_table> select * from <old_table>; drop table <old_table>; rename table <new_table> <old_table>; ``` qui pourraient s'appliquer en vérifiant que chaque étape se passe bien pour éviter de perdre une table...

J'ai testé la page spip de repair sur 2 de mes sites réels : l'un datant de 5 ans, l'autre datant de 20 ans passé par divers hébergements.

Cette page de repair révèle que ces 2 sites ont un mix de tables InnoDb et Mysam, alors que, pour autant que je m'en souvienne, je n'ai jamais intentionnellement choisi MyIsam ou InnoDb pour ces créations de tables, n'ayant aucune idée de leurs spécificités.

En ne parlant que des tables de spip-core et dist, l'un des sites (le plus ancien) a 2 tables innodb et l'autre en a 7 (le plus récent).

  • Sur les 2 sites, spip_auteurs_liens et spip_mots_liens sont INNODB (mais pas spip_documents_liens ou spip_jobs_liens).
  • Les autres tables InnoDb sur un seul site sont : spip_articles, spip_auteurs, spip_forum, spip_groupes_mots et spip_mots.

Depuis toujours la page de "repair" produit ces avertissements. Il n'y a aucun ticket concernant ces avertissements, et personne à ma connaissance ne s'en est jamais plaint. Ça ne semble pas une nuisance.

Ça montre aussi que depuis toujours SPIP "gère" les tables InnoDb (et peut être aussi en "génère" ?)

J'ai testé la page spip de repair sur 2 de mes sites réels : l'un datant de 5 ans, l'autre datant de 20 ans passé par divers hébergements. Cette page de repair révèle que ces 2 sites ont un mix de tables InnoDb et Mysam, alors que, pour autant que je m'en souvienne, je n'ai jamais intentionnellement choisi MyIsam ou InnoDb pour ces créations de tables, n'ayant aucune idée de leurs spécificités. En ne parlant que des tables de spip-core et dist, l'un des sites (le plus ancien) a 2 tables innodb et l'autre en a 7 (le plus récent). - Sur les 2 sites, `spip_auteurs_liens` et `spip_mots_liens` sont `INNODB` (mais pas `spip_documents_liens` ou `spip_jobs_liens`). - Les autres tables `InnoDb` sur un seul site sont : `spip_articles`, `spip_auteurs`, `spip_forum`, `spip_groupes_mots` et `spip_mots`. Depuis toujours la page de "repair" produit ces avertissements. Il n'y a aucun ticket concernant ces avertissements, et personne à ma connaissance ne s'en est jamais plaint. Ça ne semble pas une nuisance. Ça montre aussi que depuis toujours SPIP "gère" les tables InnoDb (et peut être aussi en "génère" ?)
Owner

Si non, on peut émuler un repair pour innodb. Repair Innodb_table suggère un succédané :

Plus simple cf #29 :)

> Si non, on peut émuler un repair pour innodb. [Repair Innodb_table](https://stackoverflow.com/a/3322930/2897835) suggère un succédané : Plus simple cf https://git.spip.net/spip/spip/pulls/29#issuecomment-5155 :)
Owner

Donc, je viens de poster #5177 dans laquelle je reprends l'introduction d'un define _MYSQL_ENGINE comme dans #5166 avec en plus l'adaptation de spip_mysql_repair() afin qu'elle prenne en charge les tables myisam & innodb (et si l'engine est un autre on log qu'on ne sait pas faire).

Donc, je viens de poster #5177 dans laquelle je reprends l'introduction d'un define `_MYSQL_ENGINE` comme dans #5166 avec en plus l'adaptation de `spip_mysql_repair()` afin qu'elle prenne en charge les tables myisam & innodb (et si l'engine est un autre on log qu'on ne sait pas faire).
Owner

du coup @JLuc et @RealET puisque le sujet vous tient à coeur vous avez testé la PR ?

du coup @JLuc et @RealET puisque le sujet vous tient à coeur vous avez testé la PR ?
marcimat closed this issue 5 months ago
marcimat closed this issue 5 months ago
marcimat referenced this issue from a commit 5 months ago
marcimat referenced this issue from a commit 5 months ago
Poster

Bonjour @cerdic,

Je viens de tester en rajoutant dans config/mes_options.php :
define('_MYSQL_ENGINE', 'InnoDB')
et en ayant switché sur issue_4277_bis (b35b895915)

Tests faits :

  • Installation de SPIP OK avec toutes les tables en InnoDB.
  • ecrire/?exec=base_repair : Ok (à noter qu'en lisant le code, je vois qu'avec InnoDB, le résultat est soit 'OK', soit rien de spécifié explicitement ; et que par ailleurs, je n'avais pas de base corrompue, donc je ne sais pas ce que ça fait si c'est corrompu)
  • Installation du plugin FullText : OK
  • Installation de SoyezCréateurs qui nécessite 32 plugins supplémentaires : OK

Bref, pour autant que je puisse le dire, ça me semble tout à fait fonctionnel.

Bravo @b_b

Bonjour @cerdic, Je viens de tester en rajoutant dans config/mes_options.php : `define('_MYSQL_ENGINE', 'InnoDB')` et en ayant switché sur issue_4277_bis (https://git.spip.net/spip/spip/commit/b35b89591595a55d3b4813844f6dbf1ab9396d57) Tests faits : * Installation de SPIP OK avec toutes les tables en InnoDB. * ecrire/?exec=base_repair : Ok (à noter qu'en lisant le code, je vois qu'avec InnoDB, le résultat est soit 'OK', soit rien de spécifié explicitement ; et que par ailleurs, je n'avais pas de base corrompue, donc je ne sais pas ce que ça fait si c'est corrompu) * Installation du plugin FullText : OK * Installation de SoyezCréateurs qui nécessite 32 plugins supplémentaires : OK Bref, pour autant que je puisse le dire, ça me semble tout à fait fonctionnel. Bravo @b_b
Owner

merci du retour.

merci du retour.
Sign in to join this conversation.
No Milestone
No project
No Assignees
9 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.