Ça y est, les mises à jour des SharedSQL de MySQL 5.6 à 5.7 sont lancés! 🚀
**De quoi parle t'on?**
Les bases de données livrées avec votre hébergement web, appelées également «SharedSQL» ou «Bases de données MySQL mutualisées», tournent actuellement en MySQL 5.6. Toutes, sans exception. Elles vont être mises à jour dans la version majeure suivante: MySQL 5.7.
Dans votre Control Panel, univers web, sélectionnez votre hébergement web dans la section «Hébergements» du menu de gauche, puis allez dans l'onglet «Bases de données». C'est de ces bases là dont on parle. On ne parle PAS des CloudDB que vous pourriez avoir dans la section «Bases de données» du menu de gauche: celles là sont déjà à jour.
**Quand et comment se font les mises à jour? Quel impact?**
Les mises à jour commencent… maintenant. Le process de mise à jour est entièrement automatisé, hautement parallélisable, et techniquement on pourrait avoir fini avant que vous n'ayez le temps de lire ce post, même si on a 1.2 million de bases à mettre à jour.
Sauf que voila, un si grand nombre de bases implique une loi bien connue des statisticiens: la loi des très grands nombres (à ne pas confondre avec la loi des grands nombres). Cette loi dit que dans un échantillon d'une taille suffisamment grande (comme par exemple 1.2 million de bases de données), même les évènements les plus improbables et extravagants finiront par se produire. Et croyez moi, on en a vu des choses improbables 😄
Pour contrer ça, on va utiliser une méthode bien connue des Sysadmins qui travaillent sur de très grosses plateformes. Ça s'appelle le «Canary Deployment», «Canary Rollout», «Smooth Seployment», ou même le «1, 10, 100, Tous». Bref, on va étaller les mises à jour au maximum. Les mises à jour se termineront donc fin septembre. D'ici là, elles se feront tous les jours, du lundi au jeudi inclus (sauf le 15 août, férié en France).
Notez que c'est la 4ème fois que l'on opère une mise à jour de version majeure, massivement. Il y a quelques années, on a passé tout le monde de MySQL 5.0 à 5.1, puis de 5.1 à 5.5, puis de 5.5 à 5.6 et maintenant de 5.6 à 5.7.
Comme je vous le disais un peu plus haut, la migration a déjà été faite sur les CloudDB (il ne reste plus aucun CloudDB MySQL 5.6, tout le monde est passé en 5.7).
**Qu'est-ce que ça change?**
La liste complète des changements entre MySQL 5.6 et MySQL 5.7 est ici. En 3 mots: "elle est gigantesque". Je vais donc tenter de résumer l'essentiel:
* Le SQL mode par défaut passe de:
NO_ENGINE_SUBSTITUTION
à:
ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
Pour comprendre ce que ça veut dire, je vous invite à aller lire l'article de Fabien sur le blog, ou ce commentaire que j'avais écrit il y a quelques temps. Si on laissait passer ce changement tel quel, une quantité de sites auraient clairement «cassé». Un peu à contre-cœur, donc, nous avons laissé le SQL mode de MySQL 5.6, plus permissif que celui de MySQL 5.7.
* Les CMS les plus massivement utilisés (WordPress, Joomla, Drupal, Prestashop) qui fonctionnaient en MySQL 5.6 continuent à fonctionner en MySQL 5.7, même pour les versions les plus vieilles.
* Les CMS qui ne fonctionnaient pas à cause d'une version trop vieille de MySQL se mettront à fonctionner.
* Pour finir, je vais vous parler d'un dernier cas assez étonnant qui, d'après ce qu'on a constaté sur l'ensemble de vos bases, ne concerne qu'une extrême minorité de personnes (on parle de 0.008%). Un bug présent dans MySQL 5.6 mais corrigé dans MySQL 5.7 faisait qu'il était possible de créer des tables comportant plusieurs centaines de colonnes.
Ce bug a été corrigé, ce qui fait que des tables à plusieurs centaines de colonnes créées sous MySQL 5.6 (qui a un innodb_strict_mode à 0) n'est par défaut plus possible sur MySQL 5.7 (qui a un innodb_strict_mode à 1). Le contournement consiste à forcer le innodb_strict_mode à 0 lors de la création de votre table. Une base de données relationnelle permet d'organiser ses données en différentes tables, et de créer des relations entre elles. Créer une table à plusieurs centaines de colonnes va à l'encontre de ce modèle et n'a, à notre sens, rien à faire dans un SGBD relationnel.
**Pourquoi pas MySQL 8.0?**
MySQL 5.7 n'est pas la dernière version de MySQL (c'est la 8.0). Alors pourquoi ne pas passer directement à celle-ci? Tout simplement parce qu'une mise à jour majeure de MySQL doit impérativement passer par toutes les versions majeures intermédiaires. Sauter 2 versions majeures n'est pas supporté. On passe donc maintenant à la version 5.7, et on prévoit la mise à jour en 8.0 avant la fin de vie de la 5.7, fin 2023.
**Des questions? 🤔**
Si vous avez des questions liées à ces mises à jour, n'hésitez pas à les poser ici, ou a créer un sujet dédié. On essayera d'y répondre au mieux. 😊
La team Web Cloud Databases
SharedSQL: mises à jour vers MySQL 5.7
Sujets apparentés
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
63944 
03.09.2018 14:46
- Connexion à mon compte client
58043 13.02.2019 09:51
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
50007 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
34340 28.07.2017 11:39
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
29794 16.10.2016 16:24
- Augmenter taille PHP Post Max Size sur mutualisé ?
28249 04.12.2019 21:52
- The requested URL / was not found on this server
27855 02.03.2017 18:25
- NextCloud sur mutualisé
27213 07.04.2017 08:42
- Deploy d'un projet Node JS
27079 12.10.2016 20:18
- Passage en php 7.4
24852 30.06.2020 05:05
Merci @MikaelD1 pour cette explication très compréhensible par tous.
Bon courage pour cette migration.
Il serait utile d'indiquer quel sera l'impact pour les sites concernés, par exemple pendant la migration, qu'en sera-t-il des transactions en cours ?
Merci! 😊
Pour t'expliquer l'impact, je vais te détailler un peu comment se fait une mise à jour, et le timing associé:
1. Étapes préliminaires: tests automatisés, backup…
2. On lance l'arrêt de MySQL. Pendant le temps de l'arrêt, MySQL va empêcher les nouvelles connexions, et terminer les transactions en cours. Très généralement, cette étape se finit en ~5-10 secondes. Mais si des transactions trainent, elle peut durer jusque 60 secondes. Si au bout de 60 secondes il reste des transactions, elles sont annulées. Dans tous les cas, la base est dans un état consistant.
3. On met à jour MySQL. Cette étape dure de l'ordre de 1-2 secondes (si si! 😃)
4. On lance un https://dev.mysql.com/doc/refman/5.7/en/mysql-upgrade.html mysql_upgrade.
5. On démarre MySQL.
6. On relance la batterie de tests.
Il y a donc un downtime entre 2. et 5., compris grosso-modo entre 15 secondes et 1 minute 15. Les bases sont toujours dans un état consistant. Les IP ne changent pas (pas de propagation DNS à prévoir).
Merci @MikaelD1 pour toutes ces précisions.
Super explication. Rien à ajouter. Bravo les gars.
Bonjour,
les mises à jour de drupal 9.4.x nécessitant une version de mysql en 5.7 mini, est-il prévu de prioriser les hébergements qui ont installés ce module?
Cdlt,
Non, et ce pour 3 raisons:
* Pour connaître la liste des hébergements utilisant un CMS particulier dans une version donnée, il nous faudrait regarder sur l'ensemble des web. On en a 3 millions. C'est faisable, mais long, et la liste bouge constamment.
* Sur cette offre, les instances MySQL sont mutualisées. Ça veut dire qu'une instance est utilisée par plusieurs clients. La probabilité pour qu'un instance contienne au moins un client qui a un CMS particulier est extrèmement forte. Dis autrement, même si on listait les instances à prioriser, il est fort probable pour que la réponse soit «toutes».
* La migration est finie dans moins d'un mois.
Par contre, si tu veux qu'on priorise la ou les instances sur lesquelles tu as ta base de données, envoie moi un message privé avec le nom de ta base, et/ou à @FabienB42.
@MikaelD1
Bonjour,
désolé, je vais passer pour un neuneu mais comment on envoi un message en privé?
Je n'ai pas de bouton "message privé ou autre en affichant ton profil...
Bonjour @MathieuD44,
Tu cliques sur mon nom juste au dessus de ce message, puis en haut, à droite tu verras "Message privé".
Je te contacte en message privé pour avoir le nom de ta base
Bonjour,
Pas pour les nouveaux inscrits au forum (restriction).
Cordialement, janus57
Effectivement, merci @janus57
@MathieuD44 il est aussi possible de laisser en réponse ici même le nom de ta base
Bonjour à tous,
Comme annoncé par @MikaelD1 à la création de ce post, les mises à jour devaient s'étaler jusque fin septembre.
Fin septembre est là, et j'ai le plaisir de vous annoncer que les mises à jour viennent de se terminer !
L'intégralité de vos bases de données - Soit environ 1,2 millions de bases - est maintenant en version 5.7
L'intervention est terminée, mais n'hésitez pas à nous remonter tout dysfonctionnement que vous pourriez constater.
La team Web Cloud Databases
Bravo à l'équipe !
Bravo pour la mise à jour vers 5.7 qui est passée inaperçue de mon coté :)
Des nouvelles de la mise à jour vers la 8.0?
Merci!
Bonjour,
Mes bases de données sont toujours en MySQL v.5.7
Je ne sais pas comment changer leur version.
Ca va se faire tout seul ?
Merci d'avance pour votre réponse
Pour les «https://www.ovhcloud.com/fr/web-cloud/databases/ Web Cloud Databases» ou «CloudDB», les upgrades sont en cours, et seront terminés d'ici 2 semaines environ. Tu peux forcer l'upgrade toi même depuis ton Manager.
Pour les bases de données livrées avec ton hébergement web, appelées également «SharedSQL» ou «Bases de données MySQL mutualisées», on attaque le sujet fin avril. On prévoit d'avoir upgrade 100% de la prod d'ici fin juillet.
Dans les 2 cas, aucune action de votre part n'est nécessaire 🙂
Bonjour @MikaelD1 ,
Je viens de faire l'acquisition d'un SharedSQL ou Bases de données MySQL mutualisées. Mes projets sont exclusivement sous Joomla5 et MySQL8. @MikaelD1, vous indiquez dans votre précédent message que les upgrades des SharedSQL débute fin avril.
Si, aucune base n'est installée sur un compte client, sommes nous prioritaire et pouvons nous espérer avoir l'offre SharedSQL en version 8 des ce mois d'avril?
Ou non, vous me conseillez de prendre dès maintenant un WEB CLOUD DATABASES en SQL8 pour 3 mois maximum puis de repasser sur l'offre mutualisée en juillet ?
Merci d'avance pour votre réponse.
Bonjour @AlexandreL99,
Comme annoncé dans mon post précédent, les upgrades des Web Cloud Databases est bien terminé, et le sujet de l'upgrade des SharedSQL a bien commencé. Par contre, ça ne veut pas dire qu'on a commencé les migrations: on en est toujours à la phase de tests et de mise en place de contournements de régressions qu'on a pu rencontrer, pour que tout se passe de la façon la plus transparente possible. Pour te donner une idée, on a un peu plus d'un million de bases de données à mettre à jour 🤯
Pour répondre à ta question, donc: non, les SharedSQL ne seront pas en version 8 dès ce mois d'avril. Idem pour les nouvelles installations. Par contre effectivement, on va faire en sorte que les nouvelles installations se fassent directement en MySQL 8.0, puis on upgrade toute la prod.
Mikaël
Bonjour @MikaelD1,
As tu des informations fraiches sur le planning de migration des SharedSQL en MySQL 8.0 ?
Tu as parlé de mai/juin/juillet, il n'y a pas d'agenda plus précis ?
Merci d'avance
Hervé
au 12 aout 2024 la mienne est encore en 5.7, je pense qu'ils ont dû avoir du retard.
Bonjour,
voir la tâche : https://web-cloud.1ovhcloud.com/incidents/cnf2n29hj6s1ovhcloud.com/incidents/cnf2n29hj6s1
Les migrations sont échelonné et était en pause pour les JO.
Cordialement, janus57
Bonjour,
Comment connaitre le cluster qui héberge ma BD ?
A ce jour, la BD d'origine est toujours en MySQL 5.7.
(Une BD faite ce jour par création/copie est bien en 8.0)
Merci
Hervé