Bonjour,
OVH m'a annoncé une migration de mon site web et depuis, la base de données est régulièrement plantée alors qu'avant il n'y avait jamais de problème.
L'assistance me répond que mes requêtes sont trop lourdes. Alors j'ai mis en ligne une page qui ne comporte que la connexion mysqli, sans requête. J'ai mis le site sur écoute, minute par minute, sur l'excellent updown.io : les perturbations sont toujours là, intermittentes. Si je retire toute connexion à la bdd, le rapport de updown est au vert total.
C'est mon 3ème site ayant fait l'objet d'une migration de serveur, depuis décembre, à subir ces dysfonctionnements (ils sont en ligne depuis des années et n'ont pas connu de changement).
Avez-vous remarqué ce genre de problème après migration ?
Le script n'a pas lieu d'être en cause, vu qu'il fonctionnait très bien avant et qu'il continue de bien fonctionner 22 heures par jour, en dehors des passages perturbés, mais je l'indique tout de même, il se résume à :
define ("SERVEUR", "mysql57-85.perso");
define ("NOM", "login");
define ("PASSE", "mot_de_passe");
define ("BASE", "nom_de_la_base");
function Connexion ($pNom, $pMotPasse, $pBase, $pServeur)
{
// Connexion au serveur
$connexion = mysqli_connect ($pServeur, $pNom, $pMotPasse, $pBase);
if (!$connexion)
{
echo "Désolé, connexion au serveur impossible\n";
exit;
}
// Paramètre pour UTF8
mysqli_query($connexion, "SET NAMES UTF8");
// On renvoie la variable de connexion
return $connexion;
} // Fin de la fonction
$connexion = Connexion (NOM, PASSE, BASE, SERVEUR);
Merci
Stéphane
Base de données perturbée
Sujets apparentés
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
63931
03.09.2018 14:46
- Connexion à mon compte client
58008
13.02.2019 09:51
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
49960
14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
34335
28.07.2017 11:39
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
29792
16.10.2016 16:24
- Augmenter taille PHP Post Max Size sur mutualisé ?
28238
04.12.2019 21:52
- The requested URL / was not found on this server
27849
02.03.2017 18:25
- NextCloud sur mutualisé
27208
07.04.2017 08:42
- Deploy d'un projet Node JS
27074
12.10.2016 20:18
- Passage en php 7.4
24847
30.06.2020 05:05
> mysql57-85.perso
tu peux essayer en changeant le nom et en utilisant le serveur indiqué dans ton manager?
tu vois quelle version mySql?
J'ai changé le nom comme indiqué et en moins de 15 minutes j'ai vu l'indicateur updown.io remonter vers le vert ! Ce serait donc juste ça ?! Dans ce cas, pourquoi OVH, avant changement de serveur, n'indique-t-il pas que le nom du serveur de bdd doit être changé ? Cela m'aurait évité bien des ennuis avec un client… Et surtout, pourquoi l'ancien nom continue-t-il a être admis, mais pas tout le temps… Incompréhensible. En tout cas, un grand merci kyodev. J'attends encore une heure ou deux pour voir si la base de données fonctionne correctement et je refais un post pour confirmer.
Merci
Stéphane
j'ai une hypothèse, mais rien de sûr je ne connais pas l'infra Ovh
tu as/aurais dû être prévenu: https://www.ovh.com/fr/webhosting-migration/
si tu as un accès ssh, j'aimerais bien voir l'entête d'un dump sur le vieux serveur, juste la version du serveur mySql:
```sql
mysqldump -d mysql57-85.perso -u login -pmot_de_passe > dump-struct.sql
```
Je connexion semble pleinement rétablie, c'était donc juste cette bête histoire de nom qui posait problème.
J'ai mené ma petite enquête : le mail d'OVH annonçant la migration ne donne pas ce lien vers la page webhosting-migration/, mais le mail de confirmation de migration terminée propose le lien en question dans cette phrase : _Si toutefois vous constatez un dysfonctionnement, vous pouvez consulter la documentation spécifique à cette opération en cliquant **ici**._
Le problème ne concerne peut-être que peu de clients, alors il n'a pas été jugé nécessaire de donner des indications plus explicites. Sur la page en question, il est indiqué au paragraphe 2 : _Quel en sera l’impact pour mon site web ? _
_Aucun changement n’est prévu sur votre site internet. Nous conserverons l'ensemble des configurations appliquées : versions de PHP, multisite, bases de données, etc._
Et au § 3 : _Que dois-je faire pour migrer ? _
_Aucune action de votre part n’est requise concernant cette migration. Celle-ci sera transparente et automatique._
Effectivement, plus bas, au § 5, il est mentionné : _L’utilisation du nom du serveur de base de données « bdd.mysql.db » est fortement recommandée_
_Historiquement, les serveurs de bases de données prenaient la forme « mysql51-123.pro » ou « mysql55-123.perso ». Un format plus générique est maintenant disponible : « NomBaseDeDonnées.mysql.db ». Il nous permet de déplacer votre base de données en cas de surcharge de votre serveur vers un autre, moins sollicité._
_Nous n’avons pas encore rendu cette fonctionnalité obligatoire sur les comptes que nous allons migrer. Si votre hébergement est concerné, vous recevrez ultérieurement un e-mail vous communiquant les opérations à effectuer._
Depuis décembre, les réponses de l'assistance OVH n'ont pas pu me donner cette explication. On m'a juste dit que mes requêtes étaient sans doute trop lourdes. Je vais leur faire un courrier pour leur mentionner cette possibilité que le nom du serveur peut être en cause, au cas où d'autres clients seraient confrontés au même problème.
Je ne passe pas avoir d'accès ssh pour effectuer la requête proposée, vu que les sites sont en mutualisé. Cette possibilité ne concerne-t-elle pas uniquement les serveurs dédiés ?
Merci en tout cas kyodev, ta réponse m'a apporté un immense soulagement. Je suis même allé jusqu'à transférer le 1er de mes sites concerné par ce problème sur un hébergement pro (qui tolère sans broncher l'ancienne adresse de serveur de bdd), où il tourne bien depuis 2 mois grace à l'option d'hébergement multisite. Il va pouvoir rentrer à la maison !
Un dernier point updown : tout est rentré dans l'ordre ! L'informatique ne cessera jamais de me surprendre...
Stéphane
tu perds ton temps à vouloir former le support... s'il n'y avait que ça
dans la doc, il est dit aussi qu'un tunnel permettait de relier les datacentres, je me demandais si les vieilles bases restaient à Paris, donc avec une latence importance due au tunnel
le ssh est dispo à partir de l'offre dite *"pro"*, en mutu
mais si tu ne sais pas manipuler SSH, ce n'est pas grave
J'ai tout de même posté mes explications à l'assistance OVH. Même si elle est peu réactive, dans le doute, il est préférable de transmettre l'info, en croyant un peu aux miracles.
Merci en tout cas.
Stéphane
Salut
Même si ton problème semble résolu, pourrais tu SVP (STP) voir si tu constates régulièrement des temps de connexion à la bdd anormalement élevé ? entre 200ms et 1s ?
Car si ta connexion fonctionnait mais été parfois très lente avec l'ancien nom de serveur (.perso) il n’est pas impossible qu'avec le nouveau des lenteurs moins importantes (pour le moment) mais anormales soient présentes de façon aléatoire.
J'ai un problème similaire pourtant j'ai le bon nom de serveur : https://community.ovhcloud.com/community/fr/passage-a-mysql-5-6-temps-de-connexion-bdd-eleve?id=community_question&sys_id=c2b4b10cf19e42d01e11e7bb9bf10372
Si tu pouvais faire un petit log ou tu choppes les temps de connexion (uniquement la connexion) dépassant 200ms , ça serait très sympa :)
Ceci afin de voir si c’est leur infra (gestion du host...) qui provoque des temps de connexion régulièrement élevés. Voir même un pb de configuration avec le passage à mysql 5.6.
Bonjour,
J'ai malheureusement interrompu l'écoute via updown.io après avoir nettement constaté que tout était rentré dans l'ordre sur 2 sites différents. Mais des écoutes précédentes m'ont montré que même sur des sites qui tournent bien à 99,99 %, il y a de temps en temps des temps de réponse au-delà de la seconde, même si c'est extrêmement rare.
Ce que je peux te conseiller, c'est de créer plusieurs pages test sur ton serveur, inaccessibles depuis le site bien sûr, pour faire des comparaisons (au besoin avec un service de surveillance) :
une page ne contenant que du html,
une page se bornant à se connecter à la bdd,
une page lançant une requête simple
et enfin une ou plusieurs pages avec des requêtes plus fournies.
C'est ainsi que j'ai pu réfuter la thèse d'OVH accusant des requêtes trop lourdes : une simple connexion à la base, sans aucune requête, entraînait les mêmes perturbations que sur les pages soi-disant trop lourdes.
Bon courage !
Stéphane
Bonjour
Je te remercies, j'ai déjà testé avec une simple page qui fait une simple connexion à la bdd et je constate les mêmes perturbations.Je n'arrive absolument pas à déterminer l'origine de cette perturbation. J'ai même essayé en créant une autre bdd avec aucune table et donnée et je constate également ce type de perturbation (moins fréquente pour le moment) mais bien présent. A la 1ere connexion ou après un temps d'attente la connexion met entre 200ms et 1s, voir même un peu plus.
Ce qui est étonnant c'est que ça semble étroitement lié à Mysql 5.6. Avec Mysql 5.5 pas de problème de ce type constaté.
faut pas oublier que l'on parle de serveurs mutualisés chez Ovh
tu avais peut-être la chance d'avoir un serveur mySql5.5 au top, mais ce n'est plus le cas sur le mySql5.6?
il faut se méfier des généralités sur 1 constat
J'ai 4 sites sur 4 serveurs mutualisés différents. Mes réflexions se basent sur les tests que j'ai pu faire sur du 5.6 et 5.5 sur des serveurs mutualisés et serveurs SQL différents (mutualisés et SQL privés). Je ne généralise pas vraiment je fais part des soucis que je rencontre et des fais constatés pour le moment. ;)
Après je dis bien que "ça semble" lié à Mysql 5.6, mais je ne peux évidemment pas en être certain.
Si d'autres personnes peuvent identifier ce même type de problèmes sur Mysql 5.6 ça réglerait pas mal de questions. Enfin je pense.
Sur du 5.5 j'avais par exemple 4-5 enregistrements dans mes logs. Seulement des requêtes qui mettaient plus de 200ms. Au passage sur du 5.6 je n'ai plus aucune requêtes qui met plus de 200ms mais j'ai plus de 60-70 enregistrements dans mes logs de connexions qui mettent entre 200ms et plus d'1s. c'est une vraie galère pour en tirer des conclusions et faire des tests.
les seuls tests intéressants que je vois pour le moment c'est de voir le comportement des temps de connexions sur d'autres serveurs et d'autres sites autres que les miens. :/
Il est fort possible que beaucoup de clients n'ont pas fait attention à ça car ils ne contrôlent pas les temps de connexion mais le temps d'exécution d'une requête de plus d'1s (pouvant englober le temps de connexion); par conséquent ça peut peut être passer inaperçu pour la plupart.