Avis sur sql privé

[polweb]

Bonjour,

est ce que certains d'entre vous ont un sql privé chez ovh ? Est ce que vous avez des problèmes avec ?

Je suis sur le point de compléter ma collection chez eux. En plus d'un dedie et d'un 90plan je voudrai rajouter un sql privé. Le problême c'est que j'ai l'impression qu'il y a quelques incidents parfois avec ce service. Le service technique d'ovh m'avait dans un mail indiqué que c'était le cas au début mais que cela marchait bien maintenant.

Quand je vois cela : http://forum.ovh.com/showthread.php?t=69985 j'ai un doute.

Si il y a le moindre problème technique je préfère investir plus d'argent, ce sont des sites qui ne peuvent supporter de discontinuité de fonctionnement.

Donc si le sql privé est fiable cela m'intéresse, sinon je préfère prendre un second dédié et jouer de l'ip fail over entre les deux.

Merci de vos retours d'expérience et à plus.

 

[jamalofski]

Ce qui est sûr est que je voyais beaucoup de posts des gents qui se plaignaient de SQL privé au début. Maintenant, je n'en vois plus. Est ce que c'est parce que ça fonctionne mieux?!

Tu sais qu'on ne peut utiliser SQL privé qu'à partir d'un mutualisé? Je dis ça au cas où tu comptes appeler ta base à partir de ton dédié.

 

[polweb]

Merci de ta réponse et de ta précision. J'avais déjà vu que l'on ne pouvait utiliser un sql privé qu'à partir d'un mutu. Mais effectivement c'est un point à ne pas oublier pour la suite.

En fait je crois que je vais tout rapatrier sur le dedié et faire une ip fail over vers un vps ou un dédié de secours.

J'ai vu qu'il y avait des vps à 5 € par mois. Pour un serveur de secours c'est pas mal et puis on peut monter en puissance comme l'on veut.

Je suis en plein dans le truc je sens que ça va être compliqué

 

[Julia41]

Pourquoi, si tu as un dédié, tu veux un SQL privé ?
J'ignore ce que tu as sur dédié, mais généralement le matos le moins cher (hors kim) est tout de même plus performant que le SQL privé, surtout avec la RAM dispo sur les nouvelles offres.

 

[polweb]

En fait je suis en train de progressivement basculer tous mes sites sur le dédié qui est un kimsuffi. Le but du sql privé c'était de garder un mutu en secours qui puisse accepter une base de plus de 100 Mo.

Je pense que j'ai trouvé la solution. Je vais changer le 90 plan par un pro 100 Go. Le 90 plan étant payé pour encore un an de toute façons cela ne me coutera rien. En faisant un peu de ménage dans les bases du 90 plan cela devrait passer.

Cet été dés que j'ai un peu de temps je prend un second kimsuffi et je le configure en serveur de backup/test. L'ip failover me permettra de basculer rapidement de l'un à l'autre.


Voili voilou, si cela peux servir à d'autres :mrgreen: Ou bien si vous pensez que je me plante :mrgreen:

 

[Julia41]

Je pense que tu te "plantes" car 2 kimsufi sont nettement moins performant qu'un "vrai" dédié (vrai = ceux un peu plus cher et pas de la gamme kimsufi).
A ta place j'investirais dans un serveur correct directement. Pour le backup certes tu l'auras pas en "temps réel" mais les vrais plantages sont rares si tu fais ton install proprement.
Pour les tests, un VPS peut être pas mal.

 

[jamalofski]

Je ne crois pas qu'avoir une seule machine même très puissante est dépendre du bon fonctionnement du celle-ci est une bonne idée. Deux machines identiques avec un IP FO qu'on peut basculer en quelques secondes d'une machine à une autre serait bien plus prudent.

Bien sur je part du principe que ce qui intéresse polweb n'est pas les performances car j'imagine que ça marche très bien même avec une seule machine, mais bien la fiabilité.

Un seul point qui me dérange dans le mode de fonctionnement avec deux machines est la base de donnée. Avoir deux serveurs c'est bien mais si la base n'est pas mise à jour sur les deux machines (réplication), on ne peut basculer d'une machine à une autre aussi facilement. L’idéal est de mettre la base ailleurs SQL privé par exemple, mais ce dernier n'accepte pas de connexions à partir d'un dédié (dommage)!

 

[Julia41]

Un seul point qui me dérange dans le mode de fonctionnement avec deux machines est la base de donnée. Avoir deux serveurs c'est bien mais si la base n'est pas mise à jour sur les deux machines (réplication), on ne peut basculer d'une machine à une autre aussi facilement. L’idéal est de mettre la base ailleurs SQL privé par exemple, mais ce dernier n'accepte pas de connexions à partir d'un dédié (dommage)!

