SQLprivé : point sur la nouvelle infrastructure [Archives]

Bastijn

07/07/2016, 15h48

Envoyé par Lassa

Bonjour Alexis
J'ai essayé de vous joindre individuellement en vain, donc j'utilise cette manière en espérant d'avoir votre réponse.
j'ai eu un problème dont vous avez dépuis 2012 voici le lien
https://forum.ovh.com/showthread.php...site-wordpress
J'ai un domaine, un VPS, et service mail chez OVH, j'ai pointé mon domaine sur mon VPS afin d'héberger mon site, mais impossible de mettre à jour mon thème (theme+Cherry) "Erreur 500" j'ai dé commenté les trois que vous avez sugerez jadis
// Load active plugins.
//foreach ( wp_get_active_and_valid_plugins() as $plugin )
// include_once( $plugin );
//unset( $plugin );

mon site affiche mais trop catastrophique, mise à jour incomplète toutes les extensions qu'on les activent ou pas ne servent plus à rien. j'ai appelé j'ai le support ils contredisent vos propos (je crois que la plus part ne savent pas) le robot qui tue les processus gourmand.
Je ne sais plus quoi faire, j'étais trop avancé pour reprendre à zero. c''est la 2è fois que ça m'arrive
Je remercie d'avance pour vos conseils !!!!

Bonjour,

Une erreur 500 peut avoir une multitude de causes. le lien que vous donnez au dessus parlait d'un client qui "abusait" avec des scripts trop consommateurs. mais pour votre cas, ce n'est pas frocément cela. C'est peut-être un fichier .htaccess mal configuré, une erreur dans le code d'un script... OVH n'assure pas le support de wordpress, nous vous conseillons d'appeler un professionnel, le Web reste un métier avant tout
Si besoin vous trouverez une multitude de partenaires ici : https://partners.ovh.com/rechercher-une-expertise?filters={%22keywords%22:%22wordpress%22, %22customerZone%22:%22ALL%22,%22universe%22:%22uni verse_default%22}

Bonne journée

cavapulser

07/07/2016, 08h19

Envoyé par JLB

Bonjour,

@Kevius et Cavapulser
Je suis sur Docker et comme Kevius, les tailles de mes bases sont à 0Mo.
Avez-vous réussi à vous connecter via SFTP pour accéder aux logs du serveur ?

1) Taille de la base toujours OK.
2) Oui (via Filezilla), mais il m'a fallu réinitialiser le MdP. Rien dans le répertoire /dump, et seulement 2 fichiers log slow-query.log et stdout.log.

- - - Mise à jour - - -

Envoyé par Julia

Toujours pas de métriques !

Pour moi non plus.

Par ailleurs, je ne sais pas si ça a déjà été signalé, mais la section SQLPrivé fonctionne mal avec Firefox, notamment la liste des sauvegardes, invisible, alors qu'elle apparait bien avec d'autres navigateurs

Julia

06/07/2016, 11h32

Toujours pas de métriques !

JLB

04/07/2016, 14h37

Bonjour,

@Kevius et Cavapulser
Je suis sur Docker et comme Kevius, les tailles de mes bases sont à 0Mo.
Avez-vous réussi à vous connecter via SFTP pour accéder aux logs du serveur ?

cavapulser

01/07/2016, 22h00

@Kevius
Je suis sur Docker, et la taille de ma base est bien indiquée.

kevius

01/07/2016, 13h27

Bonjour,

Dans le manager du SQL-Privé onglet base de données, la taille de mes bases est de 0Mo alors que ce n'est pas vraiment le cas.

Est-ce que c'est comme ça pour tout le monde ?

Pareil pour l'espace total utilisé est : 0Mo dans l'onglet générale de mon SQL-Privé

Peut-être que ces fonctions ne sont pas encore implémentées ?

En tout cas la bascule legacy/Docker a été transparente pour moi, c'est cool :-)

Cordialement, Fred

JLB

01/07/2016, 11h01

Bonjour,

Suite au changement de plateforme technique SQLprivé Legacy vers SQLprivé Docker, ce vendredi matin, je ne parviens plus à me connecter via SFTP pour accéder aux logs du serveur.

