Erreur lors de la restauration d'une base de données à partir d'un vidage SQL
Je suis extrêmement nouveau sur MySQL et je l'exécute sur Windows. J'essaie de restaurer une base de données à partir d'un fichier de vidage dans MySQL, mais j'obtiens l'erreur suivante:
$ >mysql -u root -p -h localhost -D database -o < dump.sql
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'SQLite format 3'.
J'ai essayé $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sql mais cela m'a donné ce qui suit ERROR at line 1: Unknown command '\☻'. Il s'agit d'un fichier de vidage de 500 Mo, et lorsque je regarde son contenu à l'aide de gVIM, tout ce que je peux voir, ce sont des expressions et des données qui ne sont pas compréhensibles. De plus, lorsque j'essaie de copier le contenu du fichier à publier ici, tout ce que je peux copier est: SQLite format 3 Ce genre de semble étrange.
La référence à --binary-mode (introduit dans MySQL 5.6.3) est probablement une distraction.
Il ne semble pas que vous ayez affaire à un fichier de sortie mysqldump, là. Essayez l'utilitaire file.
Shell> file dumpfile.sql
dumpfile.sql: ASCII text
Si vous n'obtenez pas le ASCII text réponse, vous avez affaire à quelque chose qui n'est pas du tout un fichier de vidage de mysqldump, ou vous avez affaire à quelque chose qui a été compressé (avec gzip ou bzip2, par exemple), que vous aurait besoin de décompresser avant de le canaliser dans mysql.
Si tu vois SQLite 3.x database alors vous avez définitivement votre réponse ... c'est une base de données SQLite brute, pas un fichier de vidage MySQL.
En effet, les premiers octets d'une base de données SQLite sont les suivants:
53 51 4C 69 74 65 20 66 SQLite f
6F 72 6D 61 74 20 33 00 ormat 3^@
Notez que le 16e octet est ici 0x00, expliquant le ERROR: ASCII '\0' appeared in the statement... message dans ce cas. La suggestion que --binary-mode est approprié est une fausse alarme.
Utilisateurs Windows: l'utilitaire 'file' est un outil d'Unix, mais la version Windows peut être trouvée ici .
Les fenêtres
Créez vos fichiers de vidage avec cette commande
.\mysqldump [dbname] -r [filename.sql]
en utilisant:
.\mysqldumb --help
-r, --result-file = nom
Direct output to a given file. This option should be used
in systems (e.g., DOS, Windows) that use carriage-return
linefeed pairs (\r\n) to separate text lines. This option
ensures that only a single newline is used.
J'ai eu cette erreur une fois, après avoir exécuté mysqldump sur Windows PowerShell comme ceci:
mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF > db_objects.sql
Ce que j'ai fait, c'est le changer en ceci (pipe à la place de Set-Content):
mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF | Set-Content db_objects.sql
Et le problème a disparu!
Moi aussi dans PowerShell
J'ai rencontré ce problème lorsque j'utilisais PowerShell pour appeler mysqldump et > pour diriger la sortie vers un fichier. PowerShell utilisait un encodage incorrect lors de la création du fichier et j'ai été confronté à la même erreur lorsque j'ai essayé d'importer le fichier en utilisant mysql .. <exports-file.sql
J'ai trouvé que la définition du codage par défaut sur UTF8 dans la session PowerShell a résolu ce problème.
Ma résolution - PowerShell 5.1 testé:
$PSDefaultParameterValues["Out-File:Encoding"] = "utf8";
Exemple: comment je produisais l'exportation (simplifié) :
$cmdExportDB = "mysqldump --Host $Host --databases $DbName -u $UID =p$PWD > $fileName";
Invoke-Expression "& $cmdExportDB";
Remarque: découvert que cela ne fonctionne pas sur PowerShell 4.
Mon environnement de développement fonctionnait sous 5.1, mais prod est à 4.0 et mon correctif initial ne fonctionne pas dans les anciennes versions de PowerShell.
Besoin d'utiliser | Set-Content -Encoding UTF8 $fileName
Cela a déjà été suggéré par Ifedi
Quelqu'un m'a envoyé un gtar compressé. Je ne connaissais même pas trop gtar, mais c'est un autre format de compression.
$ file core_production-1432173533.sql.gtar
core_production-1432173533.sql.gtar: gzip compressed data, from Unix, last modified: Wed May 20 21:59:31 2015
Cependant, j'ai pu le décompresser comme d'habitude:
tar -zxvf core_production-1432173533.sql.gtar
$ file core_production-1432173533.sql
core_production-1432173533.sql: ASCII text, with very long lines
Et puis je pourrais faire l'importation:
mysql -u root -p -h localhost core_production < core_production-1432173533.sql
Dans mon cas, le fichier a été corrompu. La base de données a été compressée avec l'extension .bz2 mais c'était en fait un .tar.bz2.
Décomprossage à l'aide de bzip2 -dk ne génère aucune erreur et génère le fichier. Utilisation de la commande file sur les sorties de fichier bzip2 compressed data, block size = 900k donc il ne semble même pas mal de l'utiliser.
Je devais utiliser tar -xf myfile.bz2
Solution: Extraire le fichier de sauvegarde, puis restaurer ce vidage sql extrait.
Exemple :
La sauvegarde a été prise en tant que fichier dump.sql.gz et extrayez-la à l'aide de gunzip cmd comme suit,
Shell> gunzip dump.sql.gz
Et RESTORE a extrait le fichier dump.sql.
Réf: À propos du mode binaire et interactif de MySQL.
http://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html#option_mysql_binary-mode
Cela fonctionne pour moi et tout ensemble !!
Avez-vous essayé d'ouvrir dans notepad ++ (ou un autre éditeur) et de nous convertir/enregistrer en UTF-8?
Voir: https://stackoverflow.com/questions/7256049/notepad-converting-ansi-encoded-file-to-utf-8
Une autre option peut être d'utiliser textwrangle pour ouvrir et enregistrer le fichier au format UTF-8: http://www.barebones.com/products/textwrangler/