I need to dump data with mysqldump and have it use ANSI quoting, so
"tablename"
instead of
`tablename`
quoting.
I can't change the server settings and --compatible options are not working, nor is --ansi a valid option to mysqldump.
How do I set this for the mysqldump session?
I don't want to pipe through sed.
https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_compatible says:
--compatible=name
Produce output that is more compatible with other database systems or with older MySQL servers. The only permitted value for this option is ansi, which has the same meaning as the corresponding option for setting the server SQL mode.
(emphasis mine)
I just tested this on MySQL 8.0.32 and it works. It does not produce an error, it changes the identifier delimiter to " for compatibility with non-MySQL instances.
That's only part of the compatibility you need, though. There are many other statements in the dump output that will not work in other brands of RDBMS.
Related
I need to convert a mysql database to postgres. Just for testing, I installed a local mysql database and created a simple test database with one table. Now I wan't to make a SQL dump with the option --compatible=postgresql:
mysqldump test --compatible=postgresql -uroot > ~/Documents/testdump.sql
But I always get the following error message:
Invalid mode to --compatible: postgresql
I'm using OSX and installed mysql using homebrew
the mysql version is: stable 8.0.12 (bottled)
I also tried it with the Docker-container and the newest version 8.0.12 but it also gives me the same error message. I need the compatible mode so I can use the dump with an python script to convert it to postgresql.
Edit:
I downgraded to 5.7 and it's now working - I'm still wondering why it's not working with the new version.
If you check the documentation for MySQL 8, you will find this:
--compatible=name
Produce output that is more compatible with other database systems or
with older MySQL servers. The only permitted value for this option
is ansi, which has the same meaning as the corresponding option for
setting the server SQL mode.
So setting the value of name to postgresql won't work.
https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html#option_mysqldump_compatible
For 5.7 the following values are possible, which is the reason that a downgrade enabled you to use the desired value:
--compatible=name
Produce output that is more compatible with other database systems or
with older MySQL servers. The value of name can be ansi, mysql323,
mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options,
no_table_options, or no_field_options.
I am using MySQL Workbench 8.0. I am trying to dump test data to DB including all the tables, stored procedures and views with data.
When I try to import it's says import finished with one error and the error is
Variable 'sql_mode' can't be set to the value of 'NO_AUTO_CREATE_USER'
Operation failed with exitcode 1
Also after importing if I check the database, only tables have come but there are no stored procedures at all.
How would one fix this?
I recently had this problem as well after exporting my database from MySQL Workbench 6.1 CE and then trying to import it into a newer version of MySQL WorkBench 8.0.11. Each were installed with the community server installer msi.
After doing some searching I came across this bug report on the MySQL website:
Restaure dump created with 5.7.22 on 8.0.11
What fix worked for me was to go through my dump file manually and remove the statements:
'NO_AUTO_CREATE_USER' which are located above each of your routine dumps within the dump file.
Statement to remove image example
After I did this I received the error
ERROR 1418 (HY000) at line 318: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you might want to use the less safe log_bin_trust_function_creators variable)
But after referring to this answered question:
This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled
and simply entering:
SET GLOBAL log_bin_trust_function_creators = 1;
in the
MySQL command line client solved that issue and finally allowed me to properly import my database with all the dumped tables, data, routines, and functions.
Hopefully this saves others some time.
Best way to find & replace.
Find NO_AUTO_CREATE_USER and replace it with nothing without opening the file.
Linux sed utility is the best option for that if the *.sql file is large to open.
sed -i 's/FIND_TEXT/REPLACE_TEXT/' file.sql
sed -i 's/NO_AUTO_CREATE_USER//' file.sql
-i for --in-place[=SUFFIX]
-s for --separate
I too faced the similar problem. Just removed that words NO_AUTO_CREATE_USER from the import script by using find & replace option in mysql workbench and it executed fine.
Bugs Fixed
Important Change: Importing a dump from a MySQL 5.7 server to a server running MySQL 8.0 often failed with ER_WRONG_VALUE_FOR_VAR when an SQL mode not supported by the 8.0 server was used. This could happen frequently due to the fact that NO_AUTO_CREATE_USER is enabled by default in MySQL 5.7 but not supported in MySQL 8.0.
The behavior of the server in such circumstances now depends on the setting of the pseudo_slave_mode system variable. If this is false, the server rejects the mode setting with ER_UNSUPPORTED_SQL_MODE. If pseudo_slave_mode is true, the server ignores the unsupported mode and gives a warning. Note that mysqlbinlog sets pseudo_slave_mode to true prior to executing any SQL. (Bug #90337, Bug #27828236)
Source: MySQL release notes.
Verifying this:
I connected to MySQL then with my schema selected by default I ran the following commands in a Workbench SQL tab:
SET pseudo_slave_mode = true;
SET ##SESSION.pseudo_slave_mode = true;
To make sure it worked I verified it with other command in other tab:
SHOW VARIABLES;
It showed to me the list of variables and I filtered it typing ps to find the pseudo_slave_mode variable
Yup pseudo_slave_mode was ON now (when previously was OFF)
Then I ran the .sql and it showed me the NO_AUTO_CREATE_USER error again but this time it created everything that was required in the .sql file
Then I dumped the schema, to another sql file to verify it:
mysqldump -u root -p --no-data --routines my_database > schema.sql
Everything was ok. This time it dumped it with a modified sql_mode
I hope this can be helpful for you.
I found a workaround, if not the solution. Use Linux to get the sed utility, and run the two sed commands as mentioned in my previous comment. Also, I needed to use the mysqldump option: --set-gtid-purged=OFF
From the command line, the --force option will cause mysql to continue processing the dump and ignore the 'NO_AUTO_CREATE_USER' (as well as any other) error.
You can turn on this behavior in MySQL Workbench as well. See Continue SQL query even on errors in MySQL workbench.
Dillon's answer works for me, thanks
MAC OS:
sed -i old 's/\DEFINER=[^]*#[^]*//g' file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql
LINUX:
sed 's/\sDEFINER=[^]*#[^]*//g' -i file_name.sql
sed 's/,NO_AUTO_CREATE_USER//g' -i file_name.sql
Mysql:
mysql> SET GLOBAL log_bin_trust_function_creators = 1;
Worked for me when I downgraded the mysql, to more compatible version.
Probably would've also work to update the driver.
I just ran into the same exact problem while restoring a 5.7 version dump using Workbench 8.0 in Windows environment.
I combined everyone's recommendations above as follows:
Used Notepad++ and to universally remove the "NO_AUTO_CREATE_USER" option from the dump file.
SET pseudo_slave_mode = true;
SET ##SESSION.pseudo_slave_mode = true;
SET GLOBAL log_bin_trust_function_creators = 1;
That worked (Thank you), however - some important notes:
usage of special characters (i.e. double-quotes, back-slashes, etc.), if not properly formatted can cause the debugger to flag it, thus aborting the import.
deprecated commands, such as "reset query cache" will also cause the debugger to throw an exception.
Any of the above is typically exhibited as: ERROR 1064 (42000) at line : 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 <...>
I handled each condition by copying the individual problematic stored procedure from the dump file into a NEW stored procedure in Workbench. The native debugger immediately highlighted the offending line(s)/statement(s).
After several volleys of the above, I was able to finally import the entire .sql dump file cleanly.
Is it possible to use a newer version of mysqldump to export data that is compatible with older versions of mysql?
Specifically, I am using mysqldump to export data from version 5.5.44 to 5.1.55.
I was getting the error
Unknown collation: 'utf8mb4_unicode_ci'
when trying to import data from the 5.5.44 to the 5.1.55 server
I know in the manual, it says that the compatible option can be used with one of the following names: ansi, mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, or no_field_options, but I'm not sure if that is what I want in this situation.
If I really wanted a sure-fire solution I would use mysql40 - 5.1 can definitely load a dump from 4.0, MySQL philosophy is backwards compatibility to a fault. However, it is quite likely to work as is - dumps have not changed very much between 5.1 and 5.5.
I run a MySQL server off my computer and have been playing around with it and PHP to access stored data. I find it works a lot better than Excel and is more cross platform/portable with export to HTML tables.
I recently was reading on how to secure MySQL and came across this article:
http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips
which has a section suggesting to disable the data infile in the mysql.conf file using:
set-variable=local-infile=0
However, after doing this, I was unable to get MySQLD to start at all. I had to remove this line to get SQL running again. Using MySQL 5.5.35-0ubuntu0.13.10.2 (Ubuntu)
Anyone know another way to patch this vulnerability without breaking MySQL?
http://dev.mysql.com/doc/refman/5.0/en/program-variables.html says:
Before MySQL 4.0.2, the only syntax for setting program variables was --set-variable=option=value (or set-variable=option=value in option files). ... This syntax still is recognized, but is now deprecated and is removed in MySQL 5.5.
In other words, in MySQL 5.5 and later, don't use set-variable. Just set the variable:
local-infile=0
I'm using derby for development in eclipse. Is it possible to dump a table from MySQL and use it for derby in some way? I know that ddl & dml are different for both dbms but I'm looking for a way, other than dump/export, that would be appropriate.
There are two options I can find; if I understand your question correctly, I think at least one will cover what you are looking for.
If your focus is the data (or a subset thereof) from a single table, use ij as indicated in the Derby tools documentation (see "Using the bulk import and export procedures"). The data can be extracted from MySQL using intrinsic formatting commands in the required format, which appears to be pretty standard CSV (this would require that you have an appropriate table already existing in your Derby database).
Here's an example from the MySQL forums:
SELECT a,b,a+b INTO OUTFILE '/tmp/result.text'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '\n'
FROM test_table;
If you want to import everything, Apache DdlUtils will allow the transfer of an entire schema from MySQL to Derby. This would not require the repeated table definition in Derby, as it would come across as part of the import/export process with DdlUtils.
Unless you need to automate the process, the "DBCopy Plugin for SQuirreL SQL Client" tool might work for you. There are probably other tools, but that's the one I know (however never used myself).
If you do need to automate the process, and if you don't care so much about the DDL, then I would probably use CSV.
To take over the data from MySQL (production environment) to Derby (development environment), I use following command:
mysqldump -u root -h 127.0.0.1 --compatible=ansi --complete-insert --skip-add-drop-table --skip-add-locks --skip-comments --skip-disable-keys --skip-set-charset --no-create-info dbname > export.sql
But specially in Derby, I have also the problem of disalbing constraints. Therefore, the insert statements have to be in the correct order!