Bonjour
est 'il possible de faire communiquer les deux , c'est a dire
je teste avec une base sqlperso (xxx.mysql.db) et le script d'installation spip (pas de phpmyadmin pour tester :/ ) tout est ok
avec une base créée dans l'instance st185596-001, échec de connexion, avec des logs bizarres que je peux plus consulter avec cette fenêtre intrusive....
serveurs utilisé:
st185596-001.dbaas.ovh.net:35262
utilisateur: st185596-ovh sans effet
ip autorisée: 87.98.154.146 sans effet
pas d'exemples concrets dans vos docs, pouvez vous nous confirmer les bons paramètres de connexions ? notamment cette histoire d'ip autorisée, pour un hebergement web pro, que doit on indiquer?
sql privé est bien compatible avec web pro?
en vous remerciant par avance d'une réponse rapide qui nous permettrait d'avancer
Hébergements Web - Résolu .... Hebergement pro + sql privé
Related questions
- Connexion à mon compte client
155699 
13.02.2019 09:51
- Serveur non sécurisé, celui-ci ne supporte pas FTP sur TLS
127685 03.09.2018 14:46
- reCAPTCHA erreur pour le propriétaire du site : clé de site non valide
111910 14.02.2019 16:17
- [FAQ] Comment mettre à jour mon site pour supporter Apache 2.4 ?
99109 28.07.2017 11:39
- Passage en php 7.4
98229 30.06.2020 05:05
- Augmenter taille PHP Post Max Size sur mutualisé ?
92773 04.12.2019 21:52
- Deploy d'un projet Node JS
91803 12.10.2016 20:18
- The requested URL / was not found on this server
91800 02.03.2017 18:25
- Ce site est inaccessible Impossible de trouver l'adresse DNS du serveur
91659 16.10.2016 16:24
- NextCloud sur mutualisé
91527 07.04.2017 08:42
Bonjour,
Je suppose que vous avez un CloudDB ?
Si oui il faut autoriser l'IP de sortie du cluster.
Cordialement, janus57
je pense pas car dans mes services j'ai
MX Plan spipfactory.fr Juillet 2019 Automatique
Hébergement base SQL privée st185596-001 Expire le 23 juil. 2019 Manuel
Hébergement web + domaine
bien entendu j'ai envoyé un ticket hier ........
le telephone quand a lui ne répond pas ;)
oui c'est bien un cloudDB
essai avec cette ip: 87.98.154.146, mais c'est l'ip externe du site
je vois pas où trouver/connaitre l'ip du cluster 026?
la commande à été faite pour un sqlPrivé, installé un cloudDB, mais dans la configuration de l'hébergement, il y a une zone _base de données privée_ où on ne peut que commander... curieux
Bonjour,
Toutes les IPs sont dans la doc : https://docs.ovh.com/fr/hosting/liste-des-adresses-ip-des-clusters-et-hebergements-web/
Et si vous avez une whiteliste alors c'est du CloudDB et non du SQL Privé qui fonctionne que en mutu.
Cordialement, janus57
ok, c'est bien l'ip essayée en premier, sans succès donc. whitelist, donc cloudDb, c'est noté
si je regarde les logs _AVANT_ de ré-essayer:
```
26/07/2018 14:59 stderr 2018-07-26 16:59:18 4329397638912 [Warning] Connection attributes of length 108 were truncated
```
sans discontinuer, toutes les secondes, depuis la création hier j'imagine
ré-essai: **échec**, sans erreur spécifique dans les logs :/
déjà essayé en changeant le mot de passe hier, sans succès. réussite immédiate lors d'une tentative en créant une base sur l'hébergement mutu.
ça va faire 24h qu'un ticket a été déposé, on peut considérer cela ***normal*** un tel manque de réactivité du support chez ovh?
Bonjour,
Quel IP ??
Car celle-ci (donne plus haut) pour le cluster026 est pas bonne il faut indiquer l'IP de sortie en whiteliste et non l'IP d'entrée (ce qui est le cas plus haut).
Cordialement, janus57
ok, vu quel __c**__ je suis, me semblait que le principe était pas bon, je viens de relire les https://docs.ovh.com/fr/hosting/liste-des-adresses-ip-des-clusters-et-hebergements-web/ ip des clusters, je vais réessayer avec 91.134.248.211
edit (aberration: new user limité à 3 post sur discourse, du n'importe quoi):
bingo, **connexion réussie**. merci **beaucoup**
c'est moi qui fatigue ou j'avais pas vu la doc des ip dans la doc des bases sql?
toujours les erreurs de logs mais pour l'instant c'est pas le plus grave
Bonjour,
bah normalement elle est dans la doc des mutus (utile quand un presta bloque une IP de sortie d'un cluster, par exemple) et non des bases SQL (elle n'aurait rien à y faire d'ailleurs).
Cordialement, janus57
elles se trouvent où elles veulent, mais comme c'est obligatoire pour se connecter sur un cloudDB, on peut s'attendre à y trouver au moins un lien!
enfin, dans la logique de beaucoup...
Bonjour,
le "truc" c'est que une base CloudDB n'est pas censé être utilisé en mutu, outre l'absence de phpMyAdmin (qui peu rebuter), il y a les restriction du mutu qui s'applique à la connexion SQL (de mémoire cela devrais être 3 ou 5 connexions à la minute).
Normalement le CloudDB c'est plus pour être utilisé avec un VPS/Dédié (car c'est OVH qui a la gestion de l'instance du SGBD, ce qui inclus la gestion des incidents 24/7, et sans doute une SLA, à voir dans le contrat) voir une application lourde.
Dans le cadre d'un mutu c'est clairement un SQL Privé qu'il faut.
Cordialement, janus57
oui, ça c'est super sympa de nous informer
mais personne de joignable avant vente pour aiguiller le client... que c'est en dramatique
même si ma demande portait sur un sql privé, je ne sais de quel côté est venue l'erreur, on s'est retrouvé avec un cloudDb
et comme arranger un client ne parait pas une bonne pratique, et comme tout ça parait un peu cordien, on va trancher ;)
Bonjour,
pour le coup vous pouvez toujours demander le remboursement du CloudDB (erreur de produit), et soit prendre un SQL Privé soit upgrade en perf.
Cordialement, janus57
yep, mais y'a comme un malaise sur la confiance à accorder à ovh ... :/
et perso, je ne peux cautionner de telles pratiques de camelots de foire
en sachant que je me sens responsable, car cautionné le choix
dans une autre vie, au boulot, je n'avais pas eu de soucis avec ovh. mais les choses ont bien changées, on va faire avec