At shell command prompt (backup and restore db):
mysqldump -u"username" -p"password" --host="127.0.0.1" --port=3306 --routines --triggers --no-data --add-locks my_db_schema > "C:\dumpfile.sql"
mysqladmin -u"username" -p"password" --host="127.0.0.1" --port=3306 --force DROP my_db_schema
mysqladmin -u"username" -p"password" --host="127.0.0.1" --port=3306 CREATE my_db_schema
mysql -u"username" -p"password" --host="127.0.0.1" --port=3306 --force my_db_schema < "C:\dumpfile.sql"
On the last command, I get an error:
ERROR 1115 (42000) at line xxxx: Unknown character set: 'latin1BEGIN'
Line xxxx in C:\dumpfile.sql (first stored procedure in file):
delimiter varchar(255)) RETURNS text CHARSET latin1
BEGIN
How can I fix that error?
I'm using Windows and MariaDB if that makes any difference
If I add an extra carriage return between latin1 and BEGIN the script runs fine. That seems to be the only problematic line in the whole script. Still looking for a solution to this issue.
I'm guessing the dump file is in unix text format (\n only), and you're importing it in Windoze, which expects \r\n.
\r-only for a line ending is Mac-style, if I remember right.
Related
I have a large .sql file and when I try to upload it I get an error like this
mysql -u root -p --default-character-set=utf8 db_name < file.sql
The error i got;
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'.
I also tried different installation attempts but without success.
mysql -hlocalhost -r -uroot -p --binary-mode -o db_name < file.sql
mysqldump -p -u root db_name --hex-blob > file.sql
I am trying to create a dump file with mysqldump.exe
I tried it like this:
C:\Program Files\MySQL\MySQL Workbench 8.0 CE>mysqldump --column-statistics=0 --single-transaction -p3306 -h10.10.10.10 -u username -p dbName > backup.sql
mysqldump: [Warning] Using a password on the command line interface can be insecure.
Enter password: ****************
mysqldump: Couldn't execute 'SHOW CREATE TABLE `PLZ_Stra├ƒen`': Table 'dbName.PLZ_Stra├â┼©en' doesn't exist (1146)
Because of the special character, the dump process fails, How can I solve this problem?
try to specify the character set with --default-character-set=utf8mb4 option when using mysqldump
mysqldump --default-character-set=utf8mb4 --column-statistics=0 --single-transaction -p3306 -h10.10.10.10 -u username -p dbName > backup.sql
or you can set any character set in mysql using that
ß, when interpreted as CHARACTER SET cp850 is hex c39f.
ß, which is presumably the character you wanted, when interpreted as CHARACTER SET utf8 (or utf8mb4) is hex c39f.
One hand is talking cp850; the other hand is utf8. Be consistent.
You seem to be using the Windows cmd. The command chcp 65001 provides utf8, but it needs a special charset installed.
On Ubuntu 14.04 terminal using bash, i'm able to dump from master mysql db to the slave:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 --user=myuser --password=[password] --host=127.0.0.1 mydb | mysql --max_allowed_packet=128M -h 192.168.1.110 -u myuser -p[password] otherdb
But I simultaneously want to redirect the mysqldump output to head -30 > /tmp/pointintime.log so I can get the point in time info:
--
-- Position to start replication or point-in-time recovery from
--
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.049868', MASTER_LOG_POS=107;
How to do this? I tried using tee but this results in sql syntax errors at the slave import end (as though its breaking up the output and not sending full statements):
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 --user=myuser --password=[password] --host=127.0.0.1 mydb | tee >(head -30 >/tmp/pointintime.log) | mysql --max_allowed_packet=128M -h 192.168.1.110 -u myuser -p[password] otherdb
How to mysqldump import to slave mysql db and simultaneously retrieve the head -30 of the dump? I dont want to dump to a file first because the db is huge, its more efficient to pipe over the network.
I also tried using multiple tee redirects but had the same syntax error:
mysqldump --skip-lock-tables --single-transaction --flush-logs --hex-blob --master-data=2 --user=myuser --password=[password] --host=127.0.0.1 mydb | tee >(mysql --max_allowed_packet=128M -h 192.168.1.110 -u myuser -p[password] otherdb) >(head -30 >/tmp/pointintime.log)
ERROR 1064 (42000) at line 47: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near..
You can't do this with tee and head because head closes its input handle once it has output the requested number of lines, breaking the pipe. Here's what you should see with the command you've written.
mysqldump: Got errno 32 on write
Error 32 is "Broken pipe."
The other error -- I suspect -- is because the broken pipe causes the input handle to mysql to be closed, with a partial line of output already written, and the end of file it receives when that happens is interpreted as a premature end of statement.
You need something in the middle that will not break the pipe. Suggestion: the swiss army chainsaw... Perl.
Replace this:
| tee >(head -30 >/tmp/pointintime.log) |
With this:
| perl -p -e 'print STDERR $_ unless $. > 30' 2>/tmp/pointintime.log |
The -e switch tells Perl that instead of loading a Perl script from a file, that the script is inside the quoted string that follows. The -p switch causes this little one-line "program" to be run for each line of STDIN, after which each input line will be printed to STDOUT, with the input line transiently appearing in the variable $_ as each line passes through, and the variable $. indicating the running line counter. Of course STDERR is the second output stream, which we catch with 2> and redirect to your log file, and once $. > 30 is true, no more lines are written to your log... but they're all written to the output.
Simple as that.
Piping mysqldump through Perl in this way is completely safe -- it will not manipulate the data in any way, it will write it out exactly as it came in. I routinely do this when I need to modify a backup stream on the fly.
I am using MySQL 5.5.29, utf8mb4 charset, there is a table user containing a field nickname with value hex F09F988EF09F988E that translates to the emojis 😎😎.
Now open MySQL console, and execute:
set names utf8mb4;
select nickname, hex(nickname) from user;
nickname | hex(nickname)
---------+-----------------
😎😎 | F09F988EF09F988E
And then execute:
mysqldump --default-character-set=utf8 -utest -ptest test_dev user > user.sql
Check the user.sql and find the nickname display ?? which hex string is 3f
So, how can mysqldump with UTF8 export the right emojis string?
btw, the database charset envionments configured as follow:
show variables like 'character_set_%':
'character_set_client', 'utf8mb4'
'character_set_connection', 'utf8mb4'
'character_set_database', 'utf8mb4'
'character_set_filesystem', 'binary'
'character_set_results', 'utf8mb4'
'character_set_server', 'utf8mb4'
'character_set_system', 'utf8'
'character_sets_dir', '/data/mysql/share/charsets/'
Thanks Danack!
Thru specifying utf8mb4 charset and upgrading mysqldump version to 5.5.3+, mysqldump & mysql work well for 4 bytes emojis.
[tomcat#localhost ~]$ mysqldump --default-character-set=utf8mb4 -utest -ptest test_dev user > user.sql
If it shows an error like:
mysqldump: Character set 'utf8mb4' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file
check your mysqldump version (mysqldump --version)
[tomcat#localhost ~]$ mysqldump --version
mysqldump Ver 10.11 Distrib 5.0.95, for redhat-linux-gnu (x86_64)
It works after upgrading mysqldump to 5.5.33.
[tomcat#localhost ~]$ mysqldump --version
mysqldump Ver 10.13 Distrib 5.5.33, for Linux (x86_64)
It's true that you need to use mysqldump --default-character-set=utf8mb4 (notice the --default-character-set option) when exporting.
But then importing is still super tricky. I tried so many different approaches and had no success.
Finally, I discovered that you need to create an importer.sql file like this:
USE my_example_db_name;
# Select the right charset
SET NAMES 'utf8mb4';
# Import from SQL file
SOURCE /somewhere/dump.sql;
# Disconnect from SQL server
EXIT
Then, to import, run this:
mysql -u my_user my_example_db_name < /somewhere/importer.sql
Thank you to https://korobochkin.wordpress.com/2017/02/25/import-and-export-wordpress-database-with-utf8mb4-charset/
Was struggling with this for a while as well. The other solutions in this thread still caused dump.sql to still have multiple wrong characters for emojis.
Turns out, using > is not a safe way of exporting (at least not on my machine, Windows 10). Using -r dump.sql instead of > dump.sql did the trick.
This command exports all the tables of the database:
mysqldump --default-character-set=utf8mb4 -h [host] -u [username] -p [database_name] --set-gtid-purged=OFF --port=3306 --protocol=tcp --skip-triggers -r dump.sql
Then for importing, first run this command:
mysql -h [host_name] -u [username] -p [database_name] --binary-mode -o
And then, when in mysql mode, type the following:
USE database_name;
SET NAMES 'utf8mb4';
SOURCE /dump.sql;
EXIT
Hope this helps others that had the same issue!
when I run below statement, mysql is complaining having error.
mysqldump --triggers --routines -u root -p mydb > mydb_20120924.dmp;
mysql version: 5.1.34
You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near 'mysqldump --triggers --routines -u root -p mydb > mydb_20120924.dmp' at line 1
It looks like you are trying to run the mysqldump command from inside the mysql command line interpreter.
Does the prompt for the mysqldump command say 'mysql> '? Then you are running the mysql command line interpreter. It should be used - indeed, it can only be used - for running mysql commands.
mysqldump is a separate command and must be run from the shell.
Quit mysql by typing "exit" - you will see a shell prompt. Then the mysqldump command will work.
If you have a database called "mydb" this should work. You could try using --database specifically:
mysqldump --triggers --routines -u root -p --database mydb >
mydb_20120924.dmp;