C'est un peu le genre de soucis que je veux montrer.
Il faut : update sa database sur son serveur de backup en permanence (donc réplication Master/slave et sur un kimsufi: bonne chance)
Il faut : mettre à jour ses fichiers en "permanence" si tout n'est pas stocké en DB.
Il faut : avoir une configuration prête à être mise dessus pour que les FO marchent aussitôt.

A noter que je parlais aussi de la garanti du "temps" d'intervention: sur les kimsufi ça peut être long, sur les dédiés plus gros/cher c'est nettement plus performant.

Concernant les perfs : c'est surtout pour le "voir venir":
Avoir un kimsufi en backup: si c'est une petite attaque switcher sur l'autre ne servira à rien.
A mon niveau entre à partir du dédié est mort (qu'il faut le réinstaller) :
réinstall OVH: 30 minutes
récupération du backup FTP d'OVH : (dépends de la taille du fichier) ~30 minutes
réinstallation des paquets nécessaires : 10 minutes
application du backup 5/20 minutes
Up & running.
Ca fait une bonne heure d'indisponibilité.

Avec du RAID et un peu de vérification des pannes sont toutefois très rare.

 

[jamalofski]

Figure toi, tu m'as convaincu Personnellement j'utilise trois machines identiques (+ une pour le site) pour dispatcher la charge et surtout prendre le relai en cas de plantage mais c'est parce que ne sont des machines qui nécessitent plus de 12h si je veux les reintaller.

Pour un site + base, c'est bcp plus simple. Donc un backup régulier (ftp de sauvegarde pour les serveurs ovh) et un dédie avec raid (pas de kimsufi donc) et le tour est joué.

 

[polweb]

Merci de vos réponses le post devient vraiment intéressant.

Mais je reste sur mon idée de base :mrgreen:

Sur un site de ecommerce hacké par machin pendant une heure cela ne le fait pas. Cela m'est déjà arrivé, j'étais en déplacement, et j'ai du remonter le truc à coup de backup a partir d'un pocket pc et du wifi de l'hôtel. C'est pas pratique cà a été dur. Depuis j'ai mieux sécurisé le truc mais bon.

En cas d'attaque remonter à distance c'est stressant, il faut avoir sur lui tout les shells d'installs du dédié, les backup et autres codes.

Dans mon cas le chargement du backup c'est plutôt une heure. Remonter la machine 30 minutes si tout va bien, je m'entraine régulièrement sur virtual box :mrgreen: Bonjour le stress quand même (surtout si c'est au moment de l'apéro et qu'il y a pleins de ventes).

L'avantage c'est aussi que le serveur de backup me servira de serveur test (par exemple en ce moment il faut migrer de lenny à Squeeze. En plus pour la sauvegarde ftp + SQL tout en cron avec ma machine éteinte

Pour la réplication je peux en lancer une juste avant de basculer. Si je bascule avec une base qui n'est pas à jour de 6 h c'est pas super gênant, ce sera juste gênant pour les forums (et j'ai déjà vu ça même sur des grands forum ) pour la partie vente j'ai la trace du paiement et les commandes qui sont écrites en deux endroits différents. A moi de synchroniser le reste plus tard.

Il faut voir qu'actuellement cela marche bien sur du 90plan, donc le kimsuffi c'est plus rapide. Quand ce ne sera plus suffisant je migrerai sur du plus puissant. entre temps j'aurai acquis de l'expérience sur des dédié pour pas cher :wink:

J'hésitai à prendre un vps comme serveur de secours/test mais avoir les deux mêmes c'est quand même plus cool. Les commandes dans la console sont les mêmes certe, mais pour tout ce qui est ip failover et autre c'est mieux.



A plus.

 

[Julia41]

Sur un site de ecommerce hacké par machin pendant une heure cela ne le fait pas. Cela m'est déjà arrivé, j'étais en déplacement, et j'ai du remonter le truc à coup de backup a partir d'un pocket pc et du wifi de l'hôtel. C'est pas pratique cà a été dur. Depuis j'ai mieux sécurisé le truc mais bon.

Ouais mais dans ce cas là, tu te fais aussi hacké le second, de la même manière (mais oui, tu gagnes du temps).

En cas d'attaque remonter à distance c'est stressant, il faut avoir sur lui tout les shells d'installs du dédié, les backup et autres codes.

Je confirme, j'étais parti ce weekend en amoureux... Bah je suis "célibataire" depuis lundi

Dans mon cas le chargement du backup c'est plutôt une heure. Remonter la machine 30 minutes si tout va bien, je m'entraine régulièrement sur virtual box :mrgreen: Bonjour le stress quand même (surtout si c'est au moment de l'apéro et qu'il y a pleins de ventes).

Je confirme ça m'a déjà amené à faire un :
rm blabla.php *
(la touche étoile étant à côté du "valider" )

L'avantage c'est aussi que le serveur de backup me servira de serveur test (par exemple en ce moment il faut migrer de lenny à Squeeze. En plus pour la sauvegarde ftp + SQL tout en cron avec ma machine éteinte

Pour la réplication je peux en lancer une juste avant de basculer. Si je bascule avec une base qui n'est pas à jour de 6 h c'est pas super gênant, ce sera juste gênant pour les forums (et j'ai déjà vu ça même sur des grands forum ) pour la partie vente j'ai la trace du paiement et les commandes qui sont écrites en deux endroits différents. A moi de synchroniser le reste plus tard.

Le problème c'est que si ta machine est réellement inaccessible, là tu pourras pas faire ta "réplication de dernière minute", pareil si une partition (home) saute.

Il faut voir qu'actuellement cela marche bien sur du 90plan, donc le kimsuffi c'est plus rapide. Quand ce ne sera plus suffisant je migrerai sur du plus puissant. entre temps j'aurai acquis de l'expérience sur des dédié pour pas cher :wink: [/quote]
Bonne démarche

J'hésitai à prendre un vps comme serveur de secours/test mais avoir les deux mêmes c'est quand même plus cool. Les commandes dans la console sont les mêmes certe, mais pour tout ce qui est ip failover et autre c'est mieux.

A savoir que des fois il y a des couilles de routage sur les IPs failover Donc le jour de ta migration, tu gagnes du temps, mais tu en "perds" quand ça plante (bon j'exagère un peu ça reste "rare" (mais plus fréquent qu'avec les "vrais" IPs)).

 

[polweb]

Ok ok,

je commence a comprendre ce que tu veux dire par : "bonne chance pour répliquer les bdd sur le kimsuffi".

Une requête sql de 1MO provoque un time exed limit sur le phpmyadmin.

Je suis passé par mysqlimport pour transférer les bases de donnée.

Au fait je ne comprend pas, pourquoi c'est aussi rapide avec mysqlimport ?

Je pense que maintenant je vais faire qu'avec cela, en plus pas besoin de découper les fichier sql en petits morceaux :mrgreen:

A plus.

 

[Julia41]

Ok ok,

je commence a comprendre ce que tu veux dire par : "bonne chance pour répliquer les bdd sur le kimsuffi".

Une requête sql de 1MO provoque un time exed limit sur le phpmyadmin.

Je suis passé par mysqlimport pour transférer les bases de donnée.

Au fait je ne comprend pas, pourquoi c'est aussi rapide avec mysqlimport ?

Je pense que maintenant je vais faire qu'avec cela, en plus pas besoin de découper les fichier sql en petits morceaux :mrgreen:

A plus.

Je ne "connais" pas mysqlimport (c'est en bash ou par phpmyadmin ?)
A mon niveau j'utilise mysqldump et c'est rapide.

C'est aussi long par phpmyadmin car ça vérifie tout ce que tu fais et que tu utilises PHP aussi (alors que tu veux faire du mysql !)

L'histoire de la réplication sur les kimsufi était pour de la réplication Slave/Master: car ça écrit des logs binaires. Ces logs (dès que tu as un site qui fait pas mal de requêtes SQL) sont très consommateurs de disques durs (sur un des masters que j'ai c'est 100Mo d'espace disque toutes les 20 secondes environ) et donc de vitesse de disques, du coup sur des kims, cette réplication est très lourde pour le disque sachant que mysql ne peut pas forcément tourner complètement en RAM (peu de ram sur les kim) et qu'Apache utilise aussi les disques etc...

 

[jamalofski]

Pourquoi vous êtes obligés d'utiliser ces différents outils pour répliquer une base?! une tache planifiée qui établie une simple connexion en sftp pour copier tous les fichiers de la base du serveur 1 vers serveur 2 et c'est tout. En tout cas c'est ce que j'utilise depuis des années et ça marche très bien!

 

[Julia41]

Pourquoi vous êtes obligés d'utiliser ces différents outils pour répliquer une base?! une tache planifiée qui établie une simple connexion en sftp pour copier tous les fichiers de la base du serveur 1 vers serveur 2 et c'est tout. En tout cas c'est ce que j'utilise depuis des années et ça marche très bien!

Tu as de la chance