English post here.
MySQL 8.0 arrive bientôt sur les bases de données livrées avec vos hébergement web, appelées également «SharedSQL» ou «Bases de données MySQL mutualisées». Pour la grande majorité des cas, la migration sera transparente et vous n'avez rien à faire. Mais certains cas, plus rares, nécessitent des actions de votre part. Nous avons listé ici les cas les plus répendus.
Si nous rencontrons d'autres cas significatifs, nous les rajouterons ici.
* De nouveaux mots réservés
TL;DR: MySQL 8.0 a introduit de nouveaux mots réservés, ce qui peut aboutir à de rares erreurs côté client.
Détails ici.
* Préparez vos vieux Drupal
TL;DR: Les vieilles versions de Drupal ne fonctionnent pas avec MySQL 8.0. Mettez-les à jour dès maintenant.
Détails ici.
* Préparez vos (très) vieux Wordpress
TL;DR: Pour éviter les problèmes d'accents lors du passage de MySQL 5.7 à 8.0, vérifiez que le paramètre DB_CHARSET est bien présent dans le wp-config.php de votre Wordpress.
Détails ici.
Mises à jour vers MySQL 8.0
Sujets apparentés
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
63708 
03.09.2018 14:46
- Connexion à mon compte client
57288 13.02.2019 09:51
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
49713 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
34252 28.07.2017 11:39
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
29712 16.10.2016 16:24
- Augmenter taille PHP Post Max Size sur mutualisé ?
28025 04.12.2019 21:52
- The requested URL / was not found on this server
27766 02.03.2017 18:25
- NextCloud sur mutualisé
27070 07.04.2017 08:42
- Deploy d'un projet Node JS
27024 12.10.2016 20:18
- Passage en php 7.4
24798 30.06.2020 05:05
Merci @MikaelD1
Bonjour,
Nous avons une petite question. En ce qui concerne la variable "sql mode", allez-vous utiliser les mêmes valeur que sur les serveur actuels ou allez-vous y intégrer ceci : "NO_ZERO_IN_DATE,NO_ZERO_DATE" ?
Nous avons beaucoup de serveur qui ne fonctionneront plus si vous intégrez cela...
Merci.
Bonjour,
Vous me confirmez qu'un Joomla 4 pourra tourner sans modification sur MySQL 8.0 dès la migration ?
Bonjour,
Si cela peut aider, pour m'aider à passer à mysql 8.0 sur wordpress, prestashop et mes développements PHP, j'ai utilisé ce très bon article : https://www.wasi.fr/ovh-va-passer-a-mysql-8-faut-il-mettre-a-jour-version-de-mysql/">migration mysql8
Bonne journée,
Michel.
Bonjour,
le changement de version de mysql concerne aussi les serveurs d’hébergement mutualisé ?
Bonjour,
Oui, c'est pour bientôt, vous allez recevoir un e-mail d'OVH.
Bonjour,
ce topic est justement pour les serveur mutualisé vu que les autres sont fait (de ce que j'ai compris).
Cordialement, janus57
Bonjour,
Je maintiens une ancienne application PHP 5.6 .
Est-il possible de conserver mysql5.6.
Bonjour,
Vu que les serveur actuel sont en mysql5.7 : non
Et non ce sera un upgrade pour tout le monde vu que c'est des serveur mutualisé.
Et la version de PHP n'a rien à voir avec la version de MySQL.
Cordialement, janus57
Bonjour,
Les anciennes applications développées avec php5.6 seront bloquées ou il y aura des problèmes avec mysql8. (mysql_connect)
Avec PHP 7.4 et au delà les commandes mysql_xxx ne sont pas autorisées.
Les anciennes applications et site , développées avec php5.6 seront bloquées
Bonjour,
si vous utilisez pas des requêtes avec des nouveau mots interdit, cela devrait passer (sauf si j'ai loupé un truc).
Par contre PHP5.6, il va falloir penser à migrer, car le jours ou OVH va décider de faire le ménager dans les version de PHP, ce sera trop tard pour agir et vous avez de la chance, chez OVH l'utilisation d'ancienne version de PHP n'est pas facturé en supplément (ce qui n'est pas le cas chez d'autres hébergeur qui facture en supplément à cause du maintient de version EOL dans leurs infras).
Cordialement, janus57
On va le laisser tel quel. Effectivement, si on intégrait `NO_ZERO_IN_DATE` et `NO_ZERO_DATE`, ça casserait beaucoup de sites.
Après, ma préconisation (et qui n'est pas liée à cet upgrade), c'est d'essayer de coller au plus au sql mode par défaut, à savoir:
* ONLY_FULL_GROUP_BY
* STRICT_TRANS_TABLES
* NO_ZERO_IN_DATE
* NO_ZERO_DATE
* ERROR_FOR_DIVISION_BY_ZERO
* NO_ENGINE_SUBSTITUTION
J'avais écrit un post il y a quelques années (wow, 4 ans, ça passe…) sur le sujet:
https://community.ovhcloud.com/community/fr/cloud-db-mysql-privilege-super-user?id=community_question&sys_id=fa05b540fdde8e902d4c483e6acd516b?u=mikaeld1
Ce qui serait intéressant, c'est qu'OVH propose la version actuelle de MySQL (la 5.7 donc) et que l'on puisse créer une nouvelle base en version 8.0
Cela nous permettrait de faire les modifications nécessaire avant la date fatidique et ne pas avoir à justifier auprès des clients pourquoi leur service sur OVH ne fonctionne plus pendant quelques jours.
En plus, vous le faites à partir du 8 juillet. Cela veut dire que vous ne voulez pas que les développeur et gestionnaire de serveur partent en vacances durant le mois de juillet.
C'est vraiment pas cool.
Mais je ne sais si techniquement (et financièrement pour OVH) cela est possible.
Merci beaucoup pour la réponse, ça me rassure déjà, car nous avons malheureusement pas mal de sites très anciens (certains ont plus de 10 ans) avec un CMS dédié non standard où nos clients ne veulent pas investir pour les mettre à jour. Les adapter prendrait aussi pas mal de temps et il faut s'organiser.
Pour tous les sites concernés, nous utilisons PHP 5.X avec driver mysql et mysqli.
Pourra-t-on conserver ces drivers ou faudra-t'il tout passer en mysqli ?
Merci.
Bonjour,
l'authentification sur mysql8 est-elle fixée sur mysql_native_password ou bien caching_sha2_password
Bonjour @MikaelD1
Avez-vous des retours sur le couple à trois :
Joomla! 3.1.1 / PHP 5.4.45 / MYSQL 5.7.42-log
Nous n'avons pas eu de test concluant, aux premiers essais de migration.
Nous avons surement loupé quelquechose dans les paramètres ?
Merci d'avance
End of Life décembre 2013, êtes vous certain de ce que vous demandez ?
A un moment ou l'autre il faut migrer !
Sur mysql_native_password. Plus d'infos https://community.ovhcloud.com/community/fr/logs-base-de-donnees-plugin-mysql-native-password-reported-mysql-native?id=community_question&sys_id=7fe4fa8474eb4ad01e118a96965def94?u=mikaeld1">ici. 🙂
Bonjour @MikaelD1
à l'instant sur mon hébergement Perso 2010 :
Et pourtant ma base de données MySQL 5.7 est bien opérationnelle.
Bonjour Mikael,
qu'entendez-vous par cette phrase "On va le laisser tel quel." ?
Car ok pour votre préconisation, mais dans les faits quel sera la valeur précise du sql_mode ? J'ai une dizaine de sites sur lesquels les 4 premiers paramètres seront bloquants, et vue la date butoir du 08/07 qu'on m'a indiqué c'est impossible pour moi de tout planifier, corriger et tester...
C'est une très bonne nouvelle de voir "enfin" mysql 8 arriver sur les mutualisés OVH.
C'est une des raisons qui me faisait très sérieusement regarder la concurrence pour héberger les différents sites que j'administre pour mes clients, sous le CMS Typo3 qui impose mysql8 dans sa version 12.
**Est-ce qu'à l'occasion il pourrait sérieusement être étudié la remise en place de possibilités d'administrer ces bases de données via un client externe, et surtout pouvoir se passer de PhpMyAdmin (connexion via tunnel SSH) ?**
Cette fonctionnalité a été coupé en 2017… suite à la découverte de faille de sécurité dû à une non-maîtrise de la portée des actions faites via les tunnels ouverts.
Les adresses des serveurs de BDD étant au format xxxxxx.mysql.db, il serait peut-être possible d'ouvrir cette possibilité avec base de restriction (pour ne pas ouvrir des accès complet).
Bien cordialement
Effectivement @GregD34 ma réponse était très loin d'être claire, désolé pour ça. Je la refais:
Le sql_mode des MySQL 8.0 sera le même que celui qui est actuellement en production sur les MySQL 5.7, à savoir:
NO_ENGINE_SUBSTITUTION
(et rien de plus)
Bonjour,
Je tourne avec prestashop 1.6 et je ne peux pas dépasser la version php 7.1.
Que dois-je faire ?
Bonjour @ZandidoustA
Pouvez-vous préciser ?
Problème de plugin ou de Thème.
Bonjour
J'administre plusieurs sites en JOOMLA 4.4.5
1/ Est-ce que au changement de version mySQL vous m'assurez zéro souci ?
2/Hébergement sur des serveurs mutualisés différents aura-t-on un mail avec la date prévu ?
car à partir du 8 juillet c'est vague :)
3/Question complémentaire vous passez à la version 8.0.? (la 33 ou la 35 ou autre ? )
Merci à vous
Bonjour,
Je suis sous OsCommerce avec MySQL 5.7
Je comprends que mon site va cesser de fonctionner ?
Il s'agit de ma source de revenu unique et j'ai ajouté tellement de modifications que je ne souhaite pas migrer vers des solutions qui ne me conviennent pas autant.
Merci pour votre réponse.
Bonjour,
Sur la home page de OsCommerce je lis ceci:
"In 2024 your eCommerce platform needs to use the latest server technology. That’s why osCommerce uses PHP 8.1 (but of course we still support older versions, starting from php 7.3) and Maria DB 10.x to offer the fastest and most secure performance for ultimate speed and security. osCommerce will always develop for compatibility with the latest and best versions of server software ensuring your eCommerce shopping cart is always fast, safe and secure."
Ne vous inquiétez donc pas, OsCommerce supporte les versions récentes des logiciels serveurs.
A moins que votre version de OsCommerce n'accuse un grave retard, ce qui ne serait ni de la faute d'OVH ni de OsCommerce.
Je m'occupe de 2 sites utilisant une base de données MySQL 5.7 dans des modules codés en PHP.
Sur le premier site, qui utilise aussi WordPress, je suis passé à PHP 7.4 et je suppose que je n'aurai rien à faire pour que la migration vers MySQL 8.0 fonctionne correctement.
En revanche, j'ai des doutes pour le second site, codé en PHP 5.4. Quelqu'un peut-il me renseigner ? Quelle est la version de PHP minimum requise pour fonctionner correctement avec MySQL 8.0 ?
Merci d'avance
Bonjour @JeanG43
Indépendamment de MySQL 8.0 , je me demande si vous ne devriez pas déjà faire évoluer votre site par étapes pour le faire fonctionner sous **_PHP 8.3_** ?
La version PHP n’a rien à voir avec celle de Mysql.
Si le site est du dev perso alors un bon moyen est de tester en local ou sur un hébergement de dev.
Quand l'écart de génération est trop grand, ces doutes sont fondés et la version de PHP peut avoir des limitations quant à sa compatibilité avec une version récente de Mysql.
Voir le manuel PHP :
https://www.php.net/manual/en/mysqli.requirements.php
Visez à minima la version PHP 7.4.4 (obsolète) et idéalement la 8.1/8.2
https://www.php.net/supported-versions.php
Bonjour,
alors oui est non car OVH a déjà indiqué que cela restera désactivé comme actuellement donc 0 contraintes côté PHP de ce que j'ai vu.
Cordialement, janus57
Bonjour Mikael,
pouvez vous vous entendre avec le support OVH (Héléna L.) ?
Elle vient d'infirmer ce que vous avez écrit... /!\ /!\ /!\
"
Je vous confirme que la version MYSQL 8.0 inclura par défaut les modes suivants :
- ONLY_FULL_GROUP_BY
- STRICT_TRANS_TABLES
- NO_ZERO_IN_DATE
- NO_ZERO_DATE
- ERROR_FOR_DIVISION_BY_ZERO
- NO_ENGINE_SUBSTITUTION.
"
Qui croire ?!
Bonjour,
connaissant les réponse "type" du support niveau 1, je pense que ce qu'il dit est faux car réponse sorti du manuel MySQL.
Si je dit pas de bêtises, @MikaelD1 fait partie de l'équipe Databases de OVH, donc est en plein cœur de l'action (exemple de publication qu'il a fait sur le blog de OVH pour la migration de P19 vers GRA : https://blog.ovhcloud.com/how-to-win-at-the-massive-database-migration-game/ et de la migration de MySQL5.6 vers 5.7 : https://community.ovhcloud.com/community/fr/sharedsql-mises-a-jour-vers-mysql-5-7?id=community_question&sys_id=dbd3b540f51646d02d4c5f7a9ab3611a)
Cordialement, janus57
J'ai le code devant les yeux, crois moi, le sql_mode est bien `NO_ENGINE_SUBSTITUTION`.
Désolé pour les différents sons de cloche. À la décharge du support, je ne leur avais pas communiqué sur ce point précis. Je m'en occupe.
Bonjour,
Mais dans ce cas pourquoi le support répond une chose qui est fausse plutôt que de dire "Désolé je n'ai pas encore cette information, je vais me renseigner auprès des administrateurs", ce qui serait plus logique que d'induire le client en erreur.
Cordialement, janus57
Bonjour @MikaelD1,
Nous avons actuellement un Dolibarr en version 6.0.9 avec une version PHP serveur en 7.0.
D'après l'email reçu de OVH "Nous avons effectué des tests approfondis pour garantir la compatibilité de vos applications avec MySQL 8.0".
Pourriez-vous me confirmer que nous n'aurons aucun souci de fonctionnement et d'accessibilité sur notre version de Dolibarr svp ?
Nous ne pouvons pas migrer sur des versions plus récentes avant 2025.
Merci d'avance pour votre retour.
Bonjour,
Nous avons un réseau de sites wordpress en version 4.9.9, mysql 5.7 et php 5.6
Est-ce que cela va fonctionner avec le passage de mysql en 8.0 ?
Merci
Bonjour,
Ca date de 6 ans ! vous ne vous rendez pas compte des risques encourus ?
Passez au moins en 4.9.26 et puis voyez à vous mettre à jour.
https://wordpress.org/download/releases/#branch-49
Oui je sais
Je viens de reprendre le dossier et il y a un souci pour mettre tout le monde d'accord pour les maj #SujetCompliqué #RéseauDeSites
et concernant la compatibilité ?
ça va fonctionner ?
J' n'ai pas trouvé cette info.
Testez sur un hébergement de développement.
Merci. Nous sommes en juillet maintenant. Que signifie « 8.0 arrive bientôt ». Ce mois-ci ?
Je suis impatient :).
Quand sera mis à jour mon hébergement (offre : Perso) vers mySQL 8 ?
Merci
Bonjour,
Avec les autres.
Cordialement, janus57
OK avec les autres. Mais ça veut dire quand ? (pour avoir un ordre d'idée : dans 1 semaine, 1 mois, 1 an, …)
Bonjour,
OVH annoncera les date quand ils auront un planning de fait.
Mais en tout état de cause cela sera dans les prochains mois.
Cordialement, janus57
Si on en veut OVH aucun impact possible quelque sur la version de PHP... Je trouve ça très optimiste voir dangereux d'envoyer un tel message...
Ce que vous devez savoir :
La migration est totalement automatique et **aucune action de votre part n'est requise**. Vos paramètres de connexion ne seront pas modifiés et **vos services continueront de fonctionne normalement**.
**Nous avons effectué des tests approfondis pour garantir la compatibilité de vos applications avec MySQL 8.0.**
Bonjour,
Simple globalement PHP s'en fou de la version du serveur MySQL.
Ce qui risque de casser c'est surtout le code du site et/ou l'utilisation de mot qui sont devenus interdit dans les nouvelles versions.
Cordialement, janus57
Bonjour,
c'est prévu pour quelle heure ? Qu'on puisse suivre l'upgrade et être réactif en cas de soucis !
Merci
Pas en heures.
Je parlerai plutôt un jours, semaines et même mois. 😡
Bonjour,
OvH communiquera le moment venu mais ne vous attendez à pas à avoir une heure précise ce sera durant un créneau horaire et sûrement de nuit.
Cordialement, janus57
Bonjour,
J'ai vu que pour migrer en mysql V8.0, il fallait migrer aussi en php 8.1 (nous sommes actuellement en php 5.4 et mysql 5.7).
Je suis aussi curieux de savoir à quoi correspond "le moment venu"
Cordialement,
etarcos
Bonjour @BernardV29
Passer rapidement et par étapes de PHP 5.4 à PHP 8.3
Bonjour,
heu faux ? ou avez-vous vu ça ?
Cordialement, janus57
Bonjour Janus, J'ai trouvé ça sur le site OVH. j'essaie de le retrouver. A suivre
Merci de l'info Gaston_Phone, Nous venons de terminer les tests sur notre serveur local en php 8.1.28 et mysql 8.0.38 suite à de nombreuses corrections, et tout semble ok. nous poursuivrons vers php 8.3 selon votre conseil.
Je suppose que nous devons attendre le feu vert de OVH suite à la migration vers de leur serveur, vers mysql 8.
Comme annoncé dans les emails que vous avez reçu le mois dernier, MySQL 8.0 est arrivé hier, lundi 2024-07-08, pour les nouvelles bases de données. Si vous créez une SharedSQL là maintenant, elle sera donc forcément en MySQL 8.0.
Du côté des upgrades:
* On commence demain, mercredi 2024-07-10.
* On étale ça jusque fin septembre. Non pas par contrainte, mais par volonté. Pour ceux que ça intéresse, la méthode s'appelle "canary deployment".
* Le suivi se fait ovhcloud.com/incidents/cnf2n29hj6s1">ici.
Formidable !! Enfin !
Qu'entendez-vous par bientôt ? une semaine ? un mois ? un trimestre ?
à quel délai s'attendre pour que la mise à jour soit enfin effective ?
Cordialement,
Après les vacances estivales si tout va bien
Les clients seront ils avertis individuellement une fois la migration effectuée ?
Bonjour @MikaelD1
Si sur un hébergement **PERSO 2010** je supprime la base de données et que j'en recrée une autre, la nouvelle sera-t-elle en **MySQL 8.0** ?
Le cluster10 vient de m'autoriser à créer une base MySQL 8.0 tout en gardant l'ancienne que je supprimerai quand cela fonctionnera correctement plusieurs jours.
Pour mon nextcloud perso (qui ne sert à rien d'autre qu'à des notes, mes adresses et quelques fichiers) Voici comment j'ai procédé grâce aux sages conseils de Sam...
Maintenance ON
Sauvegarde de la base MySQL 5.7
Création de la nouvelle base sur MySQL 8.0
Importation de la sauvegarde
Mise à jour du fichier config.php pour les paramètres de bdd
Petite vérif avec occ db:add-missing-indices et occ db:convert-filecache-bigint
Maintenance OFF
Et ça roule !
Personne ne m'a averti, mais dans la console de gestion, depuis le 15 07 24 je peux créer une base en MySQL 8.0
Comme l'as dit MikaelD1, si nous créons une base de donnée elle sera automatiquement en 8.0, si on veut pas attendre sagement la mise à jour sans forcément créer une nouvelle base de donnée
Tu peux aller encore un peu plus vite en utilisant l'option de copie de DB:
1 - Si il te reste un slot de libre, crée une nouvelle DB (qui sera donc en MySQL 8.0)
2 - Au niveau de la MySQL 5.7 que tu souhaites passer en 8.0, "Copy database":
3 - Au niveau du modal qui s'affiche, choisis la MySQL 8.0 que tu as créé en step 1:
4 - Quand tu n'as plus rien dans l'onglet "Ongoing tasks", c'est que la DB est prête. Tu peux alors changer ta conf' PHP et supprimer la DB MySQL 5.7 (s'il vous plaît, supprimez les DB qui ne vous servent plus 😅).
Exactement 🙂
Bonjour @MikaelD1
Je suis en Pro 2010
Si je supprime ma base de 2GO qui n'est plus à la vente sera-t-elle définitivement perdue et remplacée par une de 1Go ou moins ?
Merci.
Un petit soucis : Mot de passe non reconnu
**_Errare : il fallait attendre 15 mn_**
Maintenant sur mes sites hébergés en PERSO 2010 :
* PHP Version = 8.3.7
* MYSQL Version = 8.0.36-28
Seul problème rencontré lors de la migration MySQL 5.7 à 8.0 :
**_Erreur :_**
Connexion échouée : SQLSTATE[42000] [1231] Variable 'sql_mode' can't be set to the value of '**_NO_AUTO_CREATE_USER_**'
**_Correction :_**
Supprimer **_,NO_AUTO_CREATE_USER_** des paramètres de connexion **PDO**
😉
Bonjour ,
**_1er question:_** Pendant cette phase de migration chez OVH n'y a t'il pas moyen d'avoir une offre START SQL pour **1 mois** ? quelques jours aurait suffis, mais ici, on doit prendre un abonnement de 12 mois, pour sécuriser la migration !
Je suis sur une **offre perso** sur **cluster031.hosting.ovh.net**
**_2nd question:_** si je supprime la base sur mon offre perso sur cluster031.hosting.ovh.net
quel est le délais lors de la création d'une nouvelle base. Me confirmez-vous qu'elle sera en 8.0 ?
Bonjour,
Pouvez-vous me confirmer qu'il ne faut pas supprimer la base de donnée existante mais la dupliquer et qu'elle sera en SQL 8 ? Si on supprime notre base de donnée sans la dupliquer, le site sera mort non ?
Bonjour @EDENM
La logique est de sauvegarder le contenu de la base de donnée (un export) avant de la supprimer et de réimporter cette sauvegarde dans la nouvelle base de donnée.
C'est exactement ce que j'ai fait hier. 😉
Ceux qui ont déjà eu la migration (sans faire le forcing en créant une nouvelle base de donnée etc), pouvez-vous nous dire si vous avez reçu un mail ? Et si tout s'est bien passé ?
Non et comme l'écrit le maître des bases d'OVH @MickaelD1 ci-dessus, utilise la fonctionnalité de "copier la base", la nouvelle base sera en v 8.0. Tu peux commencer l'action dans ton interface et tu verras clairement la version de la nouvelle. Tu supprimeras l'ancienne lorsque tout ira bien.
J'ai peur de faire une connerie et que mon site saute, je préfère attendre qu'OVH fasse la migration même si ça prend du temps,
Je veux pas rentrer dans les fichiers du site pour changer le mdp etc de la base de donnée
C'est dommage qu'il y a pas un planning pour savoir quand notre base va changer de version
Tu peux t'inscrire au suivi
Bonjour,
J'ai des databases MySQL 5.7 liées à un hébergement 90plan (ça date...). Comment faire pour connaître le nom du serveur sur lequel elles sont réellement hébergées afin de pouvoir suivre leur planning de mise à jour ? Je sais qu'elles sont à Graveline 2, sans plus de détails.
Merci d'avance pour une réponse.
Je me suis posé la même question car dans le même cas ;-)
Et comment savoir si nos bases ont déjà été migrées ou pas ?
Est-on censé recevoir un message post migration ?
Combien de temps la 5.7 restera t-elle en ligne ?
Bonjour @DenisLC
C'est très facile, il vous suffit d'aller dans le manager OVH, onglet base de données, et regarder la version de votre base de données.
Bonjour @YuriC
Personnellement je ne vais pas attendu.
Sur un premier hébergement où je n'avais pas de site critique, j'ai supprimé la base de données et remis une nouvelle base de données qui elle est à la version 8.
J'ai ensuite copié mon site critique sur cet hébergement et fait les corrections qui s'imposent pour passer de la version MySQL 5.7 à la version 8.
Ceci fait :
* J'ai réalisé un export de la base de données 5.7 sur mon PC.
* Supprimé la base de données, créé une nouvelle base de données cette fois-ci à la version 8.
* Importé ma base de données sauvegardé sur le PC dans cette nouvelle base de données version 8.
* Appliqué pour finir les corrections que j'avais faites sur l'autre hébergement.
Tout fonctionnant correctement, je suis parti me coucher.
OK mais alors comment expliquer cette copie d'écran de @MikaelD1 qui montre la cohabitation des deux versions de myql ?
La réponse est dans la question : quel abonnement d'hébergement avez-vous ?
Personnellement je n'ai que des hébergements perso 2010.
Et si je me souviens bien le "copie database" ne pouvais pas fonctionner parce que mon hébergement n'acceptait qu'une seule base de données
Un pro 2010 mais peu importe mes 4 bases (max) sont déjà utilisées donc à moins de supprimer et recréer chaque base oui (ce qu'est censé faire la migration) mais encore faut-il être sûr que la version 8 soit disponible car cela suppose aussi de mettre en standby les sites qui y sont rattachés. Ce manque d'information sur un planning un peu plus précis qu'une plage qui s´étend en "semaines" est un peu incompréhensible de la part d'OVH d'autant que certains utilisateurs Joomla attendent avec impatience de pouvoir migrer aussi vers Joomla 5 ce qui était jusque là encore impossible du fait de l'absence de Mysql 8...
Bonjour @DenisLC
Vous avez quatre bases sont partiellement remplies.
Déplacer le contenu d'une des quatre bases dans une autre. Faites marcher le site avec cette base en modifiant dans les paramètres de votre site les identifiants de connexion de la nouvelle base.
Ensuite vous pourrez supprimer cette 4e base et recréer une nouvelle base de données qui sera à la version 8.
Migrer ensuite la base de données que vous aviez déplacée dans cette nouvelle base version 8.
Oui @Gaston_Phone c'est aussi une solution mais je préfère attendre le message d'ovh s'il existe (quelqu'un pour confirmer cette info ?) histoire de ne pas y revenir 2 fois...
Après pour ceux qui ne sont pas à l'aise avec ces manips, ATTENTION ces déplacements ou copie de base, écrasent la base destinatrice..donc SAUVEGARDE et mise en standby des sites en prod dans tous les cas avant de manipuler ses précieuses données car la sauvegarde OVH est celle de la nuit...
Merci quand même pour tes conseils ;-)
Bonjour @DenisLC
Il y a un risque d'attendre le passage automatique par OVH.
Si tu as un soucis suite au passage, il va te falloir mettre la main dans le cambouis.
Un ou tes sites seront alors inutilisables pendant tout le temps de la réparation.
**_Pour mon site critique la coupure a durée 60 mn._**
Bonjour,
comme dit plus haut les **nouvelles bases** sont automatiques en MySQL8 que ce soit une ancienne ou nouvelle offre, donc si vous supprimer une base pour ensuite la recréer elle sera bien en MySQL8.
C'est écrit en toute lettre dans le message de @MikaelD1 :
Cordialement, janus57
Dernière question avant de m'y coller...
Une "vieille" base de 2Go avec le statut "Incluse – retirée de la vente", une fois supprimée et recréée, reste bien à 2Go avec MySql 8 car je suis en Pro2010 et compte y rester... et les nouvelles bases sont à 1Go dans l'offre pro actuelle donc la question du maintien des conditions contractuelles du Pro 2010 se pose légitimement.
**[EDIT au 07/08/2024 ]** Je me réponds à moi-même : **OUI** une ancienne base reste bien à sa capacité initiale lors de sa souscription à un plan devenu depuis obsolète (90plan, Pro2010, etc)
Ma "vieille" base de 2Go en MySql 5.7 a bien été convertie "commercialement", après suppression, en base de 2Go version MySql 8...de même que les bases Mysql perso 400Mo
Bonjour,
ça c'est une question à poser au support.
Mais sachez que si un jour OVH arrête de maintenir les ancienne offre, alors il y aura migration sur l'offre de remplacement.
Cf : https://www.ovhcloud.com/fr/web-hosting/old-web-hosting-offers/
Cordialement, janus57
Pour info, je confirme que MySql 8.0 est bien disponible à partir du moment où vous supprimez et recréez une base et ce sans avoir reçu de mail ou autre info sur mon espace...
C'est sûr qu'il vaut mieux faire des tests de chaque appli/CMS, déjà qu'avec PHP 7.x à 8.x c'est au pt'it bonheur la chance quand tout fonctionne du premier coup c'est à dire lorsque que les CMS ont prévu une retro-compatibilité...
Bref j'ai un peu de pain sur la planche ;-)
Quelques nouvelles des mises à jour…
* Actuellement, un petit 10% des bases tournent en MySQL 8.0.
* On fait 2 semaines de pause entre le 2024-07-26 et le 2024-08-11 inclus: ce sont les JO, et on entre en période de «freeze». Le principe, c'est qu'on temporise les interventions qui peuvent l'être pendant des périodes importantes pour beaucoup de business: Noël, les soldes… et ici, les JO.
* À partir du 2024-08-12, on accélère significativement (c'est le concept du «canary deployment», on y va doucement au début, puis on accélère…): on vise une mise à jour de 3% de la prod par jour ouvré.
* La cible: 100% de la prod' à jour au 2024-09-30.
Merci @MikaelD1 !
Peux tu préciser ce que vous faites exactement sur toutes les bases existantes ?
A part l'upgrade pure des serveurs de mysql 5.7 en mysql8 et un nouveau charset et collate qui va bien (utf8mb4 et utf8mb4_unicode_ci) par défaut, est-ce que les tables existantes seront bien laissées en "l'état" sans toucher à leur l'engine, charset et collate configurés lors de leur création et qui doivent (ou pas) être migrées par leur seul administrateur pour cause de risque de dysfonctionnement si les applis qui les utilisent ne sont pas testées au préalable dans un espace dédié comme pour une classique update.
Apparemment, on peut encore maintenir les deux versions de mysql en parallèle mais jusqu'à quand ?
Évidemment c'est l'occasion pour tout le monde d'upgrader ses bases avec innodb/ut8 en lieu et place de MyIsam/latin1 qui persiste encore dans les bases et parfois avec les deux mélangés pour une même appli/cms :-(
Allez bonnes vacances olympiques !
Je te confirme que les tables existantes conservent:
* Leur engine,
* Leur character set,
* Leur collation.
Seuls les character set et collation par défaut changent, c'est à dire ceux qui sont utilisés lors de la création de la table/colonne lorsqu'on ne les explicite pas.
C'est gentil, mais même si on est en freeze pour les JO, pour nous les upgrades continuent… en préproduction. On y teste les mises à jour de copies de vos bases, on diagnostique, corrige et automatise les problèmes rencontrés, pour que les migrations en production se passent le plus vite et de façon la plus transparente possible lors de la reprise des upgrades dans 1 semaine 🙂
Bonjour, un rapide test de mon site avec des bases _ovh perso sql_ en mysql 8.0 me fait remonter cette erreur :
**User has exceeded the 'max_questions' resource (current value: 62803)**
C'est de façon aléatoire, mais très souvent quand même. C'est embêtant car tout allait bien en 5.7.
Une idée de ce qui bloquerait dans la version 8.0 ?
Je ne vois pas la valeur de cette variable 'max_questions' dans phpmyadmin.
Merci !!!
Ce message provient des protections anti-flood, qui ne sont pas spécifiques à la version 8.0 (elles existaient en 5.7 et le comportement n'a pas changé). Est-ce que tu peux me donner le nom de ta base que je double-check qu'il n'y a pas eu changement de comportement ?
@MikaelD1
Merci de t'y pencher !
Nom de la base envoyé en MP !
Bonne journée.
Merci pour cette confirmation et bon courage pour cette migration !
Suis en mysql 8.0 en live, je confirme que j'ai toujours le même comportement en ce moment :
**User has exceeded the 'max_questions' resource (current value: 56929)**
:(
Trop d'erreurs 'max_questions'...
Retour en 5.7, du coup.
Et retour à la normale : plus aucune erreur.
Vu ensemble en message privé: l'anti-flood est légitime, il s'agit d'un problème tiers (pas lié à MySQL 8.0), côté web.
Bonjour,
Savez-vous quand est ce que la nouvelle vague des mises à jours vers MySQL 8.0 va reprendre ?
Et pouvez-vous me dire quand mon site et son hébergement seront concernés par cette mise à jours ?
Faut-il faire une sauvegarde de sa base de données avant cette mise à jours ? Ou autre chose ?
Merci d’avance pour la réponse.
Cordialement
Bonjour,
Vous avez la progression sur la tâche de travaux.
Cordialement, janus57
ovhcloud.com/incidents/cnf2n29hj6s1">Tâche travaux qui n'avait pas été mise à jour, désolé pour ça 😬 Updated.
Bonjour YuriC,
As tu eu des réponses à ta question ?
"Comment faire pour connaître le nom du serveur sur lequel elles sont réellement hébergées afin de pouvoir suivre leur planning de mise à jour ? Je sais qu'elles sont à Graveline 2, sans plus de détails."
Je suis dans le même cas que toi.
Cordialement
Hervé
Il y a 2 méthodes pour savoir sur quel cluster se trouve votre SharedSQL.
**Méthode 1: API**
Sur https://eu.api.ovh.com/console/, faites un GET de `/hosting/web/{serviceName}/database/{name}`
Dans la réponse, vous aurez un champ `server`, qui a la forme `mysqlXXX.euYYY` (Europe) ou `mysqlXXX.caYYY` (Canada). Le cluster, c'est ce qu'il y a après le `.`.
**Méthode 2: DNS**
Depuis votre hébergement web, si vous faites une résolution DNS de:
`.mysql.db.gra.hosting.ovh.net`
Vous verrez que c'est un CNAME vers le nom du serveur, qui contient le nom du cluster.
Merci @MikaelD1
Auriez-vous un exemple de script PHP permettant de faire cette requête ?
Pour une base de donnée : **_< Nom de la base >.mysql.db_**
Bonjour,
Comme il me restait 1 DB de libre, j'ai upgradé mes 4 DB en faisant des exports. Du coup, je n'ai plus suivi la progression des mises à jour et n'ai pas creusé la question. Je vois que certains ont posté des réponses permettant de trouver le nom du serveur.
Cordialement,
Y.
Bonjour @MikaelD1
Le serveur qui héberge mon site avec une offre Perso a été migré hier matin en MySQL 8.0.
https://www.deux-zero.com/
Et le fait que le default charset soit désormais utf8 et non plus latin1 pose des problèmes pour l'affichage des caractères accentués
Exemple: 2ème journée (donnée extraite de la base de données) s'affiche 2ème journée
Si dans mon fichier index.php, je supprime la ligne
ini_set('default_charset', 'iso-8859-1');
les données extraites de la base de données s'affichent correctement, mais c'est tout le reste du texte non extrait de la base de données qui s'affiche mal avec les caractères accentués avec des ? à la place.
Est-il possible de forcer (dans le fichier ovhconfig ?) le charset à latin1 comme avant en version 5.7 ?
Merci
Bonjour,
C'est à vous de forcer le charset lors de vos requêtes SQL (voir doc de PHP).
Cordialement, janus57
Merci beaucoup
J'ai ajouté cette ligne juste après la connection à la base de données:
$mysqli = mysqli_connect(SERVER, UTILISATEUR, MOT_DE_PASSE, BASE);
mysqli_set_charset($mysqli, "latin1");
Et tout s'affiche désormais comme avant
Ouf !
Bonjour MikaelD1,
Mercredi soir, je n'ai plus eu accès à mon blog :
http://kiwaida.nu/bmk/
L'équipe d'OVH m'a conseillé cette communauté d'OVHcloud qui regroupe développeurs et utilisateurs, et est activement présente sur ce forum. Ils m'ont informé que la mise à jour s'est réalisée de Mysql 8 (depuis le 5) sauf que je n'ai rien modifié de mon côté et je n'ai plus accès à mon travail, je n'ai pas été informée de ce changement mercredi soir. Comme conseillé j'ai changé le mot de passe de ma base de donné et aussi côté serveur, le PHPMyqdmin fonctionne, mais je n'ai toujours pas accès à mon blog. J'ai interrogé Dotclear sur leur forum, pouvez-vous m'aider ?
Bonjour,
Le message d'erreur ressemble bien à un problème de mot de passe erroné.
Vous devez certeinament retranscrire le nouveau mot de passe dans un fichier de configuration de votre Dotclear.
Tant que ceci n'est pas fait il est impossible d'examiner plus en avant.
Bonjour @Kiwa
Vous devez aussi mettre à jour votre fichier : **_dotclear/inc/config.php_**
Bonjour Gaston_Phone,
Oui j'ai bien mis à jour le fichier dotclear/inc/config.php
// Database driver (mysql, pgsql, sqlite)
define('DC_DBDRIVER','mysql');
// Database hostname (usually "localhost")
define('DC_DBHOST','lenomdemabasehebergee.mysql.db');
// Database user
define('DC_DBUSER','lenomuserquinavaitpaschange');
// Database password
define('DC_DBPASSWORD','monnouveaupwdavecdeschiffresetlettres');
// Database name
define('DC_DBNAME','lenomuserquinavaitpaschange');
// Tables' prefix
define('DC_DBPREFIX','dc_');
à noter que database user et database name
sont les mêmes
Bonjour Fritz2cat, oui j'écrivais en réponse à Gaston_Phone, j'ai bien change le mot de passe dans /inc/config.php, il est le même que celui côté serveur OVH, ainsi, de leur côté, ils expliquent que tout fonctionne, la base fonctionne.
Hors, je n'ai pas accès au blog, et en ligne l'erreur est écrite.
Voici u extrait de mon fichier config :
// Database driver (mysql, pgsql, sqlite)
define('DC_DBDRIVER','mysql');
// Database hostname (usually "localhost")
define('DC_DBHOST','lenomdemabasehebergee.mysql.db');
// Database user
define('DC_DBUSER','lenomuserquinavaitpaschange');
// Database password
define('DC_DBPASSWORD','monnouveaupwdavecdeschiffresetlettres');
// Database name
define('DC_DBNAME','lenomuserquinavaitpaschange');
// Tables' prefix
define('DC_DBPREFIX','dc_');
à noter que datables user et datable name
sont les mêmes
Oui c'est fait depuis hier
Votre fichier est bien codé en ANSI (et non en UTF-8 ou UTF-16) ?
Bonne question, comment puis-je le savoir précisément ?
J'ai ouvert le fichier config sous un Dreamweaver afin de changer le pwd, je n'ai donc pas modifié l'encodage, puis pour ce forum j'ai juste réalisé un copié-collé dans l'onglet prévu pour l'édition.
Horreur @Kiwa
Utilisez donc :
* TEXTEDIT / Visual Studio Code (Mac en mode TEXTE)
* NOTEPAD / Bloc-Notes (Windows)
* NOTEPAD++ (Windows)
Extrait de mon guide :
https://www.wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm
Désolée, je me suis peut-être mal exprimée, mais oui je fais toujours cette procédure, toujours en mode TXT
(le Dream c'était pour la visualisation vite fait) En tout état de cause, cela ne change rien car l'accès ne fonctionne toujours pas.
Merci pour votre guide, je prends bonne note de votre adresse.
Je suis à l'instant en contact sur un forum de Dotclear et plusieurs sont dans ma situation à la même date, rencontrant ce même problème, suite à la migration des bases de mySQL 5.7 vers mySQL 8, sur OVH, une personne demande :
"Est-ce qu'au passage ils basculent les bases de données (tables, …)
au format utf8mb4 ou est-ce que les bases restent au format utf8 si
elles l'étaient avant ?"
Je me permets de vous poser la question, de mon côté, je ne sais rien, sauf que quelque chose ne fonctionne plus d'un coup (je n'ai pas été prévenue)
Je n'ai aucune compétence pour Dotclear
On ne traite pas d' "**Horreur**" quand on ne connaît pas !!!
Dreamweaver, ça date de la grande époque avec les serveurs ColdFusion, et respect à ceux qui utilisent DW.
(Au départ, DW et CF, ce ne sont pas des produits Adobe)
Vous n'avez pas indiqué votre version de Dotclear.
Voyez avec la communauté Dotclear (https://fr.dotclear.org/)
Voyez aussi la version de votre base de données lenomdemabasehebergee.mysql.db , est-elle en version 5.7 ou bien a-t-elle été migrée en version mysql 8 ? (ce que je suppose puisque vous postez dans ce fil)
Bonjour @Fritz2cat
Je connais très bien et j'ai utilisé **_Dreamweaver_** dans une vie antérieure.
Je vous remercie Fritz2cat pour votre message. Certes la très vive impression associée au pseudo est déplacée, mais le lien du guide de Gaston_Phone montre le souhait de bien faire. Oui je suis une vieille lune mais pas des serveurs ColdFusion, dans une vie encore plus antérieure où je co-réalisais en équipe un travail génial et colossal sur un serveur totalement indépendant. Des inventions en marge des normes, mais c'est du passé. Je visualise d'un coup ces années, la pérennité est un mot inconnu dans l'informatique. DW je ne l'utilise pas en fait, mais il y a 20 ans oui je l'ai beaucoup utilisé, j'ai même enseigné pour beaucoup de jeunes étudiants dessus, après une vie à coder en ficher texte, et en FTP. Il y a longtemps que je n'avais pas remis les mains dans le cambouis, je ne sais pas si je vais parvenir à sauver qqch, sans aide impossible. Alors ce serait peut-être un miracle que mon blog sur un Dotclear non mis à jour ait tenu jusqu'à mercredi soir sans aucune erreur ? Je suis en contact avec le forum de Dotclear, et je viens de tester comme conseillé, dans inc/config.php, de changer le driver pour pour mysqlimb4, il y a, à présent une ligne d'erreur qui s'affiche. J'ai mis le lien de votre forum sur mes échanges dans le forum de Dotclear, si cela peut faire avancer les communautés, vers une améliorations des compétences.
Il est assez périlleux avec toutes les migrations de serveurs d'OVH, puis les mises à jour, mysql et CMS, sans compter le Hardware, mis à part la vie quotidienne où les mises à jours sont innombrables... que lorsque l'on perd des années de travail d'un coup, on espère un peu d'aide de son hébergeur, qui a lui-même effectué une mise à jour inopinée. Je vous remercie d'échanger sur ce sujet, car cela touche d'autres personnes aussi, dans la même situation, suite aux migrations diverses. J'ai cru à un moment que ma base de donnée était sur un autre serveur que mon site, et qu'il avait dû s'éteindre mercredi soir, mais bon, comme tout est dispatché, je ne sais si tout est à Graveline. À suivre.
La version de PHP est sous votre contrôle (ou presque, car je pense que PHP3 et PHP4.4 sont définitvement _out_ ) !
En ce qui concerne l'abandon de MySQL 5.7, il était temps que OVH lance cette migration.
Il est faux de croire qu'un site c'est comme une vieille Omega, tant que ça fonctionne, il ne faut surtout pas y toucher...
Je ne savais ce qu'était une vieille Omega (montre suisse ?), de mon côté, mon site est travaillé quotidiennement.
La difficulté avec les diverses migrations c'est que l'ajournement aussi de Dotclear était périlleux, mais j'ai appris que OVH, au téléphone, avait pour partenaire Wordpress et ne faisait pas de suivi pour Dotclear, ni n'avait de solution. Cela dit si je ne vise pas l'Alpha et l'Omega en informatique, j'espère retrouver mon blog. Côté contrôle, je pense que nous ne pouvons tout contrôler, tout est partagé. Parfois, les erreurs aussi.
J'oubliais, dans le fichier de ma base de donnée, la version du PHP est la Version 5.2.17 :
System Linux webm143.cluster010.gra.hosting.ovh.net 5.15.152-ovh-vps-grsec-zfs-classid #1 SMP Thu Mar 21 15:19:33 UTC 2024 x86_64
Comment trouvez-vous cette valeur ?
Vous avez raison c'est bien cette version qui est activée
server: Apache
x-powered-by: PHP/5.2.17
La version 5.2.17 date de janvier 2011 (c'est https://www.php.net/ChangeLog-5.php qui le dit)
et vraiment, utiliser une version vieille de 13 ans et demi, ça ne devrait plus exister et ça urge de vous mettre à jour !!!
De mon côté je suis bien à jour.
Si le php de mon blog n'est plus à jour c'est autre chose. Une version vieille de 13 ans et demi, c'est encore bien jeune, et ma foi, elle a très bien résisté Je lui tire mon chapeau. Je vous souhaite autant de longue vie dans les mises à jour, sans aucune erreur. On ne saura jamais qui était dans l'ancien ou le nouveau monde, in fine. Mieux vaut considérer l'existant pour ce qu'il est.
Bonjour,
depuis la mise à jour mysql 8 la table performance_shema n'est pas mise à jour. Les dates de modifications des tables sont mises à jour que le soir après 24H.
Est-ce que cela peut se corriger ?
Merci par avance et bonne journée
Alain
Tu peux utiliser ce genre de code pour trouver sur quel cluster se trouve ta SharedSQL:
$server = "xxx.mysql.db";
$result = dns_get_record($server, DNS_CNAME);
$found = False;
foreach ($result as $r)
{
foreach ($r as $k => $v)
{
if (preg_match("/(mysql[\d]{3})\.([^\.]+)\.clouddb\.ovh\.net/", $v, $groups))
{
print("Server name: $groups[1]
");
print("Cluster: $groups[2]
");
$found = True;
}
}
}
if (!$found)
{
print("Unknown server address: $server");
}
?>
Merci @MikaelD1
Je testerai.
Merci pour la réponse.
Server name: mysql119
Cluster: eu001
mais sur un script php de ce style:
> SELECT TABLE_NAME, ROUND(DATA_LENGTH + INDEX_LENGTH) AS TAILLE, ROW_FORMAT, ENGINE, TABLE_ROWS, DATA_FREE, AUTO_INCREMENT, CREATE_TIME, UPDATE_TIME, CHECK_TIME, TABLE_COMMENT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = '?????' ORDER BY TAILLE DESC
J'inclue ces paramètres comment?
Est-ce pour se loger ?
Merci par avance!!!
Alain
Bonjour,
j'ai vu l'état des migrations sur la page :
ovhcloud.com/incidents/cnf2n29hj6s1">https://web-cloud.status-ovhcloud.com/incidents/cnf2n29hj6s1
J'ai des bases aussi sur les clusters eu009 et eu011 qui ne sont pas mentionnés dans la page, avez-vous une date pour leur migration ?
Merci d'avance, Marc
Oui effectivement, on ne les a pas encore commencés. Idem pour eu004.
La cible que je vous avais annoncé en juillet (il faut remonter un peu plus haut dans ce thread) reste la même: 100% de la prod' à jour au 2024-09-30. On fait tout pour !
Bonjour,
Question basique : comment peut-on savoir sur quel cluster sont mes bases de données..
J'ai beau chercher sur mon environnement mais je ne trouve pas.
En fait j'ait deux bases de données, une est passée en V8 et pas l'autre.
Merci.
Bonjour,
Cille dit plus haut, soit via un script soit via l'API.
Cordialement, janus57
Merci pour votre réponse.
Je suis Admin de mon site internet et je ne sais pas faire.
mon site est fait avec Joomla4 et j'attends le passage à MySql V8 pour pouvoir évoluer en Joomla5.
Je vais donc attendre.
Merci.
Quelle importance cela a-t-il pour vous ?
Bonjour,
Pour voir où en est l'avancement des mises à jour des bases de données..
Ce n'est exprimé qu'en n° cluster et comme je ne connais pas le cluster de ma database, je demande donc où l'on peut trouver dette info.
L'importance est de pouvoir basculer mon site en Joomla 5 et que Mysql 5.7 est obsolète.
Merci
Bonjour,
Comme dit plus haut vous avez soit un script soit l'API pour savoir sur quel cluster vous êtes.
Cordialement, janus57
Quel abonnement hébergement OVH avez-vous ?
J'ai un abonnement Pro
Dans ce cas :
Soit vous attendez que OVH fasse la migration.
Soit vous créez une nouvelle base.
- Faites un export de votre base actuelle sur votre PC
Voir dans mon guide le paragraphe :
**Ua - Sauvegarde complète de votre site sur votre PC**
https://www.wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm#_U_%E2%80%93_Sauvegarde
- Créez une une nouvelle base qui sera à la version 8
- Importez votre export de la base de votre PV vers cette nouvelle base.
- Mettez à jour vos identifiants sur le script xxx.php de votre site.
Voir dans mon guide le paragraphe :
**N - Contenu du fichier /www/wp-config.php - Identifiants de la base de données **
https://www.wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm#_N_-_WordPress
**__________________________________________________________________________________**
Voici un petit guide que j'ai écrit et qui pourrait vous apporter des éclaircissements pour **une Installation complète et propre de votre Site**.
**************************************************************************************************
* **Guide - Comprendre la Relation Domaine > Zone DNS > Hébergement > Dossier du site** *
**************************************************************************************************
Voir --> **https://wordetweb.com/word-et-web/WORDPRESS-guide-installation-de-WordPress-premier-domaine-chez-OVH-FR.htm">CMS - WordPress - Guide Installation chez OVH**
Contrôler votre situation en suivant **attentivement** les paragraphes : **A** à **J**
_N'hésitez pas à me faire un retour : positif ou négatif._
_C'est comme cela que je peaufine mon Guide._
_Si ce guide vous a bien aidé, n'hésitez pas à cliquer sur le bouton « j'aime »_
Bonjour @JEAN-PIERREL27
Vous trouverez sur votre espace client onglet FTP-SSH dans l'adresse du serveur vous verrez le numéro du cluster.
Là il s'agit du cluster de l'hébergement. Pas celui de la base de données
Il me semblait que c'était sur le même cluster mais je me trompe peut-être ?
Ok je viens de vérifier avec le code de @MikaelD1 ma bdd est sur eu002 et mon cluster hébergement est 002
Je suppose que si c'est le même pour moi ce n'est pas forcément le cas pour tout le monde
Je crois que dans mon cas c'est la meilleure solution
Merci de vos conseils
J'ai vu ce code.
Mais je ne sais pas comment le mettre en oeuvre.
Autre travers de quel outil ?
J'utilise notepad++
Faire un copier/coller du code en remplaçant les xxx de la première ligne par le nom de la bdd.
L'enregistrer en .php en lui donnant le nom que tu veux par exemple cluster-bdd.php tu envois ce fichier à la racine du site et ensuite appelle ce fichier.
Waw !! Super !! Merci !!!
Ca je sais faire :-) :-)
Ca a marché nickel !!
Ca pourra peut-être servir à d'autres.
Maintenant je sais de quel Cluster surveiller l'évolution des upgrades Mysql.
Bonsoir,
Aie aie aie, je crois que j'ai fait la bêtise à ne pas faire. Je suis en offre perso, et j'ai voulu faire la mise à jour de php7.4 vers 8.0 via le menu OVH. Ma base de donnée est aussi à présent en 8.0
Eeet… j'ai quelques pages importantes de mon site qui buggent, dont les pages de ma boutique…
Je me demande si ce n'est pas lié à un problème au niveau des DATE dans le code…
aussi un problème avec cette ligne qui semble bloquer la suite de la lecture du code :
$nbarticlespanier=count($_SESSION['panier']['libelleProduit']);
Bonjour @SergeR6
Quel CMS utilisez-vous ?
Bonjour,
je n'en utilise pas, c'est douglas.com/">un site codé "à la main" si on peut dire:
douglas.com/">https://www.raoul-douglas.com/
Dans la ligne
$nbarticlespanier=count($_SESSIONhttps://forum.getkirby.com/t/undefined-variable-since-php-8-0/26797/6">'panier']['libelleProduit']);
$_SESSION['panier']['libelleProduit'] est une valeur vide.
J'ai l'impression que c'est quand sql 8.0 rencontre des ordres sur des valeurs vides que ça pèche.
Même chose pour
$reponse = $bdd->query('SELECT * FROM encheres WHERE id_produit="'.$encheres[$i]['id'].'" AND liste_noire!="oui" AND date_enchere >"'.$encheres[$i]['date_debut_enchere'].'" ORDER BY enchere DESC');
$donnees_encheres=$reponse->fetchAll();
quand $encheres[$i]['date_debut_enchere'] est une valeur vide
ça me fait une erreur SQL et me renvoie :
Erreur : SQLSTATE[HY000]: General error: 1525 Incorrect DATETIME value: ''
je n'ai qu'une seule toute petite BDD :
J'ai fait la migration depuis le tableau de bord utilisateur, mais je n'ai pas copié la base de donnée, ou réimporté la base de donnée sauvegardée vers une nouvelle BDD vide.
Ici il est dit apparemment qu'on ne peut plus se permettre qu'une variable ne soit pas définie ou null :
[https://forum.getkirby.com/t/undefined-variable-since-php-8-0/26797/6
Je ne sais pas si c'est ça, je vais vérifier, mais j'avoue que c'est un peu galère si je dois entourer partout mo code de conditions à chaque fois que j'utilise une variable pour vérifier avant que celle-ci ne soit pas null.
Bonjour,
Depuis le passage à MYSQL 8.0, j'obtiens de temps en temps l'erreur :
User 'xxx' has exceeded the 'max_questions'
Pourriez-vous m'en dire davantage sur cette erreur?
Michael +1
Je n'avais jamais eu cette erreur avant, et depuis que OVH nous a annoncé cette migration, cette erreur est apparue plusieurs fois, parfois en bloquant mon site.
Ça ressemble à un dépassement de quotas de requêtes
https://www.google.fr/search?q=User++has+exceeded+the+%27max_questions
Moi non plus rien avant la migration.
Bonjour,
Avez-vous lancé une analyse de votre site pour voir la consommation de requêtes SQL ?
Cordialement, janus57
Perso, dans la page avec le plus grand nombre de requêtes dans les stats du site, je me suis aperçu que j'avais mis récemment une requête dans une grosse boucle "WHILE". J'ai enlevé cette requête de cette boucle, on verra si ça solutionne le problème.
Comme l'a évoqué @MaximeF https://community.ovhcloud.com/community/fr/extreme-lenteur-de-ma-bdd-depuis-8-jours?id=community_question&sys_id=f602d242dcfd56901e119f7f66c0940d">ici, le query cache a été supprimé en MySQL 8.0. Si vous voulez les détails c'est https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/">ici, mais je peux vous résumer un peu tout ça, et surtout vous expliquer ce que ça peut avoir comme conséquence pour vous, et quelle est la solution.
**MySQL 5.7**
Avant MySQL 8.0, quand tu faisais une requête, son résultat était conservé côté serveur dans un cache. Imaginons 2 cas (les chiffres suivants sont donnés à titre d'exemple):
Cas 1: Une requête optimisée, sur une table avec les bons index
Le client fait une première fois la requête. MySQL calcule son résultat, le retourne en 20 ms, et le stock en cache. À la 2ème requête, MySQL cherche dans son cache, retrouve le résultat, et le retourne en 15 ms.
Cas 2: Une requête non optimisée, sur une grosse table sans index
Le client fait une première fois la requête. MySQL calcule son résultat, le retourne en 5 secondes, et le stock en cache. À la 2ème requête, MySQL cherche dans son cache, retrouve le résultat, et le retourne en 15 ms.
**MySQL 8.0**
Les performances de MySQL 8.0 sont bien meilleures que celles de MySQL 5.7 pour la majorité écrasante des requêtes (on l'a constaté). A tel point que maintenir le cache et aller le consulter prenait même plus de temps que de recalculer les résultats… mais pas toujours. Reprenons nos 2 cas.
Cas 1: Une requête optimisée, sur une table avec les bons index
Le client fait une première fois la requête. MySQL calcule son résultat, et le retourne maintenant en 10 ms, grace aux optimisations. À la 2ème requête, MySQL refait la même chose, et retourne le résultat en 10 ms. On a des meilleures perfs, dès la première requête.
Cas 2: Une requête non optimisée, sur une grosse table sans index
Le client fait une première fois la requête. MySQL calcule son résultat, le retourne en 3 secondes. C'est mieux que les 5 secondes en MySQL 5.7. Sauf qu'il ne stock plus les requêtes en cache, et donc les prochaines requêtes prendront, elles aussi, 3 secondes au lieu de 15 ms avant.
**Anti-flood**
Le système anti-flood (celui qui est à l'origine des logs du type "User has exceeded the 'max_questions' resource") n'a pas changé. Pour info, il a vraiment des limites très hautes. Par contre, si tu es dans le cas 2, alors le passage de MySQL 5.7 à 8.0 peut te faire passer une limite que tu n'avais pas franchi avant.
**Solution**
La solution, c'est de repasser dans le cas 1. Dans une majorité écrasante des cas, on a constaté que mettre les bons index suffisaient à résoudre le problème, et augmenter les performances significativement (même par rapport à avant, en MySQL 5.7).
Bonjour,
et c'est confirmé par une personne qui a mis des index sur sa base et "pouf" gain de perf.
Cf : https://community.ovhcloud.com/community/fr/latence-sql-suite-maj-sur-mysql-8-0?id=community_question&sys_id=e2f1da02dcfd56901e119f7f66c09471
Après faut pas non plus se dire que mettre des index "partout" cela va améliorer un site, il faut faire cela de la "bonne manière" sinon cela peut également avoir l'effet inverse.
Cordialement, janus57
Exactement @janus57 tu fais bien de préciser 👍
En effet, à chaque insert / update d'une table, le ou les index concernés sont mis à jour, ce qui a un coût. L'insert / update est donc légèrement plus lent. Mieux vaut donc pas d'index qu'un index qui ne sert pas.
Si vous avez un doute, n'hésitez pas à créer un thread dédié, je suis sûr que quelqu'un pourra vous aider. Requis pour vous aider: la structure de la ou des tables, ainsi que la/les requêtes.
Bonjour,
Je me permets de profiter du fait que vous répondez et que vous vous y connaissez pas trop mal (à priori).
Est-ce que vous auriez des liens qui puissent aider pour les index ?
Car on peut trouver des ressources genre : https://use-the-index-luke.com mais cela serait intéressant de savoir si vous en avez d'autre que vous pouvez conseillé.
Cordialement, janus57
80% des indexes sont extrêmement faciles à créer.
20% peuvent être un enfer et nécessiter énormément d'expérience.
https://use-the-index-luke.com est une excellente référence, mais il adresse surtout le 20% compliqué.
Pour gérer le 80% des indexes classiques, j'irais directement sur la Doc MySQL:
* https://dev.mysql.com/doc/refman/8.0/en/column-indexes.html">Indexes sur 1 colonne
* https://dev.mysql.com/doc/refman/8.0/en/multiple-column-indexes.html">Indexes sur plusieurs colonnes
Je vous la fait en mode très simplifiée pour des cas très simples…
Imaginons cette table:
mysql> create table tbl1 (id int, col1 varchar(255), col2 int);
Et cette requête:
select * from tbl1 where col1='hello';
`explain` va m'aider à voir si j'ai les bons index pour traiter cette requête:
mysql> explain select * from tbl1 where col1='hello';
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| 1 | SIMPLE | tbl1 | NULL | ALL | NULL | NULL | NULL | NULL | 1 | 100.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
`possible_keys`, ce sont les index éligibles pour traiter ma demande. On voit qu'il n'y en a pas.
`key`, c'est l'index qui a été choisi parmis les index éligibles. Ce choix va dépendre des index, mais également de ce qu'il y a dans la table.
Comme dans ma requête j'ai une condition sur une colonne, alors je peux me contenter de créer un index sur cette colonne:
mysql> create index tbl1_idx1 on tbl1(col1);
mysql> explain select * from tbl1 where col1='hello';
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+------+----------+-------+
| 1 | SIMPLE | tbl1 | NULL | ref | tbl1_idx1 | tbl1_idx1 | 1023 | const | 1 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+-----------+---------+-------+------+----------+-------+
Si j'avais une condition sur plusieurs colonnes…
mysql> select * from tbl1 where col1='hello' and col2=42;
Alors il me faudrait un index sur plusieurs colonnes:
mysql> create index tbl1_idx2 on tbl1(col1, col2);
mysql> explain select * from tbl1 where col2=42 and col1='hello';
+----+-------------+-------+------------+------+---------------------+-----------+---------+-------------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------------+-----------+---------+-------------+------+----------+-------+
| 1 | SIMPLE | tbl1 | NULL | ref | tbl1_idx1,tbl1_idx2 | tbl1_idx2 | 1028 | const,const | 1 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------------+-----------+---------+-------------+------+----------+-------+
Ici, on voit que le premier index (celui sur une colonne) aurait pu servir partiellement à traiter ma requête (il aurait servi au premier filtre sur col1, puis il aurait fallu filtrer sans index sur col2). Mais il n'a pas été sélectionné (`key` à `tbl1_idx2`) parceque le 2ème index est plus adapté.
En espérant que ça aide 🙂
Bonjour à tous,
Je suis ravi de vous annoncer que les mises à jour sont maintenant finies.
Toutes les bases de donnée SharedSQL utilisent maintenant MySQL 8.0 sans exception.
Merci de votre patience
Félicitations aux équipes !
Bonjour,
Ce matin toujours le même problème… alors que je n'ai même pas été sur mon site.
Site plus accessible avec : Erreur : SQLSTATE[HY000] [1203] User xxx already has more than 'max_user_connections' active connections.
Du coup le site est down…
EDIT : Quelques minutes après, il remarche.
C'est quand même bizarre.
Bonjour,
Ce message indique que vous utilisez le maximum de connexion simultané autorisé (qui de mémoire est à 30).
Donc soit vous avez des requêtes qui bloquent (car traitement long/lourd) soit votre code ne ferme pas la connexion SQL après exécution.
Cordialement, janus57
Est-ce que ça va si je ferme les connections comme ceci :
foreach ($donnees_gestion as $donnee) {
if (!empty($donnee['pseudonyme'])) {
$pseudonyme = $donnee['pseudonyme'];
break;}}
$reponse->closeCursor();
}
catch(Exception $e)
{
die('Erreur : '.$e->getMessage());
}
ou
foreach ($donnees_gestion as $donnee) {
if (!empty($donnee['pseudonyme'])) {
$pseudonyme = $donnee['pseudonyme'];
break;}}
$reponse=null;
}
catch(Exception $e)
{
die('Erreur : '.$e->getMessage());
}
Le closeCursor m'a donné des problèmes dans certaines pages.
Est-ce que le fait d'interrompre et de sortir d'une boucle avec break; peut faire que le catch(Exception $e) ne soit pas lu ?
Merci d'avance.
A la fin du traitement je mets :
// Fermeture de la connexion SQL
$pdo = null;
PHP ferme seul la connexion à la fin de l’exécution du script.
- Soit tu as vraiment trop de visiteurs simultanés
- Soit tu as des scripts trop lents/lourds/requêtes mal indexé pour l'offre d'hébergement
Bon... L'un va avec l'autre.
Bonjour,
La best practice reste de fermer la connexion le plus tôt possible pour libérer la ressource le plus tôt possible.
Car il suffit d'une boucle ou que le script fasse de multiples traitements avec des appels externes pour manger une connexion SQL pour rien (et dans ce cas c'est facile d'atteindre les 30 connexions simultané).
Cordialement, janus57
Pour initialiser la connexion je fais:
try
{
$pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
$bdd = new PDO(
Donc dans mon cas je crois que ça doit être
`$bdd=null;`
Je vais chercher tous les endroits avec "catch" sur le site et je vais bien mettre ça partout, on verra si cela règle le problème.
Merci à vous en tout cas.
Bonjour,
Exemple issue de la documentation PHP :
[Code]
$dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
// use the connection here
$sth = $dbh->query('SELECT * FROM foo');
// and now we're done; close it
$sth = null;
$dbh = null;
?>
[/code]
Cf : https://www.php.net/manual/en/pdo.connections.php
Cordialement, janus57
Des fois j'ai des
`if($donnees[0]!=0){header('Location:`
et ils sont à l'intérieur des TRY avant que le CATCH ne soit atteint. Du coup je ne sais pas si ça fini de lire le code pour atteindre le CATCH ou si ça redirige tout de suite.
Si ça redirige tout de suite, il faut que je mette le
`$bdd = null;`
juste avant la ligne de redirection header('Location: ??
Pour e^tre bien certain que la connexion soit fermée avant la redirection ?
Merci d'avance.
Bonjour,
vous devez fermer la connexion SQL après avoir récupérer vos données, lors du traitements de vos données la connexion doit déjà être fermé.
Cordialement, janus57
Ah ben voilà, c'est sans doute pour ça. Donc à chaque fois que je fais une requête, je dois faire une nouvelle connexion avec try, puis la fermer juste après avec $bdd=null; et catch, avant de faire une nouvelle requête avec une nouvelle connexion et une nouvelle fermeture.
Dans mes pages, je fais une connexion au début de la page, je fais plein de requêtes et de traitements, et je ferme la connexion à la fin. Ça vient sans doute de là.
Donc avant chaque query->, un try, et tout de suite après, un $bdd=null; et un catch.
Ça pourrait même résoudre le problème de requêtes dans les boucles "for".
> Donc soit vous avez des requêtes qui bloquent (car traitement long/lourd) soit votre code ne ferme pas la connexion SQL après exécution.
C'est aussi fort probable que j'ai des "_requêtes qui bloquent (car traitement long/lourd)_". Comment savoir si cela peut venir de là et pas des problèmes de connexions pas assez régulièrement fermées ? Parce que le message parle bien de 'max_user_connections', et pas 'max_QUERY_SIMULTANEOUS' (ou un truc du genre)
EDIT : Suis-je vraiment obligé d’ouvrir et de fermer à chaque query ?
Par exemple sur cette partie de code :
try …
if(isset($newid) and !empty($newid)){$reponse = $bdd->query('UPDATE boutique SET
id = COALESCE("'.$newid.'",id) WHERE id="'.$id.'"');}
if(isset($auteur) and !empty($auteur)){$reponse = $bdd->query('UPDATE boutique SET
auteur = COALESCE("'.$auteur.'",auteur) WHERE id in ('.$id.')');}
if(isset($biographie) and !empty($biographie)){$reponse = $bdd->query('UPDATE boutique SET
biographie = COALESCE("'.$biographie.'",biographie) WHERE id in ('.$id.')');}
… autres requêtes IF…
$bdd=null;
catch (fermeture)
Dois-je dans ce cas vraiment ouvrir et fermer avant et après chaque QUERY UPDATE ??
Bonjour,
Le meilleur moyen pour le moment est déjà d'optimiser le code (et peut être aussi la BDD avec des index il ou il faut), puis voir dans les graphiques OVH si cela améliore les temps.
Je ne sais pas comment est fait votre code mais la j'utiliserai une fonction pour gérer la partie SQL.
Note : je vous conseillerais de faire un nouveau post avec un récapitulatif car là on dépasse la simple migration en MySQL8 qui étais le but de ce topic.
Cordialement, janus57
Bonjour Kiwa avez-vous finalement trouvé une solution pour votre blog ? Moi aussi j'ai 3 blogs Dotclear sur un hébergement OVH mutualisé, tous en panne depuis le passage à MySQL 8. Aucune solution trouvée sur le forum Doctlear :(
Bonjour
Votre CMS Doctlear était-il à la dernière version juste avant la migration MySQL 8 ?
Bonjour Gaston, non, pas à jour, j'étais / je suis à la version 2.11 quand la version actuellement proposée par Dotclear est 2.31.