mysqldump Erreur 1045 Accès refusé malgré des mots de passe corrects, etc.
C'est un problème, j'ai la sortie suivante:
mysqldump: Erreur obtenue: 1045: Accès refusé pour l'utilisateur 'root' @ 'localhost' (à l'aide du mot de passe: YES) lors d'une tentative de connexion.
Lors de la tentative d'exportation de ma base de données avec mysqldump sous Windows XP. Le nom d'utilisateur est root, le mot de passe est correct et ne contient que des caractères alphanumériques. J'ai essayé différents cas, avec/sans guillemets, spécifiant à l'aide de -u et -p, spécifiant à l'aide de --user= et --password= et d'autres méthodes permettant de spécifier un utilisateur/mot de passe, etc. Hôte (tout est local) et même en spécifiant la base de données en utilisant --databases au lieu de simplement vide. L'erreur est toujours la même quand on utilise un mot de passe et toujours la même sauf le message "NO" quand on est sans. J'ai essayé de nombreux correctifs trouvés lors de recherches, mais sans succès. Un correctif a suggéré d'inspecter mysql.conf, mais la version de Windows ne semble pas en avoir. Les identifiants (et les paramètres de ligne de commande) fonctionnent parfaitement avec mysql.exe - ce problème ne semble affecter que mysqldump.exe.
Merci beaucoup pour votre aide.
Cela a fonctionné pour moi
mysqldump -u root -p mydbscheme > mydbscheme_dump.sql
après avoir lancé la commande, il demande un mot de passe:
Enter password:
entrer le mot de passe fera le fichier de vidage.
Si vous parvenez à vous connecter à la base de données à l'aide de mysql, mais que vous obtenez une erreur pour mysqldump, le problème peut être que vous ne disposez pas des privilèges nécessaires pour verrouiller la table.
Essayez l'option --single-transaction dans ce cas.
mysqldump -h database.example.com -u mydbuser -p mydatabase --single-transaction > /home/mylinuxuser/mydatabase.sql
L'accès refusé est probablement lié au système de fichiers Windows et non à la base de données MySQL; essayez de rediriger le fichier de sortie vers un emplacement où votre compte est autorisé à créer des fichiers.
Essayez de supprimer l’espace lorsque vous utilisez l’option -p. Cela fonctionne pour mon mysqldump OSX et Linux:
mysqldump -u user -ppassword ...
Mettez les privilèges GRANT:
GRANT ALL PRIVILEGES ON mydb.* TO 'username'@'%' IDENTIFIED BY 'password';
N'entrez pas le mot de passe avec la commande. Il suffit d'entrer,
mysqldump -u (nom d'utilisateur) -p (nom_bdd)> (fichier_sauvegarde) .sql
Ensuite, vous recevrez une invite pour entrer le mot de passe.
Faire sans -u et -p a fonctionné pour moi (quand j'étais connecté en tant que root):
mysqldump --opt mydbname > mydbname.sql
mysqldump -h nomhôte -u nomutilisateur -P port -B base de données --no-create-info -p> output.sql
Je pense que vous devriez spécifier les arguments
Vous devez insérer des barres obliques inverses dans votre mot de passe contenant des métacaractères Shell, tels que! # '"` &;
mysqldump -u (utilisateur) -p (passwd) -h (Host_ou_IP) database_to_backup> backup_file.sql
exemple:
mysqldump -u dieu -pheaven -h 10.0.10.10 comptabilité> accounting_20141209.sql
cela créerait un fichier de sauvegarde SQL pour la base de données de comptabilité sur le serveur 10.0.10.10. Parfois, votre erreur est visible lorsque localhost n'est pas dans la configuration. Désigner une adresse IP du serveur peut aider.
J'ai dû supprimer les ticks simples après l'indicateur de mot de passe:
--password=mypassword
et PAS
--password='mypassword'
Pour les utilisateurs de MAMP PRO (ou toute personne dont mysql se trouve dans un emplacement étrange), préparez-vous à spécifier le chemin complet mysql à partir des boonies, ainsi que le chemin complet du dossier local de l'utilisateur dans lequel vous voulez transférer le fichier " permission refusée erreur "..
Après avoir travaillé pour moi après 3 heures de recherche:
/Applications/MAMP/Library/bin/mysqldump -u root -proot YOUR_DB > /Users/YOUR_USER/yourdump2.sql
Je viens de le rencontrer après une nouvelle installation de MySQL 5.6.16.
Bizarrement, cela fonctionne sans le mot de passe spécifié ou marqué:
mysqldump -u root myschema mytable > dump.sql
In Past me pose le même problème après avoir copié l'instruction mysqldump à partir d'un fichier MS Word.
Mais lors de la saisie directe de la déclaration, tout a bien fonctionné.
Dans l'éditeur hexadécimal, le "-" de l'instruction qui ne fonctionnait pas était représenté par le caractère unicode e2 80 93 ( http://www.fileformat.info/info/unicode/char/2013/index.htm )
Dans Sort, saisissez mot de passe directement et vérifiez le code de copier-coller car les chaînes de code unique (ou autre) pourraient causer un problème.
J'ai eu la même erreur pour les 2 derniers jours. Essayé un tas de choses. Rien n'a fonctionné.
Mais cela a fonctionné:
Créez un autre utilisateur. Tout accorder.mysqldump -u new_user db_name > db_name.sql // pas d'erreur
J'ai eu le problème qu'il y avait des vues qui avaient un mauvais "DEFINER", qui est l'utilisateur qui a défini la vue. Le DEFINER utilisé dans la vue avait été supprimé il y a quelque temps en tant que "racine d'un poste de travail aléatoire".
Vérifiez s'il y a un problème en exécutant:
USE information_schema;
SELECT DEFINER, SECURITY_TYPE FROM views;
J'ai modifié DEFINER (en fait, définissez DEFINER sur root@localhost et la valeur SQL SECURITY sur INVOKER pour que la vue soit exécutée avec les autorisations de l'utilisateur appelant au lieu de l'utilisateur définissant, ce qui est plus logique) avec ALTER VIEW .
C'est délicat car vous devez construire l'instruction ALTER VIEW appropriée à partir de information_schema.views, alors vérifiez:
Mysql répond avec l'accès refusé avec les informations d'identification correctes lorsque le compte mysql a REQUIRE SSL activé
Le fichier ssl_ca (au minimum) devait être fourni dans les paramètres de connexion.
Des paramètres ssl supplémentaires peuvent être requis et sont documentés ici: http://dev.mysql.com/doc/refman/5.7/en/secure-connection-options.html
Également publié ici https://stackoverflow.com/a/39626932/1695680
J'ai découvert un processus Apache en cours d'exécution accédant à la MYSQL à l'origine de cette erreur. Je suggère donc de veiller à ce que tous les processus susceptibles d'interagir avec la base de données soient préalablement arrêtés.