Auteur Sujet: Dump Non Généré Ce Matin  (Lu 19896 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne alex

  • VIP
  • *****
  • Messages: 1 915
Dump Non Généré Ce Matin
« Réponse #15 le: 24 Avril 2005 à 17:23:51 »
Il y a toujours la solution de le faire avec MySQLFront (par exemple).

Hors ligne marckisscool

  • Dr TeiGnEuX
  • Expert
  • ****
  • Messages: 536
  • Dr TeiGnEuX
    • smfgratuit.fr
Dump Non Généré Ce Matin
« Réponse #16 le: 24 Avril 2005 à 17:28:54 »
Je connais pas du tout ce soft ou script

Hors ligne alex

  • VIP
  • *****
  • Messages: 1 915
Dump Non Généré Ce Matin
« Réponse #17 le: 24 Avril 2005 à 19:27:41 »
C'est un logiciel que tu installes sur ton PC et qui te permet d'accèder à ta base de données sur PHPNET de la même façon que phpMyAdmin, sauf que tu n'es plus dépendant des timeout Apache et autres joyeuseries de PHP.

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Dump Non Généré Ce Matin
« Réponse #18 le: 25 Avril 2005 à 09:36:57 »
Oui, bien-sûr...

Alors, tous à vos MySQLFront, et tant pis pour la charge appliquée au serveur.

Sans parler que PHPNET peut peut-être associer l'activité anormale de votre base de données (soumise à MySQLFront) et prendre les décisions qui s'imposent pour "soulager" le serveur. Mais je me trompe peut-être ?

MySQLFront ne remplace en rien un dump MySQL, encore faut-il que ce dernier fonctionne...

Hors ligne marckisscool

  • Dr TeiGnEuX
  • Expert
  • ****
  • Messages: 536
  • Dr TeiGnEuX
    • smfgratuit.fr
Dump Non Généré Ce Matin
« Réponse #19 le: 25 Avril 2005 à 16:57:31 »
je rejoins l'avis de yannick, et je doute sur le faite que mysqlfront puisse outre passé la configuration du serveur sql (ce qui me parait être un paradoxe) car la config du timeout ne vient pas de phpmyadmin mais de la config du serveur donc tous les logiciels de gestion de base sql normalement subissent cette configuration.
J'ai un doute que tu puisses réinjecter une base de 14Mo avec 10Mo rien que sur une table sans aucun soucis.
Et honnêtement je préfère de loin un dump surtout quand phpnet le met à disposition (car je pense que l'horaire de 5h n'est pas anodin!).
Par contre serait il possible que thibaud nous dise s'il a pu identifier le problème, car d'apres mes reponses de support, la génération se fait mais à priori personne n'a le fichier de dispo comme indiqué dans le panel.

Hors ligne alex

  • VIP
  • *****
  • Messages: 1 915
Dump Non Généré Ce Matin
« Réponse #20 le: 25 Avril 2005 à 16:59:32 »
Citer
Alors, tous à vos MySQLFront, et tant pis pour la charge appliquée au serveur.
Quelle différence entre le fait que la requête soit faite depuis un serveur de PHPNET (distant du serveur MySQL) et de chez toi (distant également du serveur MySQL). La seule variante est l'adresse IP de la personne qui se connecte... pas ce qui est reçu|exécuté par le serveur.

Citer
Sans parler que PHPNET peut peut-être associer l'activité anormale de votre base de données (soumise à MySQLFront) et prendre les décisions qui s'imposent pour "soulager" le serveur. Mais je me trompe peut-être ?
Même remarque. Faire un INSERT via PHPMyAdmin depuis un serveur Web ou depuis chez toi via un autre client ne change rien.

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Dump Non Généré Ce Matin
« Réponse #21 le: 26 Avril 2005 à 10:16:43 »
Citer
Même remarque. Faire un INSERT via PHPMyAdmin depuis un serveur Web ou depuis chez toi via un autre client ne change rien.

Bien-sûr, mais à la différence qu'une limite est fixée avec PhpMyAdmin, évitant à l'utilisateur de solliciter trop longuement le serveur. Or, cette limite disparaît avec MySQLFront...

Et PhpMyAdmin utilise php, le principe est différent du Dump.

Ci-dessous, un ancien post sur le sujet de softs comme MySQLFront :


Citer
Pour m'en être entretenu avec une personne de PHPNET par téléphone, il semble que l'emploi de tels softs n'est pas recommandé. Si vraiment c'est inévitable, préférer alors le matin, lorsque le nombre de connectés est moins important.

Tout ceci est bien relatif, et évidemment, aucun problème si le nombre de requêtes est limité, et si elles ne sont pas exécutées chaque jour.

Je m'étais lancé aveuglement dans la réalisation d'un soft local qui, par communication avec un script php distant, pourrait exécuter un nombre infini de requêtes, sans soucis de dépassement de TimeOut, puisque c'est en local que le flux est géré.

Ceci pour réaliser une petite application de backup, et, le cas échéant, de restauration.

J'ai tout arrêté lorsque j'ai pris conscience que cela pouvait être assimilé par PHPNET, et à juste titre, à un abus qui pourrait conduire à la fermeture de la base sql utilisée. Imaginez en effet un soft qui mouline des requêtes sql en boucle, pendant plusieurs minutes... et en passant par php dans mon cas.

Bien-sûr, on peut imaginer un système intelligent, qui répartirait toutes les requêtes sur une journée entière, mais cette solution ne me convenait pas.

Pour ce qui est des backups, il est préférable de passer par les dumps. Ainsi, et pour éviter que tout le monde utilise un soft pour générer lui-même ses sauvegardes, j'avais demandé à Thibaud (qui m'a assuré que c'était noté et qu'il y réfléchirait) s'il était possible de rendre plus simple et plus rapide la demande de dump. Actuellement, il faut indiquer plusieurs fois son mot de passe, et cliquer de liens en liens pour trouver la page correspondante. Je proposais la mise en place d'un lien, peut-être dès la page d'accueil, où une simple identification sufirait pour arriver sur la page de demande de dump.

