**Mes bases de données sont toujours en MySQL version 5.7**
**Prérequis à renseigner :**
- Nom de domaine : -- non pertinent --
- Mon hébergement/serveur est chez OVH : OUI en Hébergement WebCloud Pro
----------
Bonjour à toutes et à tous,
Mes bases de données sont toujours en MySQL version 5.7 sur l'hébergement WebCLoud "Pro" que je loue depuis plusieurs années avec qq domaines.
**et:**
J'ai bien lu les articles de Fin de vie annoncée MySQL v 5.7 ici et là
J'ai cru comprendre que la montée en version vers MySQL 8 par ex serait faite par OVH mais je n'ai pas compris quand. (et je ne suis pas sûre non plus)
Aujourd'hui WordPress a la version 8.0 de MySQL en prérequis
Depuis le manager nous n'avons pas la main pour faire la montée en version.
Quelqu'un a-t-il des infos sur le calendrier d'OVH pour ces mises à jour ?
Merci d'avance, cdlt
Montée en version de MySQL sur offre WebCloud
Sujets apparentés
- [RESOLU] Server unable to read htaccess file, denying access to be safe
25690 
24.11.2019 19:11
- Version php 7.0 sur Ovh mais php 5.4.45 sur mon wordpress
22929 10.01.2019 11:14
- Comment récupérer son mot de passe phpmyadmin ?
19862 14.11.2016 10:32
- Changer la version d'une base de donnée en mutualisé
19730 22.12.2016 11:46
- Variable upload_max_filesize plus grande que post_max_size
19690 11.06.2017 16:01
- Résiliation hébergement+domaine
15435 11.09.2018 20:28
- Résiliation hébergement
14569 27.07.2018 10:39
- Transfert hebergement et domaine .fr entre client OVH ?
13757 21.12.2016 15:10
- Ne supporte pas FTP sur TLS
13738 11.12.2018 18:48
- Nouvelle fonctionnalité : SFTP pour tous
13437 06.01.2017 14:50
Bonjour,
Q3/Q4 2024 (voir sur le forum il y a un topic).
Cordialement, janus57
Bonjour, J'ai fait une recherche sur ce sujet.
Effectivement, vous répondez à chaque fois la même chose Q3/Q4 2024....je n'ai pas trouvé d'autres topics où il est clairement indiqué une période pour le transfert des serveurs MySql vers version récente ( 8 ou 8.2 ).
J'ai aussi une alerte sur mon site Web comme quoi la version du serveur MySql est dépassée et qu'il faudrait passer à la version supérieure.
Que voulez-vous dire par Q3/Q4 2024 ? Si vous avez le lien vers le topic dans lequel apparaît clairement l'info, pourriez-vous le fournir ?
En vous remerciant
Bonjour,
Voir : https://community.ovh.com/t/Mises-%C3%A0-jour-vers-MySQL-80/63779/99
Cordialement, janus57
La seule façon de savoir si vos bases sont migrées ou pas est :
**soit** de créer une nouvelle base (s'il vous en reste une de libre dans votre manager OVH). La nouvelle base vous sera proposée exclusivement en Mysql 8.
**soit** de supprimer une base existante et de la recréer avec évidemment **toutes les précautions d'usage** concernant cette migration (mise en maintenance des sites, backup de la totalité de la base à supprimer, vérification des backups, etc)
À mon humble avis, cette re-création des bases en Mysql 8 **n'est que la moitié d'une étape** concernant une **"vraie" migration** de Mysql 5.x en Mysql 8.x car si vous réimportez en l'état votre backup dans la nouvelle base, elle sera encore dans son ancien format de charset, engine et collation. Quitte à monter en version, autant en profiter pour se mettre au standard des moteurs SGBD d'aujourd'hui (InnoDb, utf8mb4, et utf8mb4_unicode_ci ou autres) et "convertir" son fichier d'import avec ces nouveaux standards ou importer en l'état et convertir les structures et les données directement dans la base vers ces nouveaux standards. Et tout cela bien évidemment sur une **base de test**, avec tests de rigueur post migration pour s'assurer que tout est OK.
Laisser en l'état fonctionnera mais causera tôt ou tard des soucis si le CMS ou l'appli ne gère pas une rétrocompatibilité vers Mysql 5.x et lorsque qu'un CMS ou une boutique "exige" Mysql 8 à l'installation ou à la mise à jour, c'est qu'il ne supportera plus les versions précédentes. Si le CMS s'occupe de cette migration des anciennes données et structures, ce qui ne sera pas toujours le cas, Il est quand même plus prudent de s'en assurer en allant voir avec phpmyadmin la structure des tables et notamment des valeurs d'engine, charset et collation.
Cette migration est loin d'être anodine et certains se contenteront du "en l'état" vu que cela marchera comme avant dans la plupart des cas mais peut-être avec des effets de bord (performance notamment).
Cet avis n'engage que moi, si un datamaster passant ici peut confirmer/corriger/contredire ces propos cela permettra à tous d'y voir plus clair sur la gestion de nos chères données et des actions à mener en parallèle de cette migration.
Comme dit le proverbe, un(e) homme/femme averti(e)en vaut deux ;-)