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

Open
opened 3 years ago by RealET · 18 comments
RealET commented 3 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 3 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 2 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.
Collaborator

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.
Collaborator

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 ;-)
Owner

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**

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
Sign in to join this conversation.
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.