Cela n'a peut-être l'air de rien, mais quand vous êtes chargés de la sauvegarde d'une dizaine de sites, c'est appréciable de ne pas passer inutilement 1 heure. De plus, cela permettrait de confier à une personne moins habituée à l'informatique cette tâche.

Maintenant, je ne veux pas m'avancer, et les spécialistes de PHPNET auront peut-être leurs remarques sur le sujet. Mais je maintiens le fait que ces softs ne devrait être utilisés qu'avec modération (tout du moins dans leur rôle de moulinette à requêtes) à moins bien sûr, que vous vous en serviez sur votre serveur dédié...

Yannick

Hors ligne rowann

  • Débutant
  • *
  • Messages: 8
Dump Non Généré Ce Matin
« Réponse #22 le: 26 Avril 2005 à 13:28:00 »
Nous somme les 26 et je n'ai toujours rien pu sauvegarder :o

le truc avec mySqlFront c'est du petit nègre pour moi :huh:  

Hors ligne alex

  • VIP
  • *****
  • Messages: 1 915
Dump Non Généré Ce Matin
« Réponse #23 le: 26 Avril 2005 à 18:48:08 »
Citer
Bien-sûr, mais à la différence qu'une limite est fixée avec PhpMyAdmin, évitant à l'utilisateur de solliciter trop longuement le serveur. Or, cette limite disparaît avec MySQLFront...
La limite est dûe à Apache et à son Timeout... pas à phpMyAdmin.

Citer
Et PhpMyAdmin utilise php, le principe est différent du Dump.
Dans les deux cas, tu exécutes les mêmes requêtes MySQL... je ne vois pas ce qui change.
« Modifié: 26 Avril 2005 à 18:49:00 par Alex »

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Dump Non Généré Ce Matin
« Réponse #24 le: 26 Avril 2005 à 22:06:30 »
Alex, Peux-tu m'éclairer alors sur le point suivant :

MySQLFront se connecte directement au serveur mySQL et lui envoie la requête demandée. Il n'y aurait d'après toi (si je comprends bien) plus la limite du timeOut, c'est ça ? Pourtant, il me semblait avoir lu que mySQLFront permettait de dialoguer avec le serveur en plusieurs fois, pour s'affranchir des limites de durée d'exécution. Ceci est faut, c'est bien ça ?

Et d'après toi, le développement d'une application communiquant avec un script php, et s'affranchissant du TimeOut par découpage des requêtes n'est pas plus préjudiciable pour le serveur qu'un soft comme mySQlFront ?

Si tel est le cas, je reprends le développement de l'application que j'avais commencée, et je la propose à qui est intéressé gratuitement. Il s'agissait, comme expliqué plus haut, de pouvoir procéder à une sauvegarde (et restauration) le plus simplement du monde (contrairement à MySQLDump, mon soft ne ferait que ça) en s'adressant à des newbies.

Hors ligne maverick78

  • VIP
  • *****
  • Messages: 2 601
    • http://www.clan-ck.com
Dump Non Généré Ce Matin
« Réponse #25 le: 26 Avril 2005 à 22:19:47 »
ce qui est le plus genant pour php a la limite serait de traiter un important volume de donnée apres et la conduirait a un timeout et depassement de memoire...
je ne vois d'ailleurs pas l'interet de passer par une appli qui utilise php, autant tout faire sur l'appli en question et c'est ce qui est fait avec mysqlfront...
ca serait comme réinventer la roue! une fois que y'en a une qu'est ronde et qui roule les autres sont similiaires!

j'ajoutes cependant que l'interet des dumps c'est que c'est fait une fois par jour a des heures de petites charges et que donc on evite les paranos qui font une sauvegarde toutes les heures d'un site sur tonton, tata et medor qui se balladent dans la creuse... Cet exemple est totalement inutile et abusé... Donc dans la mesure ou se logiciel est utilisé AVEC PARCIMONIE y'a aucun probleme
« Modifié: 26 Avril 2005 à 22:22:03 par maverick78 »
La force est dans la céréale
Clan cereal-killer : http://www.clan-ck.com

