[saxgard]

Pour résumer je dirais ceci :

SQL mutualisés :

- Plus performant dans 90% des cas

Dans les 10% restants on rencontre les soucis suivants :

- temps de connexion à la BDD pouvant dépasser les 2s
- temps d’exécution des requêtes parfois élevés. Problèmes au niveau du "opening table", "statistic", "waiting for locking query" (vérification effectuée via "SHOW profile)
- Ces problèmes semblent plus fréquents en innodb (quoi que..)

J'ai fait des tests sur 4 serveurs SQL mutualisés différents (dont 2 en 5.1 et 2 en 5.5).

Faite le test avec un simple fichier contenant 2-3 requêtes mysql, vérifiez le temps d’exécution de la connexion à la bdd et des requêtes et un show profile pour chaque requête et vous pourrez surement constater les mêmes soucis lorsque vous actualiserez plusieurs dizaines de fois. Le soir entre 1h et 3h, le problème est d'autant plus fréquent.

SQL privé avec la configuration de base :

- En innodb (pas vérifié avec Myisam), des soucis avec les update qui mettent parfois plus d'1s sans raison apparente et même sur des tables quasi vides (quelques dizaines d'enregistrements) avec index bien définies etc. Ce problème est d'ailleurs également constaté sur les mutualisés (soucis au niveau du query end).
- Manque d'infogérance comme pour les sql mutualisé, pouvant nous bloquer plusieurs heures voir plusieurs jours (support peu réactif)
- Nécessite de très bonnes connaissances en configurations de serveur sql. Ce que je n'ai pas.

Un SQL privé infogéré et mieux configuré par défaut en fonction du moteur qu'on utilise (innodb ou myisam) serait certainement le meilleur choix. Mais pour l'instant...

[cavapulser]

@Saxgard
Donc, contrairement à ce qu'on lit souvent ici, tu trouves ton "SQL privé" plus réactif/efficace que les bases en mutualisé pur ?

Pour ma part, je suis aussi en SQL Privé

[saxgard]

Bon la sauvegarde s'est débloquée toute seule après plus de 2 jours. mais je suis retourné à nouveau sur les SQL perso mutualisé.
Cependant je trouve que les serveurs MYSQL mutualisés semblent poser quelques soucis : des requêtes qui mettent parfois bcp plus de temps que la normal, ou une simple connexion a la BDD qui met parfois plus de 2s. je pensais que le problème avait été résolu depuis, mais bon c’est peut être normal sur des serveurs mutualisés.

[saxgard]

Oui je peux me connecter a ma Bdd et le site est toujours actif. Mais l'actio sauvegarde reste bloquée et marque toujours en cours. je tenterais de faire un redémarrage une fois que j'aurais fait quelques vérifications et pris les devant au cas ou le redémarrage bloque également et fonctionne pas et fait tout planter le site.

[madmax69]

@saxguard moi c'est sqlprivé 001, finalement il est plus marqué comme quoi il redémarre, mais il n'est pas pour autant accessible. Toi tu peux te connecter à tes bases de donné?

[saxgard]

Bonjour

Ca m'indique toujours "action en cours" 24h plus tard !

[ebea]

Bonjour,

même problème sur mon sql prive (19). La sauvegarde automatique programmée se contente juste de créer un répertoire, vide , dans mon /dump. Les sauvegardes manuelles fonctionnent une fois sur deux. J'en ai tenté une ce matin, le répertoire /dump/2015/09/06 reste désespérément vide ...

[Gaston_Phone]

Et oui.

[saxgard]

@Gaston_Phone : j'utilise déjà cette méthode également , je voulais essayer la sauvegarde via l'admin du SQL privé. J'imagine même pas ce que ca doit donner quand on programme des sauvegardes régulières sur le SQL privé. Si ça plante de cette façon c'est super fiable !!

[Gaston_Phone]

@Gaston_Phone : j'ai tenté une sauvegarde directement via l'administration du sql privé sur le site d'OVH.

Essaie avec cette méthode --> OVH - Sauvegardes et Restaurations de Bases de Données via un script

[saxgard]

@madmax : Je ne sais pas si le problème est identique, tu es sur quel serveur privé? je suis sur le 16
@Gaston_Phone : j'ai tenté une sauvegarde directement via l'administration du sql privé sur le site d'OVH

Pas très rassurant de voir ce genre de problème avec le sql privé. J'hésite fortement a repasser sur les sql perso et pro mutualisé. Au moins si il y a un soucis avec la BDD ou de charge ils le voient et s'en occupen s'en qu'on ai besoin de leur courir après pendant des jours !

Pour l'instant, depuis mes 2-3 mois d'utilisation de l'offre performance 1, grosse déception. Je ne sais pas si ils ont bcp de soucis avec leurs migrations php 5.3 a 5.4 par défaut et le passage mysql 5.1 a 5.5 depuis 2-3 mois mais pour ma part, je ne suis pas satisfait du service. je ne parle même pas du support qui répond maintenant au bout de plusieurs jours ! difficilement acceptable

[Gaston_Phone]

Quelle méthode de sauvegarde ?

[madmax69]

moi ca fait 30 heures...complètement HS et 3 jours ou il y a des problèmes "apparemment"ovh travaille sur le problème de sqlprive c'est qu'il me disent quand j'appel a chaque fois, pourtant pas d'accident ouvert http://travaux.ovh.net/
donc tu n'ai pas le seul si ça peut te rassurer d'une certaine façon.

[saxgard]

Plus de 2 heures maintenant !

Et franchement, j'aimerais éviter d'avoir à contacter le support qui m'est toujours plusieurs jours à répondre (ce qui est d'ailleurs inacceptable!)

[saxgard]

Bonjour

Il semblerait que l'action de sauvegarde soit bloquée j'ai le message suivant depuis plus d'une heure :

Date : 05/09/2015 à 15:22:07
Etat : Préparation
Statut : En attente

Une tâche de sauvegarde est actuellement planifiée.
Veuillez patienter quelques minutes, celle-ci sera disponible sur votre espace FTP dans le dossier de sauvegarde : /dump.

Il y a une différence entre quelques minutes et plus d'une heure.

Qu'est-ce qu'il faut faire dans ce cas là sans risque de faire tout planter ? !!
J'ose pas redémarrer le serveur SQL, et ne sait pas si une attente aussi longue est normale pour une sauvegarde, d'autant plus pour une BDD de 3Mo!

serveur : server16.sqlprive