J’ai bien changé les paramètres d’accès, conformément à la doc (https://www.ovh.com/fr/g2023.tout_sur_le_sql_prive) avec les informations Nom d’hôte, Nom d’utilisateur et Port, récupérées dans l’onglet Générales de l’espace client.

J’ai également utilisé le mot de passe que j’utilisais pour le mode legacy car je suppose qu’il n’a pas changé.

A chaque tentative de connexion, j’obtiens les messages

Code:

Connecté à sqlprive-xxxxxxx-xxx.privatesql.ovh.net, attente de la réponse...
~ Impossible de se logger sur sqlprive-xxxxxxx-xxx.privatesql.ovh.net

Pour info, j’utilise le logiciel LeechFTP.
Qu’aurais-je loupé ?

Cordialement.

Lassa

20/06/2016, 11h22

Bonjour Alexis
J'ai essayé de vous joindre individuellement en vain, donc j'utilise cette manière en espérant d'avoir votre réponse.
j'ai eu un problème dont vous avez dépuis 2012 voici le lien
https://forum.ovh.com/showthread.php...site-wordpress
J'ai un domaine, un VPS, et service mail chez OVH, j'ai pointé mon domaine sur mon VPS afin d'héberger mon site, mais impossible de mettre à jour mon thème (theme+Cherry) "Erreur 500" j'ai dé commenté les trois que vous avez sugerez jadis
// Load active plugins.
//foreach ( wp_get_active_and_valid_plugins() as $plugin )
// include_once( $plugin );
//unset( $plugin );

mon site affiche mais trop catastrophique, mise à jour incomplète toutes les extensions qu'on les activent ou pas ne servent plus à rien. j'ai appelé j'ai le support ils contredisent vos propos (je crois que la plus part ne savent pas) le robot qui tue les processus gourmand.
Je ne sais plus quoi faire, j'étais trop avancé pour reprendre à zero. c''est la 2è fois que ça m'arrive
Je remercie d'avance pour vos conseils !!!!

Julia

19/06/2016, 11h24

Bonjour,

Plus de privilèges ALTER sur les bases sqlPrivé depuis vendredi ou samedi !

Il y a une raison ?

Merci!
Julia

Jon17

18/06/2016, 07h36

Bonjour,
J'attends en vain depuis 12 heures que le serveur quittance la modification de droits d'administrateur d'un utilisateur de la base SQL privée attachée à mon abo Perf (ekarto[point]info). J'ai tenté de créer aussi un nouvel utilisateur avec des droits d'admin. Impossible. Dans les deux cas, l'interface montre 'mise à jour des droits en cours' sans plus.
Comme par ailleurs il m'est impossible de créer un ticket d'incident par suite d'un bug de l'interface des tickets (le champ de la form 'sevice' ne peut être rempli et cela génère un msg d'erreur), je me tourne vers la TEAM: pouvez-vous m'aider ? Merci d'avance.

EDIT : La mise à jour a eu lieu en fin de compte une quinzaine d'heures plus tard. Si vous êtes intervenus, merci.

Alex.P

09/06/2016, 09h34

Pour les lenteurs, peux tu me donner le nom de ton instance ?

Alex.P

Bastijn

09/06/2016, 09h28

Envoyé par Orni

Bonjour à tous,

Un de mes clients sur SQLPrivé rencontre pas mal de ralentissements depuis sa migration début mai sur la nouvelle structure Docker. J'ai vu qu'il y avait des travaux en cours (http://travaux.ovh.net/?do=details&id=18477), mais je ne sais pas si ça s'applique aux Docker ou aux Legacy.
La partie métrique du SQLPrivé fait quelques bonds de temps en temps à 200ms et parfois plus (3,5s).
D'autres personnes ont-ils ce genre de ralentissements depuis quelques temps ? Est-ce que les travaux d'aujourd'hui vont résoudre ce problème ?

D'un autre côté, nous avons remarqué que les sauvegardes n'avaient pas marché pendant plus d'une semaine fin mai, et qu'elle étaient revenues à un rythme moins soutenu que nous le souhaitions. Lorsque nous voulons modifier la planification de ces sauvegardes, nous avons un joli message d'erreur :
"Une erreur est survenue lors de la création d'une tâche. (Feature blocked)"
Pas sympa

Dernière chose, pour les métriques, peut-on avoir sur plus d'un jour ?

Lenteurs potentielles : on regarde.

Sauvegardes : remonté aux équipes interne, merci pour ce retour, on va modifier.

Métriques sur + d'un jour : oui tout à fait ! https://www.ovh.com/fr/g2057.recuper...ve_sur_grafana
il faut s'amuser un peu, installer grafana sur un VPS ou un /cloud...

On a aussi pour projet d'augmenter la durée dans l'espace client mais pour être transparent ce n'est pas dans les priorités du moi de juin.

Bastijn

09/06/2016, 09h25

Envoyé par padpad

Bonjour et merci d'avoir pris la peine de répondre

Pour la planification des sauvegardes, il conviendrait donc de modifier la doc si la fonction https://www.ovh.com/fr/images/guides/2023/img_3535.jpg ne sert à rien et si l'onglet https://www.ovh.com/fr/images/guides/2023/img_3539.jpg n'existe pas.

Effectivement, souci de synchro entre les équipes techinques et nos rédacteurs. c'est remonté, guide en cours de modification, merci.

padpad

08/06/2016, 18h23

cf plus haut
le dysfonctionnement de fin Mai, je crois qu'on est nombreux.
la fonction de paramétrage de ses sauvegardes est inopérante, les sauvegardes sont supposées quotidiennes et automatiques
pour le reste, pas mieux

Orni

08/06/2016, 12h32

Bonjour à tous,

Un de mes clients sur SQLPrivé rencontre pas mal de ralentissements depuis sa migration début mai sur la nouvelle structure Docker. J'ai vu qu'il y avait des travaux en cours (http://travaux.ovh.net/?do=details&id=18477), mais je ne sais pas si ça s'applique aux Docker ou aux Legacy.
La partie métrique du SQLPrivé fait quelques bonds de temps en temps à 200ms et parfois plus (3,5s).
D'autres personnes ont-ils ce genre de ralentissements depuis quelques temps ? Est-ce que les travaux d'aujourd'hui vont résoudre ce problème ?

D'un autre côté, nous avons remarqué que les sauvegardes n'avaient pas marché pendant plus d'une semaine fin mai, et qu'elle étaient revenues à un rythme moins soutenu que nous le souhaitions. Lorsque nous voulons modifier la planification de ces sauvegardes, nous avons un joli message d'erreur :
"Une erreur est survenue lors de la création d'une tâche. (Feature blocked)"
Pas sympa

Dernière chose, pour les métriques, peut-on avoir sur plus d'un jour ?

A vous lire.

Orni

padpad

07/06/2016, 17h47

Merci pour les précisions, explications et corrections.

chmod777

07/06/2016, 13h49

Merci.

Alex.P

07/06/2016, 13h28

Envoyé par chmod777

Sinon MySQL 5.7 est censé être proposé mais je ne le vois pas dans le menu déroulant... Il faut obligatoirement être en 5.6 d'abord ?

Oui

/!\ attention il n'est pas possible de revenir en arriere.

Alex.P

Alex.P

07/06/2016, 13h09

Certains dumps ont disparus car la durée de rétention avait baissé. ( le pourquoi du comment ici : http://travaux.ovh.net/?do=details&id=18218 )
Sinon de mon coté je vois bien l'ensemble de tes dumps ( hors ceux dont la rétention était plus basse )

nb : Pour douteuxglaieul, j'ai detecté un soucis, je corrige cela dans la journée.

Concernant l'envoie de tes dumps, cela est automatisable via l'api.ovh.com. Le sFTP est uniquement la pour la lecture de vos logs ( en cours de changement, nous allons vous déployez quelques choses de plus sexy dans les jours à venir )

Alex.P

chmod777

07/06/2016, 13h02

Sinon MySQL 5.7 est censé être proposé mais je ne le vois pas dans le menu déroulant... Il faut obligatoirement être en 5.6 d'abord ?

padpad

07/06/2016, 12h27

Envoyé par rubenxela

J mais toutes les BDD sont à 0Mo donc vides !

Attention à ce raccourci trompeur.
La logique OVH étant à la logique ce que la musique militaire est la musique, j'ai plusieurs bases dont la taille est de 0 mais qui ne sont PAS vides.
VA jeter un oeil dans phpmyadmin pour voir

padpad

07/06/2016, 11h37

Bonjour et merci d'avoir pris la peine de répondre

Pour la planification des sauvegardes, il conviendrait donc de modifier la doc si la fonction https://www.ovh.com/fr/images/guides/2023/img_3535.jpg ne sert à rien et si l'onglet https://www.ovh.com/fr/images/guides/2023/img_3539.jpg n'existe pas.

Pour l'impossibilité de récupérer et uploader des sauvegardes par FTP, c'est super quand on avait développé des automates pour le faire et qu'on doit embaucher des petites mains pour cliquer dessus à la place. C'est la façon d'OVH de lutter contre le chômage. ET du coup je ne pige pas à quoi sert le SFTP résiduel.

Pour les sauvegardes, par exemple la base db0516006-pwk de ap24505-OVH n'a pas été sauvegardée depuis le 23 mai. ( base qui bouge tous les jours) . La base suissemagblog a été sauvegardée le 7 mai, puis le 9 mai, puis plus rien jusqu'au 31 Mai. La base amacob n'a pas été sauvegardée du 23 au 31 mai. La base douteuxglaieul n'a pas été sauvegardée le 3 juin. etc etc etc ..

rubenxela

07/06/2016, 11h24

J'ai également reçu ce mail le 11 mai et depuis !!!!
Ce matin je constate que le SQLprivé visé n'a plus de données !! les BDD et utilisateurs existent toujours, visiblement des sauvegardes aussi mais toutes les BDD sont à 0Mo donc vides ! Ceci impacte un certain nombre de sites et là on est plus sur 5mn de délais ! Je ne sais absolument pas de quoi il s'agit puisque j'administrais encore ces sites et donc cette base il y a quelques jours. La facture est bien payée, pas de soucis techniques de mon côté, alors quesako ???

Alex.P

07/06/2016, 11h15

- que l'accès est passé en SFTP, a changé de serveur, de user etc ... ben voyons

-> La migration est un changement de plateforme pour ton serveur MySQL, donc oui il y a des changements de techno, users, tout cela afin de simplifier diverses opérations sur ton instance : mise à jour de la ram, changement de version, garantie de ressources etc ...

- qu'il n'y a plus de possibilité ( apparemment) d'uploader par FTP un gros fichier de dump pour le restaurer

-> Tu peux uploader tes dumps directement depuis ton interface client en selectionnant la "roulette" enface de la base. Ton dump est automatiquement importé dans la base voulu.

- que la doc fait référence à un onglet "sauvegardes planifiées" qui n'existe pas .. ou en tout cas pas chez moi

-> Les sauvegardes planifiées sont maintenant effectués automatiquement de notre coté. A chaque base que tu as dans ton mysql, nous effectuons un dump automatiquement chaque jour. Tu peux obtenir le nombre de dumps dans l'onglet database en cliquant sur le chiffre.

- que les sauvegardes ""automatiques OVH" se font au petit bonheur la chance et pas pendant plusieurs jours
- que la fonction "planfifier une sauvegarde" ne semble lui faire ni chaud ni froid

-> Peux tu préciser ? tu as des jours ou le dump n'est pas disponible ?

Alex.P

padpad

07/06/2016, 00h05

Bonsoir
Ai reçu le 11 mai un mail quelque peu abscons qui 'informait que mon sql privé allait être migré, ce qui n'aurait comme conséquence (sic) que
- 5 minutes de coupure
- upgrade de RAM
- management de la base par OVH
- suppression de l'accès root

En essayant de me connecter ce soir je découvre
- qu e l'accès est passé en SFTP, a changé de serveur, de user etc ... ben voyons
- qu'il n'y a plus de possibilité ( apparemment) d'uploader par FTP un gros fichier de dump pour le restaurer
- que la doc fait référence à un onglet "sauvegardes planifiées" qui n'existe pas .. ou en tout cas pas chez moi
- que les sauvegardes ""automatiques OVH" se font au petit bonheur la chance et pas pendant plusieurs jours
- que la fonction "planfifier une sauvegarde" ne semble lui faire ni chaud ni froid

J'ai parcouru l'ensemble de ce fil (no comment sur la façon dont il y a urgence à péter ce qui existe quand le remplaçant n'est pas pret).

Il me reste quelques questions si une bonne âme passe par là.

1) sauvegardes.
Pourquoi les sauvegardes auto OVH sont au vécu du senti. Un jour oui, un jour non ?
Que deviennent celles qu'on planifie à la main ?
Pourquoi on ne peut pas consulter les sauvegardes planifiées comme le laisse penser la doc ?

2) imports et dumps
On a encore accès en STFP à un répertoire /DUMP mais il semble invisible tant pour l'import que pour le dump
Ca veut dire qu'il faut faire les import "à la main en HTTP" et les dump itou .?

Merci

Bastijn

30/05/2016, 08h54

Envoyé par anton57

Merci beaucoup, je t'envoie mes coordonnées en MP.
Cordialement

tu nous diras si ca convient bien à tes besoins ! on a informé le support de la diff event_scheduler // cron

Alex.P

27/05/2016, 16h51

Je viens de te l'activer sur ton instance.

Pas besoin de redémarrer le mysql, tes clients ne sont donc pas impactés.

Alex.P

Bastijn

27/05/2016, 12h04

il n'y a pas de MP sur ce forum, mais tu peux les mettre ici . sans les ip et mwd ce ne sont pas des infos sensibles

anton57

26/05/2016, 17h28

Envoyé par Bastijn

Pour Event_scheduler on peut le rajouter dans votre Espace client, dans les options. Un simple "On-Off". Cela vous conviendrait ?
Si c'est pressé, donne moi ton NIC + nom du SQLprivé et on le mettra sur juste toi, asap

Merci beaucoup, je t'envoie mes coordonnées en MP.
Cordialement

chantoine

25/05/2016, 14h47

Merci ! :-)

Bastijn

25/05/2016, 14h37

C.'est fait.

chantoine

25/05/2016, 14h27

Merci pour cette réponse.
Je veux bien pour cet après midi s'il y a encore de la place.

Bastijn

25/05/2016, 12h31

Envoyé par chantoine

Bonjour,
J'ai reçu un courriel le 11/5 pour m'avertir de la bascule de mon sqlprive-ac4904-001 en docker le 19/5 entre 1h30 et 7h.
Aujourd'hui, je suis toujours en legacy.
Je ne vois dans http://travaux.ovh.net/ aucune info sur un éventuel délai.
J'ai ouvert un ticket le 19/5 sur le sujet, sans aucune réponse à ce jour.
Quelqu'un peut-il me dire ce qu'il en est ?
Merci.
Christophe

Hello, mea culpa, tâche travaux modifiée http://travaux.ovh.net/?do=details&id=17483

Pour ton SQL privé, si tu veux on peut te le migrer cet aprem (heures ouvrées) ou alors le laisser dans la file actuelle, prévu pour du HNO jeudi soir si tout va bien.
tiens nous au courant, merci

Bastijn

25/05/2016, 12h30

Envoyé par anton57

Depuis le passage sur la nouvelle infrastructure, je n'ai plus l'accès aux tâches planifiées MySQL (event scheduler) dont l'autorisation était réglée par un paramètre dans my.conf

C'est extrêmement pénalisant pour l'application de mes clients.

Je veux bien comprendre votre souci de simplifier l'utilisation de MySQL privé pour le rendre plus attractif pour des non initiés. Mais ne supprimez pas les possibilités et laissez un mode expert pour ceux qui ont envie de jouer avec ftp et le fichier de configuration.

L'avantage de ce MySQL Privé, c'était que c'était le nôtre : processeur réservé, mémoire réservée et on fait ce qu'on veut, y compris le planter si ça nous fait plaisir. Maintenant, quel est l'avantage par rapport à un SQL mutualisé ?

Surtout qu'en plus, vous avez quand même modifié unilatéralement le contrat qui nous lie en supprimant des fonctions...

Personnellement, d'une manière ou d'une autre, je souhaiterais vivement que la possibilité d'autoriser ou pas les event scheduler soit rétablie (SET GLOBAL event_scheduler = "on")

Merci

Bonjour,
C'est la nouvelle philosophie de ces instances managées. Vous n'êtes plus root mais de notre coté nous nous occupons de tout (monitoring etc).
C'est vraiment l'objectif recherché.
De plus ces nouvelles instances apportent leur lots de nouveautés, comme l'augmentation de la RAM, connexion STFP, sauvegardes automatiques journalières, metriques, etc.

Pour Event_scheduler on peut le rajouter dans votre Espace client, dans les options. Un simple "On-Off". Cela vous conviendrait ?
Si c'est pressé, donne moi ton NIC + nom du SQLprivé et on le mettra sur juste toi, asap

chantoine

25/05/2016, 08h07

Bonjour,
J'ai reçu un courriel le 11/5 pour m'avertir de la bascule de mon sqlprive-ac4904-001 en docker le 19/5 entre 1h30 et 7h.
Aujourd'hui, je suis toujours en legacy.
Je ne vois dans http://travaux.ovh.net/ aucune info sur un éventuel délai.
J'ai ouvert un ticket le 19/5 sur le sujet, sans aucune réponse à ce jour.
Quelqu'un peut-il me dire ce qu'il en est ?
Merci.
Christophe

anton57

24/05/2016, 18h37

Envoyé par Bastijn

Bonjour à tous,
S'il manque des paramètres, n'hésitez pas à nous expliquer pourquoi en dessous, merci
.

Depuis le passage sur la nouvelle infrastructure, je n'ai plus l'accès aux tâches planifiées MySQL (event scheduler) dont l'autorisation était réglée par un paramètre dans my.conf

C'est extrêmement pénalisant pour l'application de mes clients.

Je veux bien comprendre votre souci de simplifier l'utilisation de MySQL privé pour le rendre plus attractif pour des non initiés. Mais ne supprimez pas les possibilités et laissez un mode expert pour ceux qui ont envie de jouer avec ftp et le fichier de configuration.

L'avantage de ce MySQL Privé, c'était que c'était le nôtre : processeur réservé, mémoire réservée et on fait ce qu'on veut, y compris le planter si ça nous fait plaisir. Maintenant, quel est l'avantage par rapport à un SQL mutualisé ?

Surtout qu'en plus, vous avez quand même modifié unilatéralement le contrat qui nous lie en supprimant des fonctions...

Personnellement, d'une manière ou d'une autre, je souhaiterais vivement que la possibilité d'autoriser ou pas les event scheduler soit rétablie (SET GLOBAL event_scheduler = "on")

Merci

chmod777

17/05/2016, 12h31

Bonjour,

On ne peut pas faire plus de 10 sauvegardes planifiées (pour des bases qui sont toutes différentes). Je pensais au départ que ce n'était qu'un problème d'affichage mais après quelques tests (qui n'en étaient pas vraiment en fait au départ) et quelques jours d'attente, les sauvegardes ne sont tout simplement plus faites alors que je n'ai absolument pas demandé leur suppression. Ma conclusion : ajouter une sauvegarde planifiée pour une nouvelle base quand on a 10 entraîne la suppression d'une sauvegarde existante.

Désolé d'insister avec ce problème mais il est vraiment gênant.

Edit : Après suppression de toutes les sauvegardes planifiées (en effet, plus aucune n'était effectuée, il m'a fallu du temps pour m'en rendre compte car je ne faisais un backup qu'une seule fois par semaine au départ), j'ai pu toutes les recréer correctement et tout fonctionne à nouveau. Peut-être que c'était dû à ceci : "Pour les prochaines migrations, nous faisons en sorte que les backups ne tournent pas en même temps." et que le processus n'a pas été réactivé après, je ne sais pas. En tout cas, tout fonctionne de mon côté désormais.

vcasse

18/04/2016, 10h19

Envoyé par JLB

En ce qui concerne le nouvel import en base de données, j’avoue que j’ai bien fait de rester cramponné à l’épave.

L’ancien import (Manager v3) nécessitait de transférer via FTP le fichier à importer dans le répertoire /import du sql privé, de supprimer toutes les tables de chaque base par PHPMyAdmin avant de soumettre l’import qui pouvait demander plusieurs minutes avant de démarrer. Sans compter qu’il était impossible alors d’importer une autre base tant que l’import de la précédente n’était pas terminée.

Le nouvel import fait tout en 1 : transfert de fichier dump, possibilité de vider la base de données avant l’import, importation immédiate et très rapide. Rien à voir avec l’ancienne procédure.

Donc Félicitations.

Voici quand même quelques détails à améliorer :

1) Pour chaque étape de l’import, rappeler le nom de la base de données qui a été sélectionnée à l’aide de la roue crantée.

2) En cas d’import d’un nouveau fichier, initialisez le champ « Nom du fichier » avec le nom du fichier sélectionné à l’aide du bouton « Parcourir », dès que celui-ci est sélectionné.

3) A l’étape 3, rappelez le nom du fichier dump contenant les données à importer.

4) Permettre la suppression des « fichiers présents dans notre compte », dès que l'on n'en a plus besoin.

Cordialement.

Jean-Louis

Bonjour Jean-Louis,

Merci pour ton feedback, il fait plaisir !
On va voir pour améliorer l'interface d'import de backup. Il y a déjà un travail en cours, on y intégre tes remarques.

Pour le v3, on a pris note et on va tout faire pour que ca ne se reproduise pas.

Cordialement,
Vincent

jul64

17/04/2016, 13h45

Bonjour,
suite à la migration de mon sql privé en 256 mo, j'ai un service dégradé sur ma base
HOST : sqlprive-dc5789-002.privatesql
DATABASE : arseneSQLpriv

