On the old server I used the mysqldump command to make me a backup of the MySQL database.
On the new server, with version 5.6 of MySQL, the same command gives me the error
unknown option '-no-beep'
whatever it insert.
I also searched on the internet but I could not find any help....
In your init file for mysql (my.ini), comment out the no-beep line, as it is no longer a valid option in mysql > 5.0.
See answers here
Related
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.
I took backup of database from workbench from a remote server. So when I import it on my local environment I got error:
ERROR 1193 (HY000): Unknown system variable 'GTID_PURGED'
I'm using xampp server
Getting same error either import db via console or phpmyadmin
Need remove all lines with GTID_PURGED
sed -i '/##GLOBAL.GTID_PURGED=/d' your_file.sql
The final file will load without problems
After spending a lot of time.
I opened my database file in text editor and search for this variable "GLOBAL.GTID_PURGED". I just set it's value ""
like
SET ##GLOBAL.GTID_PURGED=""
Then I upload database via windows console now It works like a charm :)
Re-create the dump file by appending the --set-gtid-purged=OFF option would resolve the problem.
It was because GTIDs was added in MySQL 5.6, which is not recognized by the earlier versions.
Your command might look like below:
mysqldump -u username -ppassword -h mydbhost --set-gtid-purged=OFF db_name > dump_file.sql
More on my story, I got the same problem with a dump file originated from MySQL 5.7. I was trying the import the data into a new CentOS 7 installation with the default MariaDB installation, which is 5.5 (I guess).
The first idea came to my mind was to upgrade to latest MariaDB. Luckily their website provides a great utility to help set the package repository for Linux variaties. Moreover, digitalocean has a very short and clear guide for the upgrade process, thanks to them too!
While upgrading to the lastest MariaDB stable version 10.2 does NOT get rid of this problem. So I still have to use the option mentioned above, but it let me upgrade to the latest MariaDB anyway.
Another problem after my upgrading was that the innodb_additional_mem_pool_size config from my-innodb-heavy-4G.cnf is not supported anymore on the latest MariaDB, server failed to start. From the MySQL documentation, it was removed from MySQL 5.7. I can start the server after commenting it out. I'm not the DB expert, I would not spend more time to check how exactly MariaDB version mapping to MySQL DB, and what difference they have.
Kindly follow below step to resolve this.
Open your DB dump in notepad++/notepad
Search for SET ##GLOBAL.GTID_PURGED="[some value will be here]"
Just remove this [SET ##GLOBAL.GTID_PURGED=""] line from the db dump
Save your DB dump and try to import now.
This is working for me and I hope this will work for you as well .
You can also set the set-gtid-purged=OFF from MySQL workbench, before running the dump, click on advance options and change the AUTO to OFF under set-gtid-purged. run the dump and there should be no problem restoring to a different MySQL version.
It may be tricky to load the file and edit it if this is a large database. Here is how I did it:
I located the line number with less -N dump.sql. It was at line 24.
Then I commented that line with sed -i '24s/SET/\#SET/' dump.sql.
Finally, the mysql command to import the database dump worked.
Asterisk (version 11 & 13) Realtime was working fine with MySQL version 5.5 but when I upgraded MySQL 5.7. It stops working and following errors appeared:
ERROR[17524] res_config_mysql.c: MySQL RealTime: Failed to connect database server <database-name> on localhost (err 2003). Check debug for more info.
WARNING[17524] res_config_mysql.c: Table <table-name> not found in database. This table should exist if you're using realtime.
There was no issue in config files, database and table but it happens after MySQL upgraded from 5.5 to 5.7 version.
Can anyone help me to fix this issue or I should downgrade MySQL to previous version?
Changing your my.ini or my.cnf in [mysqld] section to include
log_warnings=2 will provide the maximum detail on connection failures.
Post into original question content of your present my.cnf OR my.ini and error log and someone will likely be able to assist.
Please note, you also may have rebuild asterisk with new mysql-devel.
When I was installing MySQL 5.6 if, there was a option to choose your MySQL database dir (I guess). I chose that option and set it to D:\ProgramData\MySQL\MySQL Server 5.6. I was hoping that there would be the same on MySQL 5.7 installation but there is not.
So, how to import the MySQL 5.6 database to 5.7?
There are several ways. Best one is to always have a full dump of the database in case you need to regenerate from zero.
Other way is to allow mysql installer to do the upgrade. If the installer fails to take the previous datadir, you can manually specify it modifying the my.ini config file.
Search for an entry, which should look like this:
# Path to the database root
datadir=D:/ProgramData/MySQL/MySQL Server 5.6/Data
Hope this helps.
How to enable inno-db support on installed instance of MySql?
I have installed mysql-5.0.67-win32.
'InnoDB' is 'DISABLED' when executing 'show engines'.
According to documentation MySql is compiled with support of inno-db
(From doc: A value of DISABLED occurs either because the server was started with an option that disables the engine, or because not all options required to enable it were given.)
In my.ini I commented line with 'skip-innodb'. This didn't help.
All other inno-db related variables remain unchanged.
I have performed some unusual action before I experienced described situation.
I have mysql-4.0.17-win installed. I uninstall it and after this installed mysql-5.0.67-win32.
In installation wizard I chose MyISAM support only (as far as I understand I disabled inno-db support in such way. When I tried to reinstall with support of inno-db I had problems of using my previous database 'mysql' with account information).
MySQL documentation says that I should use mysqldump to export data and after this to import exported data in process of upgrade. I tried to do so, but when importing data I obtained message about syntax error (I think that it is connected with some incompatibilities of 4-th and 5-th version of mysql)
Should be enabled by default. There are some situations where wrong permissions on the MySQL lib folder cause InnoDB to bark. Check your MySQL error log for permission errors.
I do have the following innodb options in my.ini. It is a very minimal configuration, so dont' use this values if you would like mysql to have a good performance. Please restart mysql after a change of my.ini.
#*** INNODB Specific options ***
innodb_data_home_dir="C:/mysqldata/"
#skip-innodb
innodb_additional_mem_pool_size=120M
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=16M
innodb_buffer_pool_size=10M
innodb_log_file_size=2M
innodb_thread_concurrency=8
Maybe you have inno-db disabled in the global configuration file. On Linux this would be something like /etc/mysql/my.cnf - maybe Windows has a similar global conf-file.
Make sure you are changing the correct my.ini file. On Windows this is read from many locations. The order is:
WINDIR\my.ini, WINDIR\my.cnf
C:\my.ini, C:\my.cnf
INSTALLDIR\my.ini, INSTALLDIR\my.cnf
defaults-extra-file
Type mysql --help in the command prompt to see the actual order on your computer e.g.:
Default options are read from the
following files in the given order:
C:\my.ini C:\my.cnf C:\WINDOWS\my.ini
C:\WINDOWS\my.cnf C:\Program
Files\MySQL\M ySQL Server 5.0\my.ini
C:\Program Files\MySQL\MySQL Server
5.0\my.cnf
have you checked the startup parameters? maybe the shell script or batch file that you use to start up the server disable the engine on the command line.. IIRC command line flags trumps the .ini settings.
I have resolved the problem.
In short:
I was not able to dump databases on MySql4 and restore it on MySql5 due to some strange syntactic errors when importing data.
I tried after installation to override MySql5 databases with old ones, including database 'mysql'. It works ok but I was not able to enable inno-db support. (In such way I even was able to use function PASSWORD for old passwords (instead of OLD_PASSWORD))
Since database structure of 'mysql' is changed in 5 version I tried to install MySql5 again and copied my old databases except 'mysql' one. After this I updated 'mysql' database with corrected version of exported data from 'mysql'. In such a way I obtained mysql 5 working.
After all I also executed mysqlcheck --all-databases --auto-repair
to upgrade my tables.
P.S. Thank to authors of all answers which hint me to the correct way of resolving problem.