Je fais face à un problème de collation dans ma base de données qui semble être apparu sans raison apparente. Je n’ai pas utilisé de caractères spéciaux ni effectué de modifications récentes qui pourraient expliquer ce problème. Cependant, des erreurs liées à la collation commencent à apparaître : COLLATION ‘utf8_general_ci’ is not valid for CHARACTER SET ‘utf8mb4’
Je pense qu’il pourrait être judicieux de réappliquer les paramètres de collation par défaut pour résoudre ce problème. Cependant, avant de procéder à cette opération, j’aimerais faire un dump de ma base de données. Malheureusement, je n’ai pas accès à la console SQL pour faire tout ça proprement.
Auriez-vous une solution à me proposer à ce niveau là ?
Je suis également curieux de savoir pourquoi ce problème se produit et s’il existe des meilleures pratiques ou des mesures de prévention que je pourrais suivre pour éviter de rencontrer ce problème à l’avenir.
Merci d’avance pour vos éclaircissements et vos conseils.
Pour faire des tests d’égalité “unicode étendu”, il faut que les collations soient homogènes entre vos colonnes : utf8mb4.
Il faut regarder dans le support MySQL comment faire cet ALTER.
Pour avoir un accès SQL pour faire un dump et changer la collation globalement, voyez avec votre support technique / DBA, car nous n’hébergeons pas vos applications.
oui en effet le pb est connu mais cette fois il s’agit d’une instance montée sur l’environnement SIM renault.simplicite.io. Du coup on essaye de solliciter le support
A priori, aucune opération n’a été réalisée sur la couche BD de notre côté; l’instance a été mise en ligne en juillet.
Pour poser un peu de contexte : Il s’agit d’une instance de démo montée spécialement “à part” pour faire quelques POC sur la couche “processus/activités” dans le cadre d’un chantier majeur de refonte de notre process “privacy by design” (GDPR). Elyass est chargé du sujet côté produit. Si le POC est concluant, cela orientera la décision de conserver l’UI/UX sur Simplicité et de ne pas (faire) redévelopper un front dédié hors Simplicité.
Les templates d’instance et images Docker à jour sont depuis quelques mois livrés en utf8mb4 par défaut pour MySQL/MariaDB, mais la version de MariaDB livrée en standard sur l’OS des serveurs SIM est désormais ancienne ce qui pose peut être des pbs à ce niveau…
PS: s’il s’agit d’une instance crée avant ce changement d’encoding par défaut, les tables doivent être modifiées manuellement via des alter.
MariaDB [bcsigdpr]> show variables like 'character_set_database';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| character_set_database | utf8 |
+------------------------+-------+
1 row in set (0.00 sec)
Le résultat est que dans la base il y a un mix de tables en charset utf8 (vos tables métier crées dans le charset de la base) et utf8mb4 (tables système Simplicité crées par défaut en utf8mb4):
Je propose de tout aligner en utf8mb4, dites moi quand je peux le faire car il faut éviter de faire ça “à chaud” = il vaut mieux arrêter l’instance avant de le faire puis la redémarrer ensuite.
je pense que si Elyass n’est pas connecté dessus, tu peux le faire asap (surtout si la manip est rapide).
C’est bien ce problème que nous avions rencontré précédemment, j’avais été amené à réaligner manuellement les tables en utf8mb4 sur notre serveur.
OK je fais la manip ASAP et je vous tiens au courant.
Le SIM (v6.5+) va désormais créer des bases MySQL/MariaDB par défaut en utf8mb4, comme le setup des tables système Simplicité est désormais livré en utf8mb4 ça devrait être cohérent.
Il y a 4 tables sur lesquelles l’ALTER ne marche pas:
ALTER TABLE bcsi_legal_entity_dep CONVERT TO CHARACTER SET utf8mb4;
ALTER TABLE bcsi_major_domain CONVERT TO CHARACTER SET utf8mb4;
ALTER TABLE bcsi_semantic_domain CONVERT TO CHARACTER SET utf8mb4;
ALTER TABLE bcsi_swsign CONVERT TO CHARACTER SET utf8mb4;
Ca dit: “Specified key was too long; max key length is 767 bytes”.
Ca vous dit quelque chose ?
Sur ces 4 tables je vois des colonnes à 255 caractère…
J’ai effectivement effectué des vérifications sur l’environnement de développement ainsi que celui de recette et j’ai constaté également que plusieurs colonnes dans les tables, y compris celles que vous avez mentionnées (bcsi_legal_entity_dep, bcsi_major_domain, bcsi_semantic_domain, bcsi_swsign), ont une longueur maximale de 255 caractères.
Cela dit, je comprends pourquoi l’ALTER TABLE ne fonctionne pas en raison de la limite de la longueur maximale de l’index de 767 bytes dans MySQL. Je voulais avoir votre avis sur la meilleure façon de gérer cette situation ?
Je me demandais aussi est-ce qu’une mise à jour de MySQL pourrait résoudre ce problème ? Si l’on peut imaginer qu’une version plus récente aurait une limite d’index plus élevée par exemple ? Si oui, quelles seraient les implications potentielles de cette mise à jour ?
Nous n’avons pas d’expertise particulière sur MySQL/MariaDB pour savoir ce qui se cache derrière cette limite ni si une version plus à jour résoudrait le pb. Sur les SIM on utilise la version de MariaDB fournie par la distribution, or sur ce SIM renault.simplicite.io créé il y a longtemps c’est une distribution CentOS 7 c’est donc une MariaDB désormais assez ancienne : 5.5.68.
Il faudrait donc envisager un déploiement autre que sur ce SIM (ex: un déploiement Docker avec une image MySQL à jour ou un nouveau SIM car les SIMs plus récents sont sous Almalinux 8)
En tout cas sur ces 4 tables il y avait un index portant sur des colonnes à 255 caractères:
swsign_id pour bcsi_swsign
dep_name pour bcsi_legal_entity_dep
name et short_name pour bcsi_major_domain
semantic_domain_name pour bcsi_semantic_domain
En supprimant ces indexes les ALTERs ont pu passer.
Il vous faudra surement revoir la taille de ces attributs à la baisse pour qu’il n’y ait pas de pb à la recréation de ces indexes.