Quand j'essaye de me connecter sur la base mysql avec phpmyadmin, j'ai des erreurs serveur :
https://drive.google.com/file/d/0B60...9PX0lQQmM/view

Je suis bloqué, je ne peux rien faire ...
Ticket 2016041519026794
Ouvert depuis le : 15/04/2016 10:00

JLB

15/04/2016, 14h38

Envoyé par Bastijn

Vincent vous en parlera surement + en détail mais si ça peut aider pour les gens pressés : SQLprivé > Base de données > roue crantée > import

« les gens pressés » ?
Tout est relatif. Il vous a quand même fallu plus de 6 mois avant de percuter.
Si vous aviez baptisé le manager v3 le « Costa Concordia », on se serait peut-être méfié.
Espérons seulement que le Manager V6 n’est pas le Titanic, que vous aurez retenu les leçons du naufrage du Manager v3 et que le transfert du Manager V6 vers son successeur s’effectuera de manière un peu plus méthodique, rigoureuse et un tant soit peu professionnelle.

En ce qui concerne le nouvel import en base de données, j’avoue que j’ai bien fait de rester cramponné à l’épave.

L’ancien import (Manager v3) nécessitait de transférer via FTP le fichier à importer dans le répertoire /import du sql privé, de supprimer toutes les tables de chaque base par PHPMyAdmin avant de soumettre l’import qui pouvait demander plusieurs minutes avant de démarrer. Sans compter qu’il était impossible alors d’importer une autre base tant que l’import de la précédente n’était pas terminée.

Le nouvel import fait tout en 1 : transfert de fichier dump, possibilité de vider la base de données avant l’import, importation immédiate et très rapide. Rien à voir avec l’ancienne procédure.

Donc Félicitations.

Voici quand même quelques détails à améliorer :

1) Pour chaque étape de l’import, rappeler le nom de la base de données qui a été sélectionnée à l’aide de la roue crantée.

2) En cas d’import d’un nouveau fichier, initialisez le champ « Nom du fichier » avec le nom du fichier sélectionné à l’aide du bouton « Parcourir », dès que celui-ci est sélectionné.

3) A l’étape 3, rappelez le nom du fichier dump contenant les données à importer.

4) Permettre la suppression des « fichiers présents dans notre compte », dès que l'on n'en a plus besoin.

Cordialement.

Jean-Louis

Bastijn

07/04/2016, 16h48

Hello,

Import de fichiers dans le V6 en production.

Vincent vous en parlera surement + en détail mais si ça peut aider pour les gens pressés : SQLprivé > Base de données > roue crantée > import

bonne journée.

vcasse

07/04/2016, 09h41

Envoyé par JLB

Bon ben çà y est :

Code:

HTTP/1.1 100 Continue HTTP/1.1 201 Created Last-Modified: Wed, 06 Apr 2016 15:52:44 GMT Content-Length: 0 Etag: 571ab05f3c5d32b2ae27ddc0fd6aaf8d Content-Type: text/html; charset=UTF-8 X-Trans-Id: txf68236cdeb8a483cbe9c1-00570530cb Date: Wed, 06 Apr 2016 15:52:45 GMT Connection: close

J’ai ensuite procédé à l’import.
Résultat :

Code:

{ • function: "database/import" • status: "todo" • dumpId: null • databaseName: "xxxxxxxxxxxxxx" • lastUpdate: "2016-04-06T17:56:25+02:00" • id: 16388633 • userName: null • startDate: "2016-04-06T17:56:25+02:00" • doneDate: null }

Lorsque j’exécute l’import, le status est « todo ». Par contre, je n’ai trouvé aucun moyen de savoir quand l’import est en cours ni surtout quand il est terminé.
J’ai pourtant coché la case sendEmail lors de la demande d'import mais je n’ai reçu aucun avertissement par mail.
Je ne me suis aperçu que la base avait été importée que lorsque mon site de test a de nouveau fonctionné. Evidemment, puisque j’avais flingué involontairement la base de test lors de mon premier essai.

Pour les bases en exploitation, comment pourrai-je savoir que l’import s’est correctement terminé sans avoir à flinguer la base opérationnelle juste avant ?

Bonjour JLB,

Si tu n'as pas reçu de mail, c'est qu'il y a un soucis. Je regarde de suite.
Mais dans tous les cas, si tu veux suivre une todo, tu peux depuis l'api : https://api.ovh.com/console/#/hostin...s/%7Bid%7D#GET

Quand elle disparait, c'est qu'elle est terminée

Cordialement,
Vincent

JLB

06/04/2016, 22h05

Bon ben çà y est :

Code:

HTTP/1.1 100 Continue

HTTP/1.1 201 Created
Last-Modified: Wed, 06 Apr 2016 15:52:44 GMT
Content-Length: 0
Etag: 571ab05f3c5d32b2ae27ddc0fd6aaf8d
Content-Type: text/html; charset=UTF-8
X-Trans-Id: txf68236cdeb8a483cbe9c1-00570530cb
Date: Wed, 06 Apr 2016 15:52:45 GMT
Connection: close

J’ai ensuite procédé à l’import.
Résultat :

Code:

{
•	function: "database/import"
•	status: "todo"
•	dumpId: null
•	databaseName: "xxxxxxxxxxxxxx"
•	lastUpdate: "2016-04-06T17:56:25+02:00"
•	id: 16388633
•	userName: null
•	startDate: "2016-04-06T17:56:25+02:00"
•	doneDate: null
}

Lorsque j’exécute l’import, le status est « todo ». Par contre, je n’ai trouvé aucun moyen de savoir quand l’import est en cours ni surtout quand il est terminé.
J’ai pourtant coché la case sendEmail lors de la demande d'import mais je n’ai reçu aucun avertissement par mail.
Je ne me suis aperçu que la base avait été importée que lorsque mon site de test a de nouveau fonctionné. Evidemment, puisque j’avais flingué involontairement la base de test lors de mon premier essai.

Pour les bases en exploitation, comment pourrai-je savoir que l’import s’est correctement terminé sans avoir à flinguer la base opérationnelle juste avant ?

vcasse

06/04/2016, 16h31

Le lien n'est pas concu pour être accédé via un navigateur. C'est normal de recevoir une erreur dans ce cas.

N'hésitez pas à récreer des liens en effectuant des POST sur /me/document. Leur durée de vie est de quelques minutes maximum

JLB

06/04/2016, 15h09

J’obtiens d’ailleurs le même résultat lorsque j’accède directement à la page
https://storage.p19.cloud.ovh.net/v1...lename=dump.gz

Donc l’erreur ne pourrait-elle pas provenir plutôt du lien putUrl proposé par https://api.ovh.com/console/#/me/document#POST ?

JLB

06/04/2016, 15h02

Oui, je m’en suis aperçu après avoir posté le message.
Je l’ai complété de suite mais pas suffisamment rapidement.
Donc non, on ne progresse pas.
J’ai toujours la même anomalie

Code:

HTTP/1.1 401 Unauthorized
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Www-Authenticate: Swift realm="unknown"
X-Trans-Id: tx76a33e288f2b4651aded0-00570510ee
Date: Wed, 06 Apr 2016 13:36:46 GMT
Connection: close

401 Unauthorized: Temp URL invalid

vcasse

06/04/2016, 14h39

Bonjour JLB,

Le remplacement de & ne changera rien dans l'url.

Par contre, la requête curl ne semble pas bonne. le début doit être

curl -i -X PUT --data-binary "@dump.gz"

Je pense que le bad request provient de là.

Cordialement,
Vincent

JLB

06/04/2016, 14h33

Bonjour Vincent,

On progresse.
J’ai tout repris depuis le début.
J’envoie maintenant la commande

Code:

curl -i -X "@dump.gz" "https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/fe34f882-ba33-42a3-895e-360e11897226?temp_url_sig=55b7640b38afe36c4cd52decc8b7458d0c09a0ac&temp_url_expires=1459948996&filename=dump.gz"

Et je récupère à présent l’erreur

Code:

HTTP/1.0 400 Bad request
Cache-Control: no-cache
Connection: close
Content-Type: text/html

400 Bad request
Your browser sent an invalid request.

J’ai bien tenté de replacer & par & dans l’url :

Code:

curl -i -X "@dump.gz" "https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/fe34f882-ba33-42a3-895e-360e11897226?temp_url_sig=55b7640b38afe36c4cd52decc8b7458d0c09a0ac&temp_url_expires=1459948996&filename=dump.gz"

Mais rien n’y fait. Même punition :

Code:

HTTP/1.0 400 Bad request
Cache-Control: no-cache
Connection: close
Content-Type: text/html

400 Bad request
Your browser sent an invalid request.

Evidemment, si j'oublie la moitié de la commande

Code:

curl -i -X PUT --data-binary "@dump.gz" "https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/fe34f882-ba33-42a3-895e-360e11897226?temp_url_sig=55b7640b38afe36c4cd52decc8b7458d0c09a0ac&temp_url_expires=1459948996&filename=dump.gz"

me renvoie toujours l'erreur

Code:

HTTP/1.1 401 Unauthorized
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Www-Authenticate: Swift realm="unknown"
X-Trans-Id: tx76a33e288f2b4651aded0-00570510ee
Date: Wed, 06 Apr 2016 13:36:46 GMT
Connection: close

401 Unauthorized: Temp URL invalid

vcasse

05/04/2016, 17h50

Bonjour JLB,

Le lien créé par l'API a une validité de courte durée. Avez vous tenté d'en créer un nouveau ?

Cordialement,
Vincent

JLB

05/04/2016, 10h08

Bonjour,

Envoyé par vcasse

Si votre besoin est assez urgent, on peut vous aider à utiliser le /me/document.

Y a plus personne ?

JLB

04/04/2016, 08h54

Bonjour Vincent,

Les doubles quotes semblent améliorer l'interprétation de la commande

Code:

curl -i -X PUT --data-binary "@dump.gz" "https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/262fe3a7-ab12-4b3a-ab45-af8d6d4c0e8e?temp_url_sig=86cd8dd2d12168399ee568fcf76cb648ef24c704&temp_url_expires=1459602328&filename=dump.gz"

Mais je récupère encore la sanction HTTP/1.1 401 Unauthorized :

Code:

HTTP/1.1 401 Unauthorized
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Www-Authenticate: Swift realm="unknown"
X-Trans-Id: txd57c6221509b40079bc0f-0057021c76
Date: Mon, 04 Apr 2016 07:49:10 GMT
Connection: close

401 Unauthorized: Temp URL invalid

vcasse

04/04/2016, 08h12

Salut JLB,

Je suis très mauvais en windows. Mais j'ai envie de troller quand je me rend compte qu'il ne comprend pas les simple quote.

Sans les quotes, les "&" continue dans l'url est interprété par windows (comme linux) comme un symbole de la commande. L'url est donc tronquée à partir de ce point.

Avez vous tenté des "doubles quotes" ?

Cordialement,
Vincent

JLB

03/04/2016, 19h11

J'ai également essayé en ajoutant le paramètre -u USER:PASSWORD à la commande curl.
J'ai bien sûr remplacé USER par mon login et PASSWORD par mon mot de passe
Mais rien n'y fait. Même punition.

HTTP/1.1 401 Unauthorized
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Www-Authenticate: Swift realm="unknown"
X-Trans-Id: tx35ffaa2d7b7d47a6a7cbf-0057015b0e
Date: Sun, 03 Apr 2016 18:03:58 GMT
Connection: close

401 Unauthorized: Temp URL invalid
'temp_url_expires' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
'filename' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

JLB

02/04/2016, 14h36

Bonjour Vincent,

Bon ben, j’ai préparé le fichier sql à importer, sous le nom de dump.gz en local, comme dans ton exemple.

Je crée ensuite le nouveau document https://api.ovh.com/console/#/me/document#POST
Je renseigne dump.gz comme nom de fichier et j’exécute.
J’obtiens putUrl: https://storage.p19.cloud.ovh.net/v1...lename=dump.gz

J’exécute ensuite la commande sous Windows

Code:

curl -i -X PUT --data-binary "@dump.gz" 'https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/262fe3a7-ab12-4b3a-ab45-af8d6d4c0e8e?temp_url_sig=86cd8dd2d12168399ee568fcf76cb648ef24c704&temp_url_expires=1459602328&filename=dump.gz'

et j’obtiens en retour,

Code:

curl: (1) Protocol "'https" not supported or disabled in libcurl
'temp_url_expires' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
'filename' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

le protocole ‘https ne semble pas être reconnu à cause de la quote devant https
Si je retire les ‘ autour de l’url et que j’exécute la commande

Code:

curl -i -X PUT --data-binary "@dump.gz" https://storage.p19.cloud.ovh.net/v1/AUTH_17a31f21a517452c8eb59fe3cbefbb5c/be691cd5212eb80bf331a0f1ab190795e241295e86946e536cb2da859e10b8457d8cf64ce25aef46f2f847f2f462f4503727406dc1a552178e491475fdc610b5/262fe3a7-ab12-4b3a-ab45-af8d6d4c0e8e?temp_url_sig=86cd8dd2d12168399ee568fcf76cb648ef24c704&temp_url_expires=1459602328&filename=dump.gz

