Version Windows : 64bits V 8.1 version Wamp : 64bits V2.4 MySQL : 5.6.12 PHP : 5.4.12 PhpMyAdmin : 4.0.4 J'utilise également Nod32 et Comodo mais sans problème là aussi depuis des années.
J'ai repris tout mon texte depuis le début car il devait y avoir 20 lignes d'intro pour rien.
En résumé je ne suis par technicien du tout de ce logiciel que j'utilise pourtant depuis des années (mais sans problème). Aujourd'hui ce n'est plus pareil aussi je viens vous solliciter. Ce matin j'ai eu un blocage de l'ordinateur (curseur de la souris qui tournait en rond sans arret). Au bout d'un 1/4 d'heure, seul un reset en est venu à bout. Au redémarrage tout se passe bien, je lance Firefox normalement ainsi que la messagerie. Ensuite je lance Wamp mais contrairement à l'habitude l'icone en bas à droite reste orange et n'ai plus aucun accès. Je précise qu'au moment du plantage Wamp était en service. Je mentionne que depuis des années je me sers de Wamp avec un répertoire WWW déplacé dans f:/
Après une bonne heure de lecture et d'essais infructueux, je décide de désinstaller Wamp puis de le réinstaller. A la relance cette fois l'icone est bien verte mais je suis sur c:\www (normal !!) Après lecture de certains posts ici même j'édite mon fichier httpd.conf et lui apporte les modifications suivantes DocumentRoot "f:/" puis <Directory "f:/">. Je sauvegarde, je ferme Wamp puis le relance, le voyant est bien vert mais toujours impossible de me connecter à la base de données.
Je me rappelle alors qu'il faut également activer dans Apache le rewrite_module ce que je fais. Je ferme Wamp, le relance, c'est vert et cette fois j'accède bien au f:\ Mais lorsque je clique sur un répertoire j'ai à nouveau le message Erreur lors de la connexion à la base de données.
Et pour être complet si après avoir cliqué sur l'icône en bas à droite, au 1er essai après avoir sélectionné phpmyadmin, j'ai eu l'invite de l'identifiant qui était root par défaut et dans mot de passe j'ai saisi celui que j'utilise depuis longtemps mais là aussi message d'erreur. J'ai donc refait une tentative de connexion mais cette fois sans mot de passe et là je suis bien arrivé sur le tableau de bord de phpmyadmin mais sans aucun dossier dans la colonne de gauche (sinon les 4 qui doivent être là par défaut). Je ne sais pas si ça a son importance mais les dossiers concernent surtout des sites WordPress.
Je pense ne plus être bien loin de la solution mais là je dois avouer que je bloque.
Bonjour, Si votre base de données était dans wamp/bin/mysql/mysql5.x.y/data/ sous forme de dossier du nom de votre base de données et que vous avez désinstallé Wampserver puis supprimé le dossier wamp, votre base de données est perdue.
Si votre base de données est, elle aussi sur f:, le plus simple et le plus, pratique est de mettre une jonction de répertoire dans le dossier wamp/bin/mysql/mysql5.6.12/data/, jonction qui doit pointer sur le dossier de votre base de données sur f:. Pour plus de détails sur les jonctions, voir [forum.wampserver.com]
D'autre part, après l'installation de Wampserver 2.4 et pour éviter des éventuels problèmes futurs, il serait bien d'effectuer : Wampserver 2.4 - À faire après installation Ça vous expliquera aussi comment installer la dernière version de PhpMyAdm et comment ajouter des utilisateurs et des mots de passe.
Je crois voir de quoi vous voulez parler quand vous dites :
"Si votre base de données était dans wamp/bin/mysql/mysql5.x.y/data/ sous forme de dossier du nom de votre base de données et que vous avez désinstallé Wampserver puis supprimé le dossier wamp, votre base de données est perdue."
Heureusement (enfin j'espère) que j'ai fait une sauvegarde complète du répertoire /wamp sur une autre partition et qu'un copier/coller de ces dossiers sera réparateur.
Je tente la chose dès que j'arrive chez moi et vous tiens au courant.
Je croise les doigts et vous remercie encore pour cette intervention express.
Pour les 2 liens mis dans votre message je suis déjà allé voir bien avant de poster et je dois avouer que là ça va être une autre paire de manches (ça sent le mal de tronche à plein nez mais bon si ça améliore les choses faudra bien s'y pencher dessus mais en faisant attention )
pastazere a écrit: ------------------------------------------------------- > Heureusement (enfin j'espère) que j'ai fait une sauvegarde complète du répertoire /wamp sur une > autre partition et qu'un copier/coller de ces dossiers sera réparateur. Ne « coller » QUE le dossier de (ou les) dossiers de vos bases de données. Ne PAS « coller » les dossiers mysql ou performance_data ou autres qui sont les bases de données de MySQL lui-même et qui ne sont pas forcément compatibles avec la nouvelle version de MySQL.
Otomatic a écrit: ---------------------------------------- Ne « coller » QUE le dossier de (ou les) dossiers de vos bases de données. Ne PAS « coller » les dossiers mysql ou performance_data ou autres qui sont les bases de données de MySQL lui-même et qui ne sont pas forcément compatibles avec la nouvelle version de MySQL.
Aie trop tard mais bon lisez la suite.
---------------------------------------- Alors ici aussi j'ai repris tout mon texte car j'ai eu du renfort (le fiston).
Mais juste pour dire que j'avais donc remis TOUS les fichiers et répertoires se trouvant dans data mais ça n'a pas marché car au redémarrage de Wamp l'icône restait de nouveau bloquée à l'orange (peut être à cause de ce que vous dites ci-dessus). Et donc là j'ai eu un grand moment de solitude.... jusqu'à ce que le fiston arrive.
Je lui explique mon problème et il se met devant l'ordi.
Je ne saurais vous décrire exactement toutes les manips qu'il a effectuées (ça va trop vite) mais d'après ce que j'ai compris via l'icône de Wamp il est allé voir une sorte de journal qui lui indiquait quel répertoire posait problème (et effectivement c'était bien celui qu'il m'indiquait qui était en cours lors du plantage). Après avoir fait une sauvegarde de ce répertoire il l'a supprimé puis fait d'autres manips que je ne saurais décrire mais déjà il y avait du mieux car l'icône passait au vert.
Pour vérifier il a remis le répertoire précédemment supprimé et là rebelote ça ne marchait plus. Donc le problème avait bien pour origine ce répertoire.
Ensuite après une recherche sur Google, ça je m'en rappelle bien il a ouvert le fichier my.ini de mysql et a ajouté une ligne avec : innodb_force_recovery = 4
Et là par la suite tout est rentré dans l'ordre.
La connexion au phpmyadmin avec mon mot de passe a bien donné accès au tableau de bord avec toutes ses bases.
Voilà j'imagine bien que ces explications ne sont pas très académiques mais je tenais à vous faire ce retour tout en pensant que vous pourriez décrypter ce petit charabia.
Mon cher Otomatic encore une fois je vous remercie pour votre aide rapide et constante.
Bonne soirée.
PS :Bon ça marche mais j'espère que mon copier/coller du début ne sera pas préjudiciable par la suite.
Grâce au « fiston », ça fonctionne et c'est tant mieux ! Néanmoins, je répète, une fois de plus, que LA SEULE SAUVEGARDE FIABLE des bases de données, c'est un export en fichier SQL avec les options qui vont bien.
Il aura fallu que je me trouve au bord du gouffre pour me décider une bonne fois pour toute à réaliser les sauvegardes qui s'imposent (fichiers+Bdd). Aussi depuis hier, je m'informe en lisant certains sujets sur le forum même si je dois avouer ne pas tout saisir.
Pour faire suite à votre dernière réponse, j'aurais une question ou plutôt un demande de confirmation car quand vous dites "LA SEULE SAUVEGARDE FIABLE des bases de données, c'est un export en fichier SQL avec les options qui vont bien."
OK bien reçu mais "par les options qui vont bien", feriez-vous référence à cette façon de faire [fluxbb.fr] (lien venant du forum il me semble).
J'abuse mais une dernière question qui j'espère n'est pas tabou ici car les recherches effectuées ne donnent aucun résultat. En effet n'étant plus un fan de la ligne de commande (et pourtant sous Ms-Dos je me débrouillais) est-il pensable de faire ces sauvegardes à l'aide d'un script graphique du style [sypex.net] ou alors [www.mysqldumper.net]
pastazere a écrit: ------------------------------------------------------- > OK bien reçu mais "par les options qui vont bien", feriez-vous référence à cette façon de faire [fluxbb.fr] Oui. Il va - quand même - falloir que je vérifie si les options sont toujours valables avec les dernières versions de PhpMyAdmin.
> est-il pensable de faire ces sauvegardes à l'aide d'un script graphique du style [sypex.net] ou alors [www.mysqldumper.net] J'utilise beaucoup et presque exclusivement MysqlDumper qui génére des fichiers - certes compressés gz - mais au format SQL et qui, une fois décompressés peuvent être utilisés comme n'importe quel fichier SQL. Remarque : MysqlDumper figure dans ma signature
Mais quel est l'intérêt d'utiliser des outils graphiques pour faire un travail que l'on peut faire par soi-même ?
Une sauvegarde de la ou des bases de données se fait, comme le dit si bien OTOMATIC, par un export. C'est ni plus ni moins qu'une fonctionnalité de PhpMyAdmin. Encore fait-il savoir l'utiliser correctement.
Quel est l’intérêt d'ajouter une couche de logiciels à ceux déjà existant et qui vont faire le même travail ? J'utilise, au travers des batchs MSDOS, tout ce dont j'ai besoin pour maintenir mes bases de données et mon paramétrage en état de marche !
La ligne de commande n'est pas quelque chose d’archaïque ou de vieillot ! C'est juste la fonctionnalité de base qui est reprise par les logiciels dits graphiques. Que vous le fassiez en ligne de commande ou au travers d'un logiciel graphique, c'est exactement la même chose ! La seule différence c'est que le logiciel graphique est un tutoriel qui vous explique comment procéder et vous conseil sur le paramétrage à faire. A l'inverse, la ligne de commande ne contrôle pas si ce que vous avez tapé est correcte ou pas. Je dirais que c'est à l'état brut, sans fioriture ni d'aide, juste l'essentiel.
En ce qui concerne les sauvegardes, voila ce que je fais :
1) sauvegarde des trois dernières versions des quatre utilitaires suivants : --> apache --> php --> mysql --> phpmysql Je parle bien sûr de la version compressé.
2) utilitaire en batch pour les comptes utilisateurs et mots de passe. Je l'utilise à chaque changement de version de mysql.
3) utilitaire en batch du paramétrage de mysql. Il s'agit surtout des langues et autres variables systèmes.
4) utilitaire en batch de réinstallation des bases de données. Je peux très bien le faire à la main en utilisant la fonction 'import' de phpmysql, mais j'ai préféré l'automatisé. Pour procéder ainsi, je sauvegarde mes quatre bases de données par un 'export', donc à la main.
5) utilitaire de vérification de la réinstallation. Il s'agit juste de visualiser le contenu des tables représentatives de ce que j'ai réinstallé au préalable.
Ici, je ne parle que de la maintenance de WampServer sur mon ordinateur et en aucune façon des sites chez les hébergeurs. Pour bien maintenir votre WampServer et vos sites, vous devez créer des sauvegardes mais aussi des utilitaires qui vous permettent de les configurer et de les réinstaller sans vous poser des questions.
Si cela vous intéresse, on peut en parler hors de ce forum. Mon adresse email est : artemus24@live.fr
> Une sauvegarde de la ou des bases de données se fait, comme le dit si bien OTOMATIC, par un export. > C'est ni plus ni moins qu'une fonctionnalité de PhpMyAdmin. > Encore fait-il savoir l'utiliser correctement. >Quel est l’intérêt d'ajouter une couche de logiciels à ceux déjà existant et qui vont faire le même travail ?
MysqlDumper, ce sont les fonctions Exporter/Importer de PhpMyAdmin, mais en beaucoup plus puissant et fiable. Cette application réussit des exports/imports là où PhpMyAdmin échoue sur des serveurs lents ou très chargés.
Je ne comprends pas comment tu peux avoir des problèmes sur des serveurs lents ou surchargé ? De plus, si une table est gigantesque, tu peux la découper en plusieurs morceaux.
On ne s'improvise pas administrateur parce que l'on à accès à phpmyadmin. Il y a un travail de préparation, qui nécessite de créer des scripts. Il faut mieux avoir 10 sauvegardes de 1 giga octets que 1 seul de 10 giga octets.
Et que fais-tu en cas de plantage, tu recommences depuis le début ? Non, ce n'est pas la solution. Il faut apprendre à gérer les commit et rollback. Ainsi que les points de reprises.
Donc non, ce n'est pas une question d'outils mais de connaissances du fonctionnement de ton SGBD !
pastazere a dit qu'il n'y connaissait pas grand chose et tu viens parler de "commit", "roolback", "scripts", "points de reprise", "batchs MSDOS" (1), etc. AMHA, pour ce qu'il demande, MysqlDumper est une très bonne solution. Il faut rester dans les limites de ce que demande (et sait) la personne qui vient chercher de l'aide, sinon, elle sera très vite dépassée.
(1) Il y a belle lurette qu'il n'y a plus de MSDOS dans Windows
Je pense que tu ne lui rends pas servir en procédant ainsi.
Si je peux me permettre de faire une comparaison, tu lui conseilles de lire, par exemple, l'Encyclopédie Universalis ce qui est une bonne chose en soi, mais à une personne qui ne sait pas lire !
Tant que tu ne possèdes pas les bases, l'outil ne sert à rien. Il continuera à faire les mêmes erreurs sans bien comprendre pourquoi. Et comme la plupart des intervenants, ils viennent dire que cela ne fonctionne pas, en criant "au secours" !
Je me suis même proposé de l'aider, mais actuellement je n'ai pas reçu d'email de sa part. Je dois en conclure que cela ne l'intéresse pas. Sans trop me tromper, il n'est pas dans une démarche d'apprentissage ou de perfectionnement, mais d'un résultat immédiat, même si cela fonctionne sur trois pattes.
P.S. quand je parle de MSDOS, je ne parle pas du système d'exploitation qui équipait les premières versions de Windows, mais des commandes que l'on tape avec l'invite de commande. Même le terme de batch n'est pas correcte car c'est plutôt de l'interactif mono-tache et mono-utilisateur, plutôt que tu traitement par lots multi-tache et multi-utilisateurs. Je devrais plutôt parler de script pour l'invite de commande.