Ne te demande pas ce que ton pays peut faire pour toi mais plutôt ce que tu peux faire pour ton pays...(JF Kennedy)

Hors ligne alex

  • VIP
  • *****
  • Messages: 1 915
Dump Non Généré Ce Matin
« Réponse #26 le: 26 Avril 2005 à 22:42:20 »
Citer
MySQLFront se connecte directement au serveur mySQL et lui envoie la requête demandée. Il n'y aurait d'après toi (si je comprends bien) plus la limite du timeOut, c'est ça ? Pourtant, il me semblait avoir lu que mySQLFront permettait de dialoguer avec le serveur en plusieurs fois, pour s'affranchir des limites de durée d'exécution. Ceci est faut, c'est bien ça ?
Je viens de faire un test. J'ai fait un dump. Du début à la fin du dump, c'était le même processus MySQL qui s'exécutait. J'en déduis donc que le dialogue se fait en une fois.

Citer
Et d'après toi, le développement d'une application communiquant avec un script php, et s'affranchissant du TimeOut par découpage des requêtes n'est pas plus préjudiciable pour le serveur qu'un soft comme mySQlFront ?
Difficile de passer outre le timeout. Mais si c'était possible, à mon avis, il n'y aurait pas de différence. Le serveur émettant la requête serait juste plus chargé que par un dump classique (via mysqldump comme je l'ai fait par exemple) car il chargerait php en plus.

Hors ligne Gemma

  • Débutant
  • *
  • Messages: 31
Dump Non Généré Ce Matin
« Réponse #27 le: 27 Avril 2005 à 06:33:31 »
sans vouloir tomber dans la parano.... mais j'ai toujours fais une save par jour de ma bd et là depuis que nous avons migré chez phpnet ça va faire 7 jours que je n'en est plus :unsure: ....

les dumps sont peut être générés, mais désolée, je n'en retrouve aucune trace à la racine de mon ftp, donc doit bien y avoir un prob quelque part....

Mais le sevrage là est quelque peu brutal !!!!! je veux mes dumps :D  :lol: naaa sérieusement, quand je vous lis plus haut, j'en ai les yeux qui s'écarquillent, la newbie que je suis n'y a rien capté mmmdddrrr, mais bon je fais confiance à l'équipe :rolleyes: Rassurez-moi, je suis la seule à avoir ce problème ? :blink:
Quelqu'un a des news ?



 

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Dump Non Généré Ce Matin
« Réponse #28 le: 27 Avril 2005 à 09:41:31 »
Citer
je ne vois d'ailleurs pas l'interet de passer par une appli qui utilise php, autant tout faire sur l'appli en question et c'est ce qui est fait avec mysqlfront...
ca serait comme réinventer la roue! une fois que y'en a une qu'est ronde et qui roule les autres sont similiaires!

L'intérêt pour moi est évident : c'est la rapidité et la simplicité qu'il y a à developper une telle application.

Sans php, il faut gérer directement la connexion au serveur MySQL, ce qui suppose de connaître l'ensemble du protocole utilisé pour dialoguer, et gérer tout cela, ce qui est nettement plus complexe. Je recherche cependant de la doc côté MySQL pour éventuellement arriver à mes fins.

Citer
Difficile de passer outre le timeout. Mais si c'était possible, à mon avis, il n'y aurait pas de différence. Le serveur émettant la requête serait juste plus chargé que par un dump classique (via mysqldump comme je l'ai fait par exemple) car il chargerait php en plus.

Non, c'est simple, il suffit de confier à l'application locale la découpe des requêtes, de manière transparente. En jouant par exemple sur le LIMIT des requêtes.

L'intérêt par rapport à mySqlFront ? Il est évident : proposer à des newbies un soft ultra simple, que ne fait -que- uploader ou downloader le contenu de tables MySQL, point. Le tout avec une interface hyper ergonomique, ...

Et ce, sans se soucier des dumps qui ne fonctionnent plus dur Phpnet, qui semble considérer qu'il s'agit là d'une fonction facultative. Pourtant, et comme Maverick le rappel très bien, le Dump avait l'avantage d'éviter à tout le monde de solliciter le serveur à des horaires critiques.
 

Hors ligne Yannick

  • Habitué
  • **
  • Messages: 204
Dump Non Généré Ce Matin
« Réponse #29 le: 27 Avril 2005 à 09:42:53 »
Citer
Alex : Je viens de faire un test. J'ai fait un dump. Du début à la fin du dump, c'était le même processus MySQL qui s'exécutait. J'en déduis donc que le dialogue se fait en une fois.

La table "dumpée" faisait quelle taille ?
« Modifié: 27 Avril 2005 à 09:43:19 par Yannick »