[Terminé] Remplacement du serveur MySQL prévu pour le 27/04 à 1h Paris

Les annonces officielles de FranceServ Hébergement.
Répondre
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Bonjour,

Suite à la précédente maintenance du 21/04/2016 (topic-3299-termine-maintenance-jeudi-21 ... tml#p18210) qui avait pour but d'effectuer un essai de migration du serveur MySQL vers une machine plus puissante, je vous informe que les essais sont vraiment concluants.

D'ailleurs, en effectuant aujourd'hui à 14h57 sur le serveur MySQL en production un petit test (mysqltuner.pl) pour vérifier ce qu'il y avait à optimiser afin de comparer avec la nouvelle machine, l'actuel serveur MySQL n'a vraiment pas apprécié et ça a bien secoué ses feuilles quelques secondes ... C'est pour dire que ce remplacement est plus que nécessaire et vas faire beaucoup de bien aux services.

Je vais alors procéder dans les prochains jours au remplacement de la machine MySQL par cette nouvelle plus robustes et bien plus puissante.

Je reviens vers vous dès que j'ai une date pour cette migration qui devrait durer moins de 30 minutes. Je vous préviendrais bien sûr 24 ou 48 heures avant et je ferai cette maintenance la nuit.

Aucune modification sera nécessaire de votre coté, je m'occupe de tout.

Dernière information :

Je procéderai à l'intervention dans la nuit à partir de 1h du matin (heure de Paris) ce mercredi 27 avril 2016, cette maintenance rendra indisponible l'ensemble des services pendant environ 30 minutes.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Dernière information :

Je procéderai à l'intervention dans la nuit à partir de 1h du matin (heure de Paris) ce mercredi 27 avril 2016, cette maintenance rendra indisponible l'ensemble des services pendant environ 30 minutes.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Bonjour,

Je vais démarrer la maintenance dans moins de 2 minutes. On se retrouve alors dans une demi heure voir 1 petite heure :)
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Maintenance terminée, l'ensemble des services sont de nouveau disponibles.

Je procède maintenant à un dernier contrôle complet des services afin de déceler un éventuel problème.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

elodie a écrit :Je procède maintenant à un dernier contrôle complet des services afin de déceler un éventuel problème.
Je ne vois toujours pas de problème de mon coté, les services sont plus rapides pour certaines tâches et bien plus stables qu'avant. Par exemple je ne vois plus les problèmes "MySQL server has gone away" qu'il y avait parfois avant. C'est un succès !

Nous sommes alors passés de MySQL 5.6.16 d'une machine de 2012 à la dernière version stable 5.7.12 sur une nouvelle machine de 2016 en RAID 5 SSD avec 64 Go de RAM DDR4 ECC.

Si vous constatez des soucis sur votre site, n'hésitez pas à ouvrir un sujet de discussion sur le forum afin que je regarde en détail.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Bonjour,

La nouvelle branche de MySQL 5.7 possède des gardes fous ainsi que des mécanismes de sécurités qui bloquent certaines requêtes MySQL incorrectement écrites, non optimisées ou encore qui ne satisfont plus à certaines nouvelles conditions d'écritures syntaxiques SQL.

J'ai retiré un de ces gardes fou (STRICT_TRANS_TABLES de la variable d'environnement sql_mode) lors du dernier redémarrage du serveur MySQL à 18h17 afin de diminuer le mode paranoïaque du service MySQL.

Le mode STRICT_TRANS_TABLES rendait impossible entre autre l'enregistrement MySQL d'une propriété vide "", elle devait être obligatoirement renseignée ou NULL et j'ai considéré que c'était un trop gros changement dans l'écriture SQL (même si les créateurs de MySQL ont raisons de forcer par défaut, les utilisateurs à optimiser leurs requêtes MySQL).

Cependant, je ne pourrai pas retirer tous les gardes fou car ça amoindrirai la stabilité et la rapidité du nouveau serveur MySQL.

Je continue à vérifier de mon coté ce qui ne vas pas et si vous avez un soucis, n'hésitez pas à m'en faire part. Par contre, communiquez également avec l'équipe de développement de la solution Web que vous utilisez afin de faciliter les corrections.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Bonjour de nouveau,

J'ai retiré un nouveau garde fou (ONLY_FULL_GROUP_BY) de la configuration MySQL 2016 car un même problème se retrouvait sur bon nombre de sites hébergés.

Normalement, il ne devrai plus avoir aucun problème MySQL dû à la migration de la nuit dernière.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Inconnu
Cet utilisateur a supprimé son compte et n’existe plus.
Messages : 6340
Inscription : 29 décembre 2010 à 18:15

Bonjour,

j'ai eu un bug qui est apparu il y a moins de 24h (donc probablement lié à cette migration).

Une requête SQL testait si une date était absente ainsi:

Code : Tout sélectionner

SELECT * WHERE date="00-00-0000"
et cela a fait planter la page.

La correction est facile: mettre l'année en premier,

Code : Tout sélectionner

SELECT * WHERE date="0000-00-00"
Le code sous-jacent (assez vieux et non mis à jour) est en cause et non cette migration qui nous offre de meilleures performances :-)

mais je poste tout de même mon soucis et sa correction au cas où d'autres utilisateurs rencontrent le même soucis

Merci encore pour le très bon service d'hébergement dont j'aurai du mal à me passer :)
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

oliverpool a écrit :mais je poste tout de même mon soucis et ca correction au cas où d'autres utilisateurs rencontrent le même soucis
Merci pour le retour :)
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Avatar de l’utilisateur
Elodie
Fondatrice / Responsable
Fondatrice / Responsable
Messages : 7937
Inscription : 2 avril 2010 à 20:14

Bonjour de nouveau,

J'ai à nouveau retiré un autre garde fou (NO_AUTO_VALUE_ON_ZERO) de la configuration MySQL 2016 car quelques sites non optimisés ne fonctionnaient plus correctement.

Ce mode empêchait la déclaration d'un champ Auto-Increment vide, NULL ou 0 dans un INSERT, pour la simple et bonne raison que c'est inutile. Sauf que quelques anciens développements PHP procèdent encore ainsi.
Vous avez une question ? Posez-la de préférence sur le forum et si ça demande un contact plus instantané, n'hésitez pas à vous rendre sur le t'chat IRC. Si votre question est personnelle, contactez-nous directement.
Répondre