I am planning an upgrade of some MySQL servers (5.1 to 5.5). I am aware that the InnoDB plugin is now built in to MySQL.
Currently we use the InnoDB plugin...
When upgrading to 5.5, is it just a case of removing the relevant lines in my.ini that load the plugin before restarting the server, or is there something I need to do (or should be doing) to the databases and tables in addition to this to take account of the change?
Will the tables just "pick up" the change to the storage engine, or do they need to be converted in some way.
I don't intend on doing a dump and reload of the tables as there are many large databases and this would be a bit of a pain!
Hope this all makes sense!
thanks!
Remove or comment out the plugin options in my.cnf or my.ini file.
Upgrade MySQL.
Run mysql_upgrade script which does the following.
mysqlcheck --all-databases --check-upgrade --auto-repair
mysql < fix_priv_tables
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names
MySQL Manual recommends doing the dump and reload instead of running mysql_upgrade script as it is a safer way to upgrade.
Review MySQL documentation for all details on upgrade steps and gotchas along the way.
Related
Using Homebrew on MacOS...
When starting mySQL using mysql.server start I receive the following error
ERROR! The server quit without updating PID file (/usr/local/var/mysql/Tims-iMac.local.pid).
I've been reading lots of posts on how to solve this issue, none of which have worked, though I keep coming across the following advice:
unset TMPDIR
mysql_install_db
If I do this, will it delete all of my existing databases?
If it will delete them, how do I backup and restore the databases after a new mySQL install?
According to the docs the answer is no, it does not, however, as tadman suggests you should do a backup prior to performing any such maintenance.
To backup your databases use the mysqldump command. And to restore you can use the mysql command line tool.
we know the supported logical upgrade method is:
5.1-5.5,
5.5-5.6,
5.6-5.7.
In each step, we mysqldump, then we need 3times.
If I mysqldump from 5.1, then install mysql5.7, we need 1 time mysqldump.
Can mysql 5.7 recognize mysqldump file from 5.1?
You should look at the differences that MySQL 5.7 offer compared to the older versions and see if it affects anything but considering how large of a jump it is, I find it hard it would "just work." In short, most likely not. Your best bet is to take your data in MySQL 5.1, upgrade it to 5.7 so your schema inherits all the changes that may have happened, and then make a new mysqldump of that.
Related sources:
https://dba.stackexchange.com/questions/123154/migrating-upgrading-a-mysql-5-1-schema-to-mysql-5-7-schema
Upgrading directly from MySQL 5.0 to 5.7
I am currently using mysql server 5.0 with innodb storage engine. I want to backup a database from source server and restore the same to one of the available destination servers.
Option 1: Use innodb_file_per_table option in my .cnf and try to copy the table.ibd file to the other server and recover. I saw examples over other websites where it was being supported in mysql 5.6, but I am not sure if that is supported in mysql server 5.0. I tried the steps given in https://dev.mysql.com/doc/refman/5.6/en/innodb-migration.html, but that did not work for me.
Option 2: Use mysqldump to get a dump of the database and use mysqlimport in the destination to perform mysql export/import. But, by doing so, I need to lock the database at source before performing the export. This can prevent any incoming requests to the source database while the mysqldump is ongoing.
I am still exploring other options, but I am not sure if option 1 is not viable due to mysql version 5.0 or because I am missing something.
http://dev.mysql.com/doc/refman/5.7/en/replication-howto.html
You are talking about replication.
I have a database on a 32bit Linux server with MySQL that I would like to import/copy/migrate to a 64bit Linux server.
I have considered
service mysqld stop
tar czf /root/db.tar.gz /var/lib/mysql
and copy this to the new server.
Or perhaps
mysqldump -uroot -p --all-databases > /root/db.sql
Question
Is that possible, and if so, what the recommended way?
Using mysqldump and re-importing the resultant file will work for certain and is recommended, unless your database is very large and the dump/import process' slower speed is an issue.
Unless the server environment is identical in most ways, you may have some cleaning up to do and permissions corrections if you were to copy the data files over directly. There is documentation on performing the transfer with raw data files, but mysqldump is the usual preferred method.
If you have a large database, I would suggest using XtraBackup. It will likely be much faster than using mysqldump followed by an import.
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.