j’obtiens en retour

Code:

HTTP/1.1 401 Unauthorized
Content-Length: 35
Content-Type: text/html; charset=UTF-8
Www-Authenticate: Swift realm="unknown"
X-Trans-Id: tx1ae44d353de3431f92c31-0056ffc6dd
Date: Sat, 02 Apr 2016 13:19:25 GMT
Connection: close

401 Unauthorized: Temp URL invalid
'temp_url_expires' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.
'filename' n’est pas reconnu en tant que commande interne
ou externe, un programme exécutable ou un fichier de commandes.

Voilà, voilà ...
Après le naufrage, peux-tu m’aider à trouver où je me suis échoué à présent ?
Cordialement.

Jean-Louis

vcasse

01/04/2016, 17h10

Bonjour JLB,

Effectivement, nous avons pris un peu de retard. On a essayé la motivation au coup de fouet mais il semble que c'est contre-productif.

Je vais essayer de t'aiguiller sur l'utilisation de /me/document. Je te conseille tout de même de faire des essais sur une base de test...

1/ Upload du dump sql (en .gz)

1/a/ Préparer l'espace d'upload
Cela se réalise en effectuant un POST sur /me/document avec un nom de fichier (par exemple dump.gz)
https://api.ovh.com/console/#/me/document#POST

Tu récupére un json avec des url. Elles te servirons à effectuer un upload.

{
putUrl: https://storage.p19.cloud.ovh.net/v1...lename=dump.gz
validationDate: null
name: "dump.gz"
expirationDate: null
size: 0
tags: [ ]
creationDate: "2016-04-01T17:56:23+02:00"
getUrl: https://storage.p19.cloud.ovh.net/v1...lename=dump.gz
id: "uuid"
}

Ici, c'est putUrl qui nous interesse.

1/ b/ Uploader le fichier
J'utilise curl en ligne de commande. Tout outil qui forge des requêtes peut fonctionner

curl -i -X PUT --data-binary "@dump.gz" ' https://storage.p19.cloud.ovh.net/v1...lename=dump.gz'

Si tu recois

HTTP/1.1 201 Created

c'est que cela a fonctionné

2/ Demande d'importer ce dump
Cela se fait en effectuant l'appel sur /privateDatabase/id/database/databaseName/import en POST.
https://api.ovh.com/console/#/hostin...7D/import#POST

Les champs sont :
serviceName : l'identifiant du sqlprivé
databaseName : le nom de la base
documentId : l'identifiant du /me/document. Dans mon exemple ici c'est "uuid"
flushDatabase : à cliquer si la base doit etre vider avant le dump
sendEmail : si un email est envoyé quand la base est importée.

J'ai testé en live. Cela fonctionne.
En cas de soucis, n'hésite pas à revenir vers moi.

Cordialement,
Vincent

JLB

01/04/2016, 15h52

Envoyé par vcasse

Bonjour JLB,

Tu as trouvé le bon appel d'API à effectué pour importer un dump. Cet appel est en cours d'intégration dans les espaces clients de OVH et devrait être mis en prod dans les jours qui viennent.

Pour le /me/document, il s'ahit d'un second appel qui permet de gérer les uploads sur OVH https://api.ovh.com/console/#/me/document#POST
Cet appel créé un lien Openstack Swift permettant d'uploader un fichier. §Il retourne un identifiant à indiquer dans le /privateDatabase/{serviceName}/database/{databaseName}/import.

Si votre besoin est assez urgent, on peut vous aider à utiliser le /me/document. Sinon, l'upload arrive sous peu dans l'espace client.

Cordialement,
Vincent

Bonjour,

Ce qui devait arriver vient de se produire. J’ai besoin d’importer 7 bases de données sur un sql privé.
L’upload devait arriver sous peu dans l’espace client selon ce que nous avait annoncé Vincent, le 16 mars 2016 à 14h46.

16 jours ont passé et toujours rien.
Pas de document en ligne non plus à propos de l’utilisation de l’API POST /me/document.
J’ai essayé de me débrouiller tout seul mais mon intuition n’a visiblement pas suffi.
J’ai tout d’abord uploader mes fichiers import dans le répertoire import de mon sql privé comme avant.

J’ai ensuite créé un nouveau document https://api.ovh.com/console/#/me/document#POST sans très bien comprendre comment le lien allait être établi entre mon fichier import et l’identifiant retourné.

Puis j’ai fait la demande d’import de la base de données https://eu.api.ovh.com/console/#/hosting/privateDatabase/{serviceName}/database/{databaseName}/import#POST en renseignant le documentId retourné par la commande précédente.

Et là, j’ai flingué ma base de données.
Heureusement que j’ai essayé sur une base de test.
Mais je suis à présent quand même vraiment dans la merde.
Si un garde-côte passe dans les parages ... HELP

Anak1

28/03/2016, 10h34

Envoyé par JLB

A moins qu'il ne soit plus simple pour vous de rétablir le manager v3 pour exploiter correctement le sql privé en attendant que le manager v6 le permette ?

Totalement OK

Ca aurait été tellement plus simple pour vos clients de juste proposer un 2 Go sur le legacy...

En plus votre infra Docker ça ajoute des restrictions importantes.
Ex: Impossible d'avoir plus de 200 connexions simultanés même sur un 2 Go (confirmé sur ce forum par un membre de la team OVH)
Et en + impossible d'avoir du MySQL 5.6 en 2016

On avait un truc qui fonctionnait.
On nous impose des régressions pour nous forcer à une migration qui va amener d'autres restrictions.

Perso je suis près a payer un Performance 5 et un SQL privé 4Go dans les 100 €/mois si vous proposez quelque chose qui fonctionne comme avant.

JLB

20/03/2016, 14h25

Bonjour Vincent,

PS : ca m'intéresse de savoir ce qui t'a fait perdre du temps lors de la migration v3 -> v6

C’est pas beau de se moquer !

Quand une commande ou une procédure fonctionne correctement avec le manager v3 et que le manager v3 est fermé avant de s’assurer qu’une fonctionnalité équivalente existe bien dans le manager v6, alors forcément cela génère une perte de temps, ne serait-ce que pour :

comprendre après des recherches vaines que la commande n’est plus accessible du jour au lendemain, via le manager v3,
tenter de retrouver une fonctionnalité équivalente dans le manager v6, toujours en vain,
rechercher une solution dans la documentation « SQL Privé - Importer une base de données » (http://docs.ovh.com/pages/releasevie...ageId=12225511) qui présente encore la procédure d’importation qui forcément n’existe plus,
rechercher dans la documentation « Tout sur le SQL Privé » (https://www.ovh.com/fr/g2023.tout_sur_le_sql_prive) qui ne propose qu’une solution via PHPMyAdmin, pour des bases de données limitées à 16 Mo,
se résoudre enfin à poster sur le forum pour savoir comment les autres naufragés sont parvenus à regagner la terre ferme et découvrir à la place, que les garde-côtes vont tester pendant quelques jours, voire un certain temps, avant de venir nous repêcher, des gilets de sauvetage qui ne nous sont pas spécialement destinés.

Je ne comprends toujours pas comment vous avez pu délibérément saborder le manager v3 avant d’avoir pris soin de transférer préalablement tous les passagers vers le manager v6.

J’avais pourtant actionné les feux de détresse https://forum.ovh.com/showthread.php...sql-priv%C3%A9 dès le 26 septembre 2015.
Je pensais aussi avoir été constructif en vous signalant toutes les fonctionnalités qu’il me manquait dans le manager v6 (dont l’import des bases de données), dès le 30 septembre 2015 (https://forum.ovh.com/showthread.php...nagerV6/page25).
De nombreux autres lanceurs d’alerte ont aussi régulièrement tenté d’attirer votre attention sur les carences du manager v6, dont notamment le second post de cette discussion de cbleu, le 20 octobre 2015 (https://forum.ovh.com/showthread.php...infrastructure).

Vous avez durant presque 6 mois, ignoré nos besoins fondamentaux.

Si votre besoin est assez urgent, on peut vous aider à utiliser le /me/document. Sinon, l'upload arrive sous peu dans l'espace client.

Mais puisque « l'upload arrive sous peu dans l'espace client », pourquoi ne pas avoir justement attendu quelques jours de plus avant de torpiller le manager v3 ?

Donc non, je ne suis pas du tout rassuré par vos promesses sans engagement de délai, ni même de résultat et j’accepte volontiers ta proposition de m’aider ainsi que tous ceux qui se retrouvent dans la même galère que moi.

Aussi, pour anticiper le besoin urgent qui ne manquera pas de survenir d’ici un certain temps, te serait-il possible de mettre en ligne une documentation détaillée présentant le mode opératoire en vue d’importer avec les moyens du bord actuellement disponibles, une base de données de 120 Mo et plus ?
A moins qu'il ne soit plus simple pour vous de rétablir le manager v3 pour exploiter correctement le sql privé en attendant que le manager v6 le permette ?

Cordialement.

Jean-Louis

Charles.A

18/03/2016, 16h53

Bonjour cbleu,

Nous y travaillons, nous sommes en train de finaliser le scenario de migration pour limiter le downtime.
J'espère que nous reviendrons rapidement vers vous avec une tache travaux pour annoncer les premieres migrations de test.

Charles

Envoyé par cbleu

Bonjour,

MIGRATION Legacy vers Docker :

On en est ou ?
C'est pour quand ? … le temps passe et toujours rien.
J'ai 1 Docker et 5 Legacy… J'aimerais bien migrer les Legacy, car aujourd'hui on sait plus ce qui se passe dessus, on a aucun tableau de bord pour savoir combien de mémoire est utilisé, pas de métriques, pas de conf et on est limité à 128 Mo (sans compter tout ce que l'on avait avant l'arrivée de Docker).

Sur Legacy finalement on est relativement BRIDÉ par rapport à Docker depuis le passage à la V6.

Une autre question : SQLprivé et IP publiques ça donne quoi ?
Ça intéresse pas mal de vos clients apparemment et on aimerait bien avoir la chance d'y accéder aussi...

Merci

vcasse

17/03/2016, 11h14

Bonjour Jean Louis,

C'est toujours difficile d'annoncer une date. La fonctionnalité est actuellement en test sur l'espace client pour la bases de données inclues dans l'offre mutualisés (donc hors sql privé). Si les testeurs valident, c'est une question de jours.

Pour les sql privés, je n'ai pas la réponse, je vais voir avec l'équipe. Sachant que techniquement, il s'agit de la même chose.

Cordialement,
Vincent

PS : ca m'intéresse de savoir ce qui t'a fait perdre du temps lors de la migration v3 -> v6

JLB

17/03/2016, 10h08

Bonjour Vincent,

Merci pour ton complément d’information.
Le besoin n’est pas urgent pour l’instant, on n’est pas à la seconde.
Je peux si besoin retarder mes mises à jour régulières. Cela ne devrait pas trop se voir si la situation ne s’éternise pas.
Mais l’import est pour moi le seul moyen d’actualiser mes bases de données. Donc si jamais un client me demande du jour au lendemain d’actualiser les données le concernant, je suis très mal.
Merci de ne pas me laisser trop longtemps dans cette situation plutôt inconfortable.

Je sais à présent qu’il existe une solution en cas d’urgence et je te remercie pour l’aide que tu me proposes.
Mais j’ai déjà perdu beaucoup trop de temps suite à l’arrêt prématuré du manager v3.
Donc je préfère me focaliser sur mon travail plutôt que de perdre davantage de temps inutilement.
En croisant les doigts pour que l’import soit opérationnel avant que le besoin ne devienne urgent.
Qu’entends-tu pas « les jours qui viennent » ou « arrive sous peu » ?
Si la tâche est correctement planifiée, alors tu peux m’annoncer une date.
Cordialement.

Jean-Louis

vcasse

16/03/2016, 13h46

Envoyé par JLB

J’ai suivi tes explications et j’ai trouvé l’api qui pourrait m’intéresser :
https://eu.api.ovh.com/console/#/hos...e}/import#POST
Parmi tous les champs à renseigner, il y a documentId auquel est associé le commentaire « Documents ID of the dump from /me/documents ».
Quel est ce répertoire / me/documents ?
Je suppose que je dois y déposer les fichiers à importer. Mais où se situe-t-il et comment y accéder ?

Bonjour JLB,

Tu as trouvé le bon appel d'API à effectué pour importer un dump. Cet appel est en cours d'intégration dans les espaces clients de OVH et devrait être mis en prod dans les jours qui viennent.

Pour le /me/document, il s'ahit d'un second appel qui permet de gérer les uploads sur OVH https://api.ovh.com/console/#/me/document#POST
Cet appel créé un lien Openstack Swift permettant d'uploader un fichier. §Il retourne un identifiant à indiquer dans le /privateDatabase/{serviceName}/database/{databaseName}/import.

Si votre besoin est assez urgent, on peut vous aider à utiliser le /me/document. Sinon, l'upload arrive sous peu dans l'espace client.

Cordialement,
Vincent

cbleu

16/03/2016, 12h27

Bonjour @JLB

Je pense que le répertoire ça fait référence aux dumps des sauvegardes planifiées…
j'ai envoyé des tweets au support. dès que j'en sais plus je te tiens au courant.

Puis si tu regarde plus haut, il y a ce problème d'anciens SQL privé "Legacy" finalement bien plus bridé que les nouveaux "Docker".
OVH nous avait promis la possibilité de migration via le manager V6, mais ça traine en longueur et il n'y a toujours rien.

JLB

16/03/2016, 11h02

Bonjour cbleu,

Merci beaucoup pour tes explications.
C’est vrai qu’en terme d’ergonomie, plus pauvre, il n’y a plus que la ligne de commande MS-DOS.
A quand le retour aux cartes perforées pour ceux qui ont connu ?

J’ai suivi tes explications et j’ai trouvé l’api qui pourrait m’intéresser :
https://eu.api.ovh.com/console/#/hos...e}/import#POST
Parmi tous les champs à renseigner, il y a documentId auquel est associé le commentaire « Documents ID of the dump from /me/documents ».
Quel est ce répertoire / me/documents ?
Je suppose que je dois y déposer les fichiers à importer. Mais où se situe-t-il et comment y accéder ?

cbleu

16/03/2016, 00h35

@Bastijn
Bonjour,
C'est vrai que c'est pas joyeux lorsque l'on a de grosses bases. impossible de les importer via PhpMyAdmin. On fait comment ?

@JLB
Bonjour,
Ça se passe sur le manager V6 maintenant, de façon beaucoup plus restrictive pour les anciens SQL Privés "Legacy". Il n'y a plus de possibilité d'import pour le moment sur le manager, même sur les nouveaux SQl Privé "Docker".
La nouvelle doc est CONSULTABLE ICI

Il y a quelques autres fonctionnalités via l'API REST : https://eu.api.ovh.com, mais c'est pas la panacée et au niveau ergonomie, c'est préhistorique … mais je n'y ai pas vu d'import de dump.
— Il faut te loguer avec ton nick OVH
— Puis aller sur /hosting/privateDatabase (SQL Privés)
— Puis sur "GET" /hosting/privateDatabase tu clique sur le bouton Execute
Ça te donne la liste de tes SQL privés…
— Puis sur "GET" /hosting/privateDatabase/{serviceName} tu entres le nom du SQL Privé sur lequel tu veux intervenir et tu clique sur le bouton Execute.
Maintenant tu as un ensemble d'opérations possibles à faire.

JLB

15/03/2016, 17h23

Bonjour,

J’utilise un sql privé pour gérer mes bases de données dont certaines dépassent les 120 Mo.
Je crée ces bases de données en local, puis je les transfère sous forme de fichier .sql via FTP, dans le répertoire /import de mon sql privé.
Ensuite, j’accédais au Manager v3, rubrique « Administration », puis « Importation ». Je sélectionnais ensuite le fichier sql à importer ainsi que la base de données concernée.
Mais à présent, quand je me rends dans le manager v3, je ne trouve plus l’espace d’administration de mon sql privé.
A-t-il été déplacé ? Si oui comment y accéder à nouveau ?
A-t-il été supprimé ? Si oui, par quoi a-t-il été remplacé ?
J’ai pourtant lu et relu la documentation « SQL Privé - Importer une base de données » http://docs.ovh.com/pages/releasevie...ageId=12225511, en vain.
Comment dois-je procéder pour importer une base de données volumineuse sur sql privé ?
Merci pour votre aide.

cbleu

12/03/2016, 07h49

Envoyé par Bastijn

On y avait pensé, mais on a abandonné l'idée, voici les raisons :

reprenons ton exemple de site e-commerce :
1/ on laisse ton ancienne base SQL legacy en read-write
2/ tu dois dump tout seul, manuellement à l'instant T
3/ restore de l'autre coté, dans le nouvel SQL privé, à l'instant T+1
==> imaginons que tu aies eu ne serait-ce que 1 commande dans ton ancien SQLprivé, comment on fait ?

On tourne en boucle. Pour avoir été également webmaster, à partir du moment où je change de DB, je passe le site en maintenance, pour éviter toute corruption.

Coté ETA, ce qui nous a le + ralenti c'est le succès des offres actuelles et la mise en place des infras, pas le process de migration en lui meme.

Bonjour,

MIGRATION Legacy vers Docker :

On en est ou ?
C'est pour quand ? … le temps passe et toujours rien.
J'ai 1 Docker et 5 Legacy… J'aimerais bien migrer les Legacy, car aujourd'hui on sait plus ce qui se passe dessus, on a aucun tableau de bord pour savoir combien de mémoire est utilisé, pas de métriques, pas de conf et on est limité à 128 Mo (sans compter tout ce que l'on avait avant l'arrivée de Docker).

Sur Legacy finalement on est relativement BRIDÉ par rapport à Docker depuis le passage à la V6.

Une autre question : SQLprivé et IP publiques ça donne quoi ?
Ça intéresse pas mal de vos clients apparemment et on aimerait bien avoir la chance d'y accéder aussi...

Merci

testeur115

28/02/2016, 20h56

Ok donc je basculerai pas car je veux pas perdre mon serveur lol

chmod777

28/02/2016, 16h27

Envoyé par testeur115

Bonjour,

est-ce qu'à un moment donné on sera basculé automatiquement de legacy en docker ? et si oui est-ce que l'on change de serveur du coup ?

Salut,

Si je me base sur ce qui a déjà été dit sur le sujet...
1/ Non (mais ça fait plusieurs semaines qu'il y aurait déjà dû avoir la possibilité de basculer depuis l'espace client, d'après le 1er post du sujet).
2/ Oui (d'où le fait que ça ne soit pas fait automatiquement puisqu'il faudra modifier tous les fichiers où il y a une connexion établie à la bdd)

testeur115

28/02/2016, 08h09

Bonjour,

est-ce qu'à un moment donné on sera basculé automatiquement de legacy en docker ? et si oui est-ce que l'on change de serveur du coup ?

Bastijn

08/02/2016, 15h54

Envoyé par DJiK

Bonjour,

ft_min_word_len = 3 au lieu de 4 ce serait possible?

C'est la taille des mots qui sont indexés pour une recherche fulltext, et les mots de 3 lettres peuvent être importants dans une recherche. C'est le même réglage sur ce forum: recherchez "OVH, PHP ou SQL" et il n'y a aucun résultat pourtant ce sont des mots significatifs.
"serveur SQL" retourne toutes les pages qui contiennent "serveur" et SQL est ignoré, pourtant ça change tout.
Ça pourrait être changé aussi sur vos grosses BDD mutualisées puisqu'on ne peut pas le changer non plus.

On va regarder ça pour vous fournir cette possibilité via API. Par contre pas prévu sur les mutu, trop d'impacts

DJiK

06/02/2016, 09h39

Envoyé par Bastijn

S'il manque des paramètres, n'hésitez pas à nous expliquer pourquoi en dessous, merci

Bonjour,

ft_min_word_len = 3 au lieu de 4 ce serait possible?

C'est la taille des mots qui sont indexés pour une recherche fulltext, et les mots de 3 lettres peuvent être importants dans une recherche. C'est le même réglage sur ce forum: recherchez "OVH, PHP ou SQL" et il n'y a aucun résultat pourtant ce sont des mots significatifs.
"serveur SQL" retourne toutes les pages qui contiennent "serveur" et SQL est ignoré, pourtant ça change tout.
Ça pourrait être changé aussi sur vos grosses BDD mutualisées puisqu'on ne peut pas le changer non plus.

Anak1

21/01/2016, 17h37

Envoyé par Bastijn

Dans les nouveau SQLprivé docker, il n'y en a plus besoin, confer premier post. On a un onglet "configuration" dans le V6

Je dois être en "Legacy", je n'ai pas d'onglet "configuration" et visiblement le 2 Go n'est possible qu'avec l'infra Docker.

Envoyé par Bastijn

Désolé, je ne gère pas la partie commerciale, mais je remonte ton point.

Merci,
Un bon exemple c'est Free, on t'annonce des nouveautés auxquels tu as droit comme client (Augmentation des destinations de pays etc...)
Chez OVH, on t'annonce que c'est réservé aux nouveaux et que tu seras migré un jour, peut être.

Envoyé par Bastijn

On a encore très peu de demandes. Par curiosité quelles sont les fonctions phares ou Apps/CMS qui veulent du 5.6 ?

Je développe des apps natives + une boutique prestashop
MySQL 5.6
=> meilleur tenu en charge
=> recherche fulltext sur de l'innodb
La MySQL 5.7 est aussi intéressante pour les perf mais pas compatible prestashop encore

Envoyé par Bastijn

As-tu regardé du coté des instances CLOUD d'ovh ?
EG-7 est à 30 euros/mois pour 200go et 7GO de RAM. au pire tu testes au tarif horaire, et si cela te convient tu passes en mensuel.

C'est clairement intéressant et je suis sur que c'est beaucoup plus performant que mon PERF4 + SQL 1 GO sur du mutu
Faut tout installer soit même, j'ai pas de connaissances dans ces domaines de sécurité.
D'ailleurs en 10 ans j'ai jamais eu un site chez OVH piraté, de ce côté là vous faites le taff.

Le prix je veux bien mettre 100-150 € / mois, c'est pas le problème

Ce que je veux
- Une infra qui ne mette pas mon site down 3 fois par semaine (comme c'est le cas avec le mutu depuis 1 mois et demi)
- Sauvegarde auto journalière + 1 semaine
- Infogérance (pour la sécurité surtout même plafonné à 1h / semaine)
- PHP 7 + MySQL 5.6 avec une interface facile

Bastijn

21/01/2016, 15h29

Envoyé par Anak1

1/ Est-ce qu'il y aura l'outil de proposition de modif my.cnf ? c'est bien utile.

Dans les nouveau SQLprivé docker, il n'y en a plus besoin, confer premier post. On a un onglet "configuration" dans le V6

2/ Il m'était proposé de changer la quantité de ram depuis la v6
J'ai passé le BC et payé.
C'est resté a 1024, après avoir appelé on m'a dit qu'il y avait un problème.
On me propose de commander un autre SQL privé 2048 pour basculer dessus.
Depuis 2 jours j'attends la réponse du support pour avoir un "avoir" de mon ancien SQL privé si je choisit cette option.

Ok tu parlais de la RAM. l'update de ta RAM ne change pas ton type d'instance.

Il y a un truc récurent et dommageable chez OVH, plus t'es un ancien client, moins t'es aimé.
Au lieu de me passer en 2048, on le propose aux nouveaux clients et pour être basculé c'est la croix et la bannière.
Pour acheter un nouveau pas de problème mais pour se faire rembourser de l'ancien qui ne sera plus utilisé on croirait que c'est la mer à boire qu'on vous demande.

Désolé, je ne gère pas la partie commerciale, mais je remonte ton point.

3/ Bien dommage

On a encore très peu de demandes. Par curiosité quelles sont les fonctions phares ou Apps/CMS qui veulent du 5.6 ?
Coté Debian 8 c'est meme pas encore en package ( https://tracker.debian.org/pkg/mysql-5.6 )

4/ il s'agit du max_connections=192 dans le my.cnf ? car depuis le v6 je vois rien

La modif dont je parlais concerne seulement les nouveau SQLprivé

5/ (ok c'est pas dans la liste)
Actuellement je suis entrain de regarder pour un hébergeur qui propose du VPS infogéré (200Go / 6Go de ram) avec un CPANEL
Dommage qu'ovh ne prenne pas exemple sur la solution de planethoster (Malheureusement il font max 100 Go).
Au moins j'aurais un MySQL 5.6 avec 2 ou 3 Go de ram et tout sur le même serveur avec une IP dédié Française avec un support en France.
Même a 150 €/mois ça sera tjs plus intéressant que de prendre un dédié + de l'infogérance.

As-tu regardé du coté des instances CLOUD d'ovh ?
https://www.ovh.com/fr/cloud/instances/cpu.xml
EG-7 est à 30 euros/mois pour 200go et 7GO de RAM. au pire tu testes au tarif horaire, et si cela te convient tu passes en mensuel.

Anak1

21/01/2016, 13h16

[QUOTE=Bastijn;660007]Bonjour,

1/ Est-ce qu'il y aura l'outil de proposition de modif my.cnf ? c'est bien utile.

2/ Il m'était proposé de changer la quantité de ram depuis la v6
J'ai passé le BC et payé.
C'est resté a 1024, après avoir appelé on m'a dit qu'il y avait un problème.
On me propose de commander un autre SQL privé 2048 pour basculer dessus.
Depuis 2 jours j'attends la réponse du support pour avoir un "avoir" de mon ancien SQL privé si je choisit cette option.

Il y a un truc récurent et dommageable chez OVH, plus t'es un ancien client, moins t'es aimé.
Au lieu de me passer en 2048, on le propose aux nouveaux clients et pour être basculé c'est la croix et la bannière.
Pour acheter un nouveau pas de problème mais pour se faire rembourser de l'ancien qui ne sera plus utilisé on croirait que c'est la mer à boire qu'on vous demande.

3/ Bien dommage

4/ il s'agit du max_connections=192 dans le my.cnf ? car depuis le v6 je vois rien

5/ (ok c'est pas dans la liste)
Actuellement je suis entrain de regarder pour un hébergeur qui propose du VPS infogéré (200Go / 6Go de ram) avec un CPANEL
Dommage qu'ovh ne prenne pas exemple sur la solution de planethoster (Malheureusement il font max 100 Go).
Au moins j'aurais un MySQL 5.6 avec 2 ou 3 Go de ram et tout sur le même serveur avec une IP dédié Française avec un support en France.
Même a 150 €/mois ça sera tjs plus intéressant que de prendre un dédié + de l'infogérance.

Bastijn

21/01/2016, 09h09

Bonjour,

1/ il y a 80% des fonctionnalités dans le V6 : gestion des bases, gestion des users, gestions des tâches planifiées (dump etc) et my.cnf est modifiable par FTP
Il n'est pas prévu de réouvrir le V3. Ca ne résoud pas vos besoins j'en convient, notamment pour la RAM et processus, on se dépeche d'apporter la migration

2/ il est toujours impossible de migrer, ça m'étonnerait que ça puisse être dans le V6 étant donné que l'API n'est pas dispo.

3/ Non pas de date la dessus. par contre PGSQL arrivera Q1 2016

4/ La nouvelle structure limite par défaut à 100conexion par instance, et 50/user. vous pouvez dans votre maanger passer à 200/instance.

Anak1

20/01/2016, 13h10

Bonjour,

Je n'ai pas tout suivi

1) On m'indique le manager V6 remplace le V3
Il y a même pas 20% des fonctionnalités sur la V6
- Gestion du Gardien
- Conseil d'optims
ou alors il faut laisser
https://www.ovh.com/managerv3/sqlprive-main.pl
accessible depuis la v6

2) J'ai vu que mon SQL privé arrivait en limite des 1 Go
Au tel la hotline m'avait dit qu'il était impossible de migrer LEGACY vers DOCK (y a environ 3 semaines)
Depuis le manager V6 j'ai vu l'option hier, je me suis dit cool j'ai essayé et ça a planté
OVH doit me tenir informé après avoir eu qqn (35 mn d'attente au tel).

3) Quid de MySQL 5.6 et 5.7 ? Y a une date ou une roadmap la dessus ?

4) On m'a dit que SQL privé ne peut pas gérer plus de 100 utilisateurs simultantés.
Est-ce toujours le cas avec la nouvelle structure ?

Merci

mathieu14

15/01/2016, 15h07

bonjour, où est passé le dossier import dans le ftp ?
merci

Bastijn

15/01/2016, 08h38

Envoyé par cbleu

• Pourquoi ne pas laisser l'ancien serveur complètement actifs pendant 24/48 heures, lorsque le nouveau serveur Docker est activé. Ainsi le client (moi) peut faire sa migration lui même sans accros. Le client (moi) est responsable et pas OVH…
Qu'en pensez vous ?

On y avait pensé, mais on a abandonné l'idée, voici les raisons :

reprenons ton exemple de site e-commerce :
1/ on laisse ton ancienne base SQL legacy en read-write
2/ tu dois dump tout seul, manuellement à l'instant T
3/ restore de l'autre coté, dans le nouvel SQL privé, à l'instant T+1
==> imaginons que tu aies eu ne serait-ce que 1 commande dans ton ancien SQLprivé, comment on fait ?

On tourne en boucle. Pour avoir été également webmaster, à partir du moment où je change de DB, je passe le site en maintenance, pour éviter toute corruption.

Coté ETA, ce qui nous a le + ralenti c'est le succès des offres actuelles et la mise en place des infras, pas le process de migration en lui meme.

cbleu

14/01/2016, 22h12

Envoyé par Bastijn

Bonjour,
Rassurez-vous c'est toujours prévu. Le succès du nouveau SQLprivé nous a un peu ralenti.

Voici ce que l'on souhaite faire, ETA 3-4 semaines :
1/ vous permettre de migrer par API ou via le manager v6
2/ gratuitement
3/ en mode semi-automatique : dès l'instant où vous validez la migration (à 1h de l'aprem ou 2h du matin, peu importe), on met en lecture seule votre SQLprivé legacy, on dump, on restore dans un SQLprivé nouvelle génération. Le temps que ça prend dépendra de la taille de vos bases (je vous sors des estimations bientôt)
4/ les utilisateurs et droits seront également restaurés
5/ la configuration sera mise par défaut (on ne peut pas récupérer toutes vos infos de config car certaines sont dépréciés, confer premier post du topic)
6/ à la fin de la migration, vous recevez un email avec votre nouvel hostname+nouveau port (on utilise plus le port par défaut)
7/ il faudra changer votre hostname + port dans vos fichiers de configurations, comme wp-config, etc

Pré-requis : il faudra forcément être en MySQL 5.5 (les SQLprivé nouvelle génération n'existent pas en 5.1), pensez à migrer dès maintenant.

J'en conviens, il y aura +-3 semaines sans info sur la RAM, jusqu'à la migration. Pour l'onglet configuration, le my.cnf sera toujours modifiable via FTP pour les Legacy.

BONJOUR, PAS MAL MAIS …

REMARQUES :
— (Point 3) => C'est embêtant, par exemple pour un site de e-commerce, de mettre en lecture seule le serveur.
— (Pré-requis) : j'ai remarqué que MySQL 5.5 consomme beaucoup plus de mémoire… donc de migrer de 5.1 en 5.5 peut poser des problèmes dans certains cas.

SUGGESTIONS : PROPOSER UN PROCESS MANUEL…

• Pourquoi ne pas laisser l'ancien serveur complètement actifs pendant 24/48 heures, lorsque le nouveau serveur Docker est activé. Ainsi le client (moi) peut faire sa migration lui même sans accros. Le client (moi) est responsable et pas OVH…
Qu'en pensez vous ?

•Cela permettrais aussi peut-être d'accélérer le process. Ce serait là un process manuel, donc disponible beaucoup plus vite que les 3-4 semaines (ETA). Il suffirait de créer un thread spécifique où les clients intéressés laisseraient leur Nick et la référence de leur SQL privé.

On peut toujours rêver

Merci …

Bastijn

12/01/2016, 17h31

Envoyé par cbleu

Bonjour,

Le Manager V3 allant fermer AZAP…
Sur le manager V6, concernant l'infrastructure LEGACY on est un peu bridé par rapport à l'infrastructure Docker :
— Pas d'onglet "Métriques"
— Pas d'onglet "Configuration"
Que pense faire OVH à ce sujet ?
Comment va t'on gérer les fonctionnalités de la V3 manquantes dans le manager V6 ?

Pour MIGRER de LEGACY vers DOCKER, est ce possible ?

Merci

Bonjour,
Rassurez-vous c'est toujours prévu. Le succès du nouveau SQLprivé nous a un peu ralenti.

Voici ce que l'on souhaite faire, ETA 3-4 semaines :
1/ vous permettre de migrer par API ou via le manager v6
2/ gratuitement
3/ en mode semi-automatique : dès l'instant où vous validez la migration (à 1h de l'aprem ou 2h du matin, peu importe), on met en lecture seule votre SQLprivé legacy, on dump, on restore dans un SQLprivé nouvelle génération. Le temps que ça prend dépendra de la taille de vos bases (je vous sors des estimations bientôt)
4/ les utilisateurs et droits seront également restaurés
5/ la configuration sera mise par défaut (on ne peut pas récupérer toutes vos infos de config car certaines sont dépréciés, confer premier post du topic)
6/ à la fin de la migration, vous recevez un email avec votre nouvel hostname+nouveau port (on utilise plus le port par défaut)
7/ il faudra changer votre hostname + port dans vos fichiers de configurations, comme wp-config, etc

Pré-requis : il faudra forcément être en MySQL 5.5 (les SQLprivé nouvelle génération n'existent pas en 5.1), pensez à migrer dès maintenant.

J'en conviens, il y aura +-3 semaines sans info sur la RAM, jusqu'à la migration. Pour l'onglet configuration, le my.cnf sera toujours modifiable via FTP pour les Legacy.

cbleu

12/01/2016, 07h24

Envoyé par Bastijn

Bonjour,

Nous venons de rajouter dans le V6 pour les SQLprivé "Docker" un onglet "métriques.

Celui si vous informe de l'utilisation de la RAM sur les dernières 24H.
Nous allons rajouter semaine prochaine un second graph avec les connexion actives.

Si vous désirez + de métriques, pour rappel elles sont toutes récupérables par API (confer le guide au dessus)

Bonne fin de journée et bon reveillon à tous

Bonjour,

Le Manager V3 allant fermer AZAP…
Sur le manager V6, concernant l'infrastructure LEGACY on est un peu bridé par rapport à l'infrastructure Docker :
— Pas d'onglet "Métriques"
— Pas d'onglet "Configuration"
Que pense faire OVH à ce sujet ?
Comment va t'on gérer les fonctionnalités de la V3 manquantes dans le manager V6 ?

Pour MIGRER de LEGACY vers DOCKER, est ce possible ?

Merci

Bastijn

31/12/2015, 15h50

Bonjour,

Nous venons de rajouter dans le V6 pour les SQLprivé "Docker" un onglet "métriques.

Celui si vous informe de l'utilisation de la RAM sur les dernières 24H.
Nous allons rajouter semaine prochaine un second graph avec les connexion actives.

Si vous désirez + de métriques, pour rappel elles sont toutes récupérables par API (confer le guide au dessus)

Bonne fin de journée et bon reveillon à tous

Bastijn

29/12/2015, 10h16

Bonjour nous avons également mis en ligne un Guide sur la mise en place de Grafana (guide avancé)
Ca permet de récupérer bien + de métriques que ce qu'on mettra dans le manager

Mis à part la RAM, vous pouvez avoir des infos sur les connections actives, le CPU, les I/O, ...

Guide : https://www.ovh.com/fr/g2057.recuper...ve_sur_grafana

Bastijn

28/12/2015, 10h28

Effectivement, mauvaise implémentation APi dans le manager, je viens de vérifier.

La fonction https://api.ovh.com/console/#/hosting/web/{serviceName}/databaseCreationCapabilities#GET
retourne le nombre de DB que l'on peut encore créer. mais le manager affiche ce nombre au lieu d'afficher [Quota moins ceNombre].
on va régler ça

chmod777

23/12/2015, 15h27

Envoyé par Bastijn

ça dépend des produits commandés
Si par exemple tu as un Perf, il y a un Bdd SQLprivé incluse, à activer. Si en plus un SQLprivé a été commandé à coté, en supplément, alors oui c'est normal.

J'ai bien un hébergement Performance mais le sql privé a déjà été activé et, justement, je n'en ai pas commandé d'autres. Est-ce volontaire pour les anciens qui ont un sql privé "Legacy" ou un bug ?

Bastijn

23/12/2015, 15h16

ça dépend des produits commandés
Si par exemple tu as un Perf, il y a un Bdd SQLprivé incluse, à activer. Si en plus un SQLprivé a été commandé à coté, en supplément, alors oui c'est normal.

chmod777

23/12/2015, 15h04

"Base de données privée : 0/1 - Activer"
Normal d'avoir ça dans l'onglet Hébergement, alors que le SQL privé (Legacy de mon côté) est pourtant bien fonctionnel ? (je n'ai pas essayé de cliquer sur Activer)

cavapulser

22/12/2015, 16h41

Au fait, je signale ce fil pour les personnes qui pourraient être concernées :
SQLPrivé "Legacy", Manager v6 et nouvelle infrastructure = Le BINZ !

Bastijn

22/12/2015, 15h39

Super. Maintenant que c'est ok pour toi coté API, si tu cherches toujours à créer des dashboards grafana, hésite pas. bonne journée

Julia

22/12/2015, 14h32

Hello,

J'ai fini par comprendre le problème.

Il y avait une confusion entre les anciens sqls et les nouveaux.

Ex: nom de l'ancien sql (sqlprive-nic-001 - Docker)
le nouveau sql (nic-001 - Legacy) a été renommé sqlprive-nic-003 par un collègue.

Et ainsi de suite....

L'utilisation du NIC sans le préfix sqlprive avec la nouvelle infra lui semblait poser quelques difficultés de compréhension...

Désolé pour cette erreur!

Encore merci!
Julia

Bastijn

22/12/2015, 09h25

Hello, tu peux me communiquer ton NIC + le nom de ton instance SQLprivé Docker que tu devrais voir via API ? tu trouveras ce nom dans ton manager (il est marqué dans ton nom d'hôte entre autres, vbxxxx-xx.privatesql.ovh.net)

On va regarder ça

Julia

21/12/2015, 14h58

Envoyé par Bastijn

non du tout. je viens de retester.
en premier se logguer en haut à droite (nic ovh)
D'abord appeler celle la : https://api.ovh.com/console/#/hostin...teDatabase#GET
Comme ça, tu as la liste exacte des services
ensuite dans /hosting/privateDatabase/{serviceName}
si tu cliques 2x dans le champ value, il y a de l'autocomplétion pour le nom du service

et voila

Je dois m'y prendre mal...

J'obtiens un résultat que pour les bases de l'ancienne infra (legacy) avec 1 qui est normalement plus en service (...)

Pas d'autres bases...

Bastijn

21/12/2015, 14h36

Envoyé par Julia

Les demandes en get pour un serveur Docker indiquent :

Not Found (404)
{ "message": "This service does not exist" }

Pas de problème pour un serveur en legacy.

Est-ce un comportenement normal ?

Merci!
Julia

non du tout. je viens de retester.
en premier se logguer en haut à droite (nic ovh)
D'abord appeler celle la : https://api.ovh.com/console/#/hostin...teDatabase#GET
Comme ça, tu as la liste exacte des services
ensuite dans /hosting/privateDatabase/{serviceName}
si tu cliques 2x dans le champ value, il y a de l'autocomplétion pour le nom du service

et voila

Julia

21/12/2015, 14h21

En utilisant la fonction https://api.ovh.com/console/#/hosting/privateDatabase/{serviceName}#GET
(pour rappel il suffit de se logger en haut à droite)

Les demandes en get pour un serveur Docker indiquent :

Not Found (404)
{ "message": "This service does not exist" }

Pas de problème pour un serveur en legacy.

Est-ce un comportenement normal ?

Merci!
Julia

Bastijn

21/12/2015, 14h05

Envoyé par Julia

Bonjour,

Les bases sur la nouvelle infra ne sont pas encore prises en compte ?

Merci!
Julia

Pas sûr de bien comprendre, si c'est de savoir si les nouvelles SQLprivé "Docker" sont visualisables dans Grafana, la réponse est oui
Par contre par les anciennes (legacy)

toutes ces métriques sont récupérables : https://docs.docker.com/engine/articles/runmetrics/
un guide est en cours d'écriture (en parallèle de l'ajout d'infos dans le V6)

Julia

21/12/2015, 11h32

Envoyé par Bastijn

Bonjour, les métriques sont disponibles par API

En utilisant la fonction https://api.ovh.com/console/#/hosting/privateDatabase/{serviceName}#GET
(pour rappel il suffit de se logger en haut à droite)

Vous allez avoir entre autres :
graphEndpoint: {
readToken: "6PUp60NtWFhxxxxxxxxxxxxx"
host: https://opentsdb.iot.runabove.io
}
Coté OVH, on va utiliser cette source pour générer des graphiques et les mettre dans le manager. on espère aussi rapidement vous fournir un dashboard Grafana (http://grafana.org/)

Si vous êtes familier avec cette technologie, vous pouvez d'ores et déjà installer Grafana vous-même et y ajouter cette source.

Bonjour,

Les bases sur la nouvelle infra ne sont pas encore prises en compte ?

Merci!
Julia

Bastijn

14/12/2015, 13h44

Bonjour, les métriques sont disponibles par API

En utilisant la fonction https://api.ovh.com/console/#/hosting/privateDatabase/{serviceName}#GET
(pour rappel il suffit de se logger en haut à droite)

Vous allez avoir entre autres :
graphEndpoint: {
readToken: "6PUp60NtWFhxxxxxxxxxxxxx"
host: https://opentsdb.iot.runabove.io
}
Coté OVH, on va utiliser cette source pour générer des graphiques et les mettre dans le manager. on espère aussi rapidement vous fournir un dashboard Grafana (http://grafana.org/)

Si vous êtes familier avec cette technologie, vous pouvez d'ores et déjà installer Grafana vous-même et y ajouter cette source.

Bastijn

08/12/2015, 17h33

Concernant les métriques, l'API est en test interne chez nous, j'espère la fournir dans les jours qui viennent
Vous aurez la possibilité de générer vos propres Dashboards (via un Grafana chez vous, ..), et ensuite, d'avoir également des résumés des stats dans le manager.

Pour migrer manuellement vers Docker, on a pris du retard : on a préféré passer toutes les SQLprivé de 128mo à 256mo par défaut. il a fallu revoir l'infra pour faire ça, mais le process de migration est toujours d'actualité. J'essaie d'avoir une ETA demain.

Pour les Dumps : peux-tu me liste les questions que tu te poses ? qu'on puisse y répondre 1 à 1 et si besoin, améliorer nos guides et manager. MErci

Pour la duplication, rien de fait. C'est dans notre Todo, mais non prioritaire pour l'instant.

cbleu

07/12/2015, 15h49

Envoyé par Bastijn

... Octobre/Novembre …
- Docker : Accès à vos métriques en Live (utilisation de la RAM, les I/O, ..) sur un dashboard web Grafana
- Legacy : Migration vers la nouvelle infrastructure Docker, manuellement depuis le manager V6
.../...
VOUS VOULEZ MIGRER SUR LA NOUVELLE INFRA ?
Super
Le process actuel est en cours de création et de mise en place, cependant si vous souhaitez voir avec nous pour une upgrade manuelle, postez dans ce topic votre NIC et on vous rappelle (la migration est définitive, et implique un changement de config de votre coté). ...

Bonjour à toute l'équipe,

On est en décembre (Roadmap)…
— On a toujours pas accès aux métriques en live. Qu'en est-il ?
— Migration manuelle de Legacy vers Docker : Où en est t-on ?

Concernant les lenteurs de la V6 relatées par les utilisateurs sur les forums, ou est-on ?

Pour les Dumps, c'est pas clair, on ne sait pas vraiment ce que l'on réellement a sur la nouvelle infra.
Avant, sur Legacy, on avait un espace FTP suffisamment large pour y stocker les dumps a notre convenance...

Envoyé par cbleu

POUR LA DUPLICATION ...
L'idéal serait de pouvoir dupliquer en interne et en externe…
— En interne (sur le SQL Privé) :
• c'est utile par exemple, lorsqu'on publie un site type CMS et que l'on a besoin d'avoir un site de pré-prod + un site de test/développement.
— En externe ça existe déjà sur les anciens SQL Privé...

Pour la duplication qu'en est-il ?

Merci

datsunfr

10/11/2015, 07h54

merci pour ta réponse

les dumps gardés 30j et sur un espace externe, cela me va bien

ne voyant pas ni paramètre de nombre max ou age max, ni moyen de purge, je m'inquiétais de saturer mon espace et bloquer ma BD

Julia

06/11/2015, 16h24

Envoyé par Bastijn

Limite de dump : tu voudrais gérer ça comment ?
Supprimer des Dumps : pour l'instant tu peux pas via le manager, on va l'activer. la on les gardes 30j

Il faut savoir que ces dumps ne sont plus archivés dans un espace personnel, mais sur une infra scalable. En quelque sorte on essaye de vous simplifier la vie, OVH se charge des backups maintenant (mais en tant que client je comprend qu'on aie envie d'en supprimer, du coup ça arrive)

Contraint et forcé de basculer sur cette nouvelle infra, je teins à vous informer de ma déception.

Plus d'accè FTP (my.cnf, slow.log, ...)
Plus de Gardien
Plus d'optimisation de configuration
Plus...

Cela associé à une interface vraiment pas ergonomique (ou finalisée)...

Brref...

Bastijn

28/10/2015, 17h23

Envoyé par datsunfr

pour les sauvegardes planifiées, comment limite-t'on le nombre de dumps archivés?

comment supprime-t'on les dumps obsolètes?

merci

Limite de dump : tu voudrais gérer ça comment ?
Supprimer des Dumps : pour l'instant tu peux pas via le manager, on va l'activer. la on les gardes 30j

Il faut savoir que ces dumps ne sont plus archivés dans un espace personnel, mais sur une infra scalable. En quelque sorte on essaye de vous simplifier la vie, OVH se charge des backups maintenant (mais en tant que client je comprend qu'on aie envie d'en supprimer, du coup ça arrive)

Bastijn

28/10/2015, 17h16

Envoyé par Yanlep

Oui, j'ai finalement appelé le service technique pour qu'on me règle ce problème.

Par contre mon Prestashop est toujours aussi lent (quand on est connecté ou qu'on a des produits dans son panier) malgré les 520 Mo de RAM sur le serveur SQL : http://shop.nationphoto.com

Désolé, j'ai pas accès aux tickets ouverts par les clients, je ne sais pas si une action est encore en cours, mais les appeler est effectivement la bonne solution.

datsunfr

27/10/2015, 19h03

pour les sauvegardes planifiées, comment limite-t'on le nombre de dumps archivés?

comment supprime-t'on les dumps obsolètes?

merci

Yanlep

27/10/2015, 17h49

Envoyé par Sylthom

vite fait en passant, je viens de checker et c'est up maintenant

Oui, j'ai finalement appelé le service technique pour qu'on me règle ce problème.

Par contre mon Prestashop est toujours aussi lent (quand on est connecté ou qu'on a des produits dans son panier) malgré les 520 Mo de RAM sur le serveur SQL : http://shop.nationphoto.com

Sylthom

27/10/2015, 17h07

Envoyé par Yanlep

Du coup tout mon site est planté !

J'ai tenté de redémarrer le serveur, mais rien ne change.

Là ça va faire 5h que c'est comme ça !
En un mot : HELP

vite fait en passant, je viens de checker et c'est up maintenant

Yanlep

27/10/2015, 16h00

Bonjour,

moi je suis sur le serveur 10.0.234.39 (sqlprive-ly31026-001), donc Infrastructure Legacy.
J'avais un problème de version qui m'indiquait 5.5 (alors qu'en vrai c'était 5.1) et j'ai dû passer par l'ancien manager pour changer vraiment en 5.5.
J'ai fait ça dimanche, mais j'ai lu plus haut qu'il y avait justement eu un problème ce jour-là.

Aujourd'hui j'ai augmenté la RAM pour passer à 512 Mo mais la connexion n'est plus disponible depuis ce midi :

Link to database cannot be established: SQLSTATE[HY000] [2013] Lost connection to MySQL server at 'reading initial communication packet', system error: 111

Du coup tout mon site est planté !

Dans le manager d'OVH j'obtiens aussi :

Une erreur s'est produite lors de la connexion à votre serveur SQL.
Il peut être surchargé ou inaccessible pour divers raisons.
Erreur détaillée :
Lost connection to MySQL server at 'reading initial communication packet', system error

J'ai tenté de redémarrer le serveur, mais rien ne change.

Là ça va faire 5h que c'est comme ça !
En un mot : HELP

Bastijn

27/10/2015, 15h11

Envoyé par Julia

Merci !

Adresse IP du serveur : 10.0.206.83
sqlprive-----001
Dimanche, nous avons atteint 98% de la conso ram.
Le fichier slow.log a accumulé les enregsitrements...

Si vous avez un début de réponse...

[TICKET#2015102619020894]

Encore merci!
Julia

Tu es donc sur un SQLprivé legacy (ancienne version).
Effectivement, il y a eu un souci de swap dimanche, résolu le 26/10 (hier). Le serveur a une uptime de +1000 jours ça reste correct

Notre nouvelle plateforme n'a donc rien à voir avec ton souci, un conseiller va répondre à ton ticket asap. bonne journée !

Julia

27/10/2015, 09h05

Envoyé par Bastijn

En cours de modification chez nous, merci.

- - - Mise à jour - - -

Bonjour Julia, tu pourrais nous donner un peu plus de détails ? serveur etc.

Merci !

Adresse IP du serveur : 10.0.206.83
sqlprive-----001
Dimanche, nous avons atteint 98% de la conso ram.
Le fichier slow.log a accumulé les enregsitrements...

Si vous avez un début de réponse...

[TICKET#2015102619020894]

Encore merci!
Julia

Bastijn

27/10/2015, 08h41

Envoyé par chmod777

Ok, merci pour vos retours, je vais attendre encore un peu.

Sinon, petit souci au niveau de la date d'expiration du sql privé qui n'est pas mise à jour quand on renouvelle l'hébergement (performance) auquel il est associé. Sur le manager v3, la date n'est pas affichée dans ce cas, il y a juste un "nd" à la place.

En cours de modification chez nous, merci.

- - - Mise à jour - - -

Envoyé par Julia

Bonjour,

Est-ce votre intervention qui rend certains SQLPRIV. instables depuis vendredi ?

+de 20 secondes pour certaines requêtes...

Merci pour votre réponse !

Julia

Bonjour Julia, tu pourrais nous donner un peu plus de détails ? serveur etc.

Julia

27/10/2015, 08h04

Bonjour,

Est-ce votre intervention qui rend certains SQLPRIV. instables depuis vendredi ?

+de 20 secondes pour certaines requêtes...

Merci pour votre réponse !

Julia

chmod777

26/10/2015, 11h29

Envoyé par Alex.P

Non il y a un changement de server ( ip + port )

Actuellement les migrations seront manuel ( de votre coté ) par la suite nous proposerons une migration automatique ( gratuite ).

Donc il va falloir recréer les taches.

Alex.P

Ok, merci pour vos retours, je vais attendre encore un peu.

Sinon, petit souci au niveau de la date d'expiration du sql privé qui n'est pas mise à jour quand on renouvelle l'hébergement (performance) auquel il est associé. Sur le manager v3, la date n'est pas affichée dans ce cas, il y a juste un "nd" à la place.

Orni

23/10/2015, 06h51

Envoyé par Bastijn

Tu parles bien des SQLprivé Legacy (les anciens) ? Si oui, tente de recréer tes sauvegardes planifiées dans le manager V6. on ne permet pas de programmer jusque dans la minute précise, mais les CRONS sont lancés dans l'heure choisie, sans attente.

Pour les sauvegardes, il n'y a plus de problèmes d'espace non plus. On impose aucun quota au client, et nous compressons automatiquement de notre coté.

Oui je parlais bien des Legacy. Je vais tenter via le manager v6, mais je ne vois pas la base actuelle, je vais être obligé de la recréer et de la transférer. En tout logique ça devrait le faire.
Merci pour le retour !

cbleu

23/10/2015, 01h56

@Alex.P

Bonsoir,

Merci pour vos réponses

POUR LA DUPLICATION
L'idéal serait de pouvoir dupliquer en interne et en externe…
— En interne (sur le SQL Privé) :
• c'est utile par exemple, lorsqu'on publie un site type CMS et que l'on a besoin d'avoir un site de pré-prod + un site de test/développement.
— En externe ça existe déjà sur les anciens SQL Privé.

POUR LES REDÉMARRAGES PLANIFIÉS (CRON).
En y réfléchissant bien, il est vrai que sur cette nouvelle infrastructure il n'y en a plus vraiment besoin.

ROADMAP :
Si on pouvait avoir des dates, ce serait vraiment bien.

Merci

Bastijn

22/10/2015, 13h51

Envoyé par Orni

Bonjour,

Un gros problème sur les SQL Privés actuels, ce sont les timings : des sauvegardes programmées à heures régulières qui se font toutes le matin ou l'après-midi au lieu d'être sur toute la journée, un redémarrage que l'on doit attendre plus de 2 ou 3 heures, etc. Tout est en décalé ou prend un temps fou et nous oblige à créer des scripts sur l'hébergement mutualisé pour des actions qui sont censées être ok via la gestion du SQL Privé.

Autre choses sur les sauvegardes, une option (ou obligation) de zip/tar/gzip, afin de gagner de l'espace sur l'FTP.

Merci !

Tu parles bien des SQLprivé Legacy (les anciens) ? Si oui, tente de recréer tes sauvegardes planifiées dans le manager V6. on ne permet pas de programmer jusque dans la minute précise, mais les CRONS sont lancés dans l'heure choisie, sans attente.

Pour les sauvegardes, il n'y a plus de problèmes d'espace non plus. On impose aucun quota au client, et nous compressons automatiquement de notre coté.

Orni

22/10/2015, 09h12

Bonjour,

Un gros problème sur les SQL Privés actuels, ce sont les timings : des sauvegardes programmées à heures régulières qui se font toutes le matin ou l'après-midi au lieu d'être sur toute la journée, un redémarrage que l'on doit attendre plus de 2 ou 3 heures, etc. Tout est en décalé ou prend un temps fou et nous oblige à créer des scripts sur l'hébergement mutualisé pour des actions qui sont censées être ok via la gestion du SQL Privé.

Autre choses sur les sauvegardes, une option (ou obligation) de zip/tar/gzip, afin de gagner de l'espace sur l'FTP.

Merci !

Alex.P

21/10/2015, 09h17

Non il y a un changement de server ( ip + port )

Actuellement les migrations seront manuel ( de votre coté ) par la suite nous proposerons une migration automatique ( gratuite ).

Donc il va falloir recréer les taches.

Alex.P

chmod777

21/10/2015, 08h47

Bonjour,

Intéressé pour la migration. Juste quelques questions, reste-t-on bien sur le même serveur (donc pas de changement à faire sur les scripts de connexion à la base) ? Et les paramètres actuels (sauvegardes planifiées, backups ftp) sont-ils bien conservés lors du changement ?

Merci.

emielb

20/10/2015, 21h12

Très bonne initiative !
J'attends avec impatience de pouvoir tester les sauvegardes planifiées directement depuis le managerV6. Ayant plusieurs sites en production sur mon SQL Privé je préfère attendre un petit peu avant de passer de Legacy à Docker.
En tout cas merci pour ces améliorations.

Alex.P

20/10/2015, 10h59

— Importer un dump (pour une grosse base de données) depuis un dossier "/import" depuis le FTP (Vous n'en parlez pas !!!) - AZAP

Le but est de vous proposer d'uploader votre fichier sur http://demo.ovh.eu/ ( ou autres services ) et de la nous faisons l'import. C'est dans le pipe.

— Restauration des sauvegardes (via manager V6 biensur).

c'est déjà le cas. Tu as juste à cliquer sur le nombre de dump disponible dans le manager v6

Duplication (vous n'en parlez pas non plus).

Peux tu me préciser ton besoin exact : tu veux dupliquer de ou ? base mutu ? base externe ?

Redémarrages planifiés CRON (vous n'en parlez pas non plus).

Votre instance doit toujours etre up, nous faisons de la maintenance 24h/24 ( astreintes, optimisations de votre configuration .... )

Quel est ton besoin ?

Accès aux métriques en Live (Très bonne idée)

On travaille dessus.

— Optimisation (vous n'en parlez pas non plus).

C'est notre travail de vous fournir une configuration optimisé en fonction de votre RAM disponible. Vous n'avez donc plus à vous soucier de la configuration de votre privatesql. Les options de configurations sont la pour affiner certaines options non critiques.

Le but : que vous obteniez une bonne qualité de service et non des serveurs sql qui plantent toutes les 2h car vous avez une mauvaise configuration my.cnf ( et donc besoin de cron de restart de server par exemple ... )

Gardien (vous n'en parlez pas non plus).

C'est dans le pipe.

Cela concerne les nouveaux sql privé.

cbleu

20/10/2015, 10h35

Bonjour,

Il était temps de mettre un thread dédié pour les nouveaux SQL Privé.

Je fait partie de ces clients habitués aux anciens SQL Privés qui se sont retrouvé le "bec dans l'eau" face aux nouveaux SQL Privé jusqu'à il y a peu de temps.
Ils ne sont réellement utilisables (professionnellement) que depuis le 15 octobre, et encore…

Merci pour les sauvegardes planifiés et la modification de config !!! :-)
Merci pour les nouveautés liés à la plateforme…

EN URGENCE — FONCTIONNALITES MANQUANTES :
— Importer un dump (pour une grosse base de données) depuis un dossier "/import" depuis le FTP (Vous n'en parlez pas !!!) - AZAP
— Refonte de la page d'informations générales (consommation en particulier). AZAP aussi
— Restauration des sauvegardes (via manager V6 biensur).

MOINS URGENT — FONCTIONNALITES MANQUANTES :
— Duplication (vous n'en parlez pas non plus).
— Redémarrages planifiés CRON (vous n'en parlez pas non plus).
— Accès aux métriques en Live (Très bonne idée)

BIEN MOINS URGENT — FONCTIONNALITES MANQUANTES :
— Optimisation (vous n'en parlez pas non plus).
— Gardien (vous n'en parlez pas non plus).

-----------

Une roadmap détaillée avec des dates, serait vraiment bien, merci.

cordialement

Bastijn

19/10/2015, 09h22

Bonjour à tous,

Depuis quelques semaines, OVH livre les nouvelles bases de données SQLprivés sur une nouvelle infrastructure.
Le but final est de gagner en performance, fiabilité et fonctionnalités.

Nous allons ici vous expliquer les changements. N'hésitez pas à nous faire vos retours sur ce qu'il vous manque, ce qui est à améliorer, et aussi ce qui va bien

NOUVELLE INFRASTRUCTURE ?
Dans l'optique d'un développement de nouvelles fonctionnalités, l'ancienne infrastructure, bien que performante, devenait limitée.
Nous avons chez OVH des besoins internes qui évoluent, et étant notre premier client nous avons décidé de construire une architecture bien plus souple, basée sur des conteneurs Docker.
Votre instance est isolée dans un container Docker, garantissant une parfaite indépendance et des ressources garanties. Cela nous permet également de déployer à grande échelle rapidement et proprement.

Pour savoir si votre SQLprivé est sur la nouvelle infrastructure, rendez-vous dans votre Managerv6. Cliquez sur votre SQLprivé, puis dans l'onglet Général > Infrastructure
- Legacy : ancienne infrastructure
- Docker : nouvelle infrastructure

NOUVEAUTES
- + de mémoire RAM : chaque offre dispose désormais d'un quota garanti et d'un quota "Best-Effort" équivalent. Par exemple avec l'offre 128 Mo, vous pouvez temporairement dépasser votre quota jusque 256 Mo.
- + de fonctionnalités : confer les roadmaps ci-dessous
- Connexion SFTP (Secure FTP) au lieu de FTP

CONFIGURATION : LEGACY VS DOCKER
Pour toutes les bases de données SQLprivés LEGACY, OVH permet un accès Root et un fichier de configuration (my.cnf) pour paramétrer sa base.
Cela peut être à double tranchant, particulièrement pour les utilisateurs non expérimentés.
Aujourd'hui, sur la nouvelle infrastructure, nous réfléchissons différemment : l'API et le manager vous donnent accès à des paramètres modifiables (si vous êtes sur l'infra Docker, dans le Managerv6 vous avez maintenant un onglet Configuration).

S'il manque des paramètres, n'hésitez pas à nous expliquer pourquoi en dessous, merci

FAIT
(ajouté depuis le 15/10) Docker : Sauvegardes planifiées (CRON DUMP) : cette fonction permet de sauvegarder votre base périodiquement via managerv6.
(ajouté depuis le 15/10) Legacy : le DUMP est disponible, mais pas sa planification, elle arrive.
(ajouté depuis 19/10) Docker : modifier ses paramètres de configuration via le manager V6 (nouvel onglet)
(ajouté depuis le 16/10) Docker/Legacy : Restauration de sauvegardes planifiées. pour l'instant disponible par API seulement, permet de restaurer des sauvegardes.
(ajouté depuis le 21/10) Docker/Legacy : Refonte de la page d'informations générales : meilleure ergonomie sur les moyens de connexion. Manque la conso RAM/IO/.., va être dispo via Live metrics pour Docker
(ajouté le 22/10) : Legacy : planification des sauvegardes (DUMP) via v6
(ajouté le 30/10) - Docker/Legacy : Restauration des sauvegardes via manager V6
(ajouté le 2/11) - Legacy : Gestion des tâches planifiées (CRON) depuis le manager V6
(ajouté le 14/12) : Docker : métriques disponible par API (guide https://www.ovh.com/fr/g2057.recuper...ve_sur_grafana )
(ajouté le 31/12) Docker : métrique RAM ajouté dans le manager (nouvel onglet Métriques)
(ajouté le 07/04) Import de bases de vonnées depuis le manager v6
(en cours en Avril ) Migration vers la nouvelle infrastructure Docker, automatiquement par OVH, sans perte d'ip

ROADMAP COURT TERME (DECEMBRE / JANVIER)
(abandonné)- Legacy : Migration vers la nouvelle infrastructure Docker, manuellement depuis le manager V6
- Docker : Gardien SQLprivé

ROADMAP MOYEN TERME
- Docker : Accès à vos logs en live (pour l'instant disponible via le SFTP seulement)

NON PLANIFIÉ SUR LA NOUVELLE INFRA
Certaines fonctionnalités Legacy ne sont pas présentes avec les nouvelles infrastructure, à savoir :
- Proposer des version MySQL < 5.5
- Donner l'accès Root. Confer la section "CONFIGURATION : LEGACY VS CONTAINER"
- Permettre l'édition d'un fichier my.cnf. Confer la section "CONFIGURATION : LEGACY VS CONTAINER"
- Lister les process en cours
- recevoir les alertes : maintenant c'est l'astreinte OVH qui les reçoit
- Récupération d'urgence : maintenant on a un restart automatique

VOUS VOULEZ MIGRER SUR LA NOUVELLE INFRA ?
Super
Update : le process est créé, OVH gère tout. Vous garder votre IP, et il y aura une coupure maximale de 2 minutes.
Les premieres migrations on débuté le 7/04.

Merci d'avoir lu jusqu'au bout, à force d'avoir la tête dans le guidon on en oublie de communiquer et cela vous agace à juste titre.
On va mettre ce topic à jour quand on sortira de nouvelles fonctionnalités.

Et n'oubliez pas de suivre les ajouts dans la console API OVH : https://api.ovh.com/console/#/hosting/privateDatabase
Vous pouvez tester toutes les fonctionnalités en avant première, rien qu'en vous connectant avec vos identifiants OVH (avant l'intégration dans le Managerv6)
Pas besoin de coder ! Attention, les actions de l'API sont réelles...