Some notes on a MySQL downgrade 5.1 to 5.0

Written by - 0 comments

Published on - Listed in Linux Database MySQL


On a MySQL downgrade from 5.1 to 5.0, which generally went well, I got into some minor problems after the downgrade itself.
Here are some notes on what problems may occur after such a downgrade.

First of all, an official MySQL 5.1 to 5.0 downgrade document exists:
http://dev.mysql.com/doc/refman/5.1/en/downgrading-to-previous-series.html
The document informs about major differences between 5.1 and 5.0, mainly PARTITIONING, EVENT SCHEDULER, STORED ROUTINES and TRIGGERS.

In my case, none of the above were used so I could go ahead and make my dumps without having to look for special routines, etc.
The downgrade procedure was:

- Dump of data bases
- Stop MySQL server
- Uninstall MySQL 5.1 server and client packages
- Install MySQL 5.0 server and client packages
- Start MySQL server
- Restore dumps

And now the fun starts: MySQL didn't start up after the downgrade:

# /etc/init.d/mysqld start
Timeout error occurred trying to start MySQL Daemon.
Starting MySQL:                                            [FAILED]

But no reason to sweat, a quick check in the mysqld log file told me why:

# tail -f /var/log/mysqld.log
120816 09:40:37  mysqld started
120816 09:40:37 [ERROR] /usr/libexec/mysqld: unknown variable 'table_open_cache=64'
120816 09:40:37  mysqld ended

After commenting-out the 'table_open_cache' parameter in /etc/my.cnf, MySQL started up:

# /etc/init.d/mysqld start
Starting MySQL:                                            [  OK  ]

Hurray!

But before I restored the dumps, I wanted to create another dump of the current mysql db, in case the restore of the dump would fail and break all privileges:

# mysqldump mysql > mysql.afterdowngrade.sql
mysqldump: Got error: 1017: Can't find file: 'general_log' (errno: 2) when using LOCK TABLES

Umm... Yes, that's something new which I haven't seen before.
Fortunately another guy had the exact same issue back in 2007 (my god, is this version already that old?!):
http://lists.mysql.com/mysql/206584

The resolution to this error is pretty simple. The general_log and slow_log entries of the mysql data base (e.g. in /var/lib/mysql/mysql) need to be removed.
So I did what I had to do:

# /etc/init.d/mysqld stop
Stopping MySQL:                                            [  OK  ]

# rm /var/lib/mysql/mysql/general_log.*
# rm /var/lib/mysql/mysql/slow_log.*

# /etc/init.d/mysqld start
Starting MySQL:                                            [  OK  ]

# mysqldump mysql > mysql.afterdowngrade.sql

After a stop of MySQL, I manually removed all general_log* and slow_log* files in the mysql data base folder and then started MySQL again.
The dump went then as smooth as it should.

The last thing to do was the restore of the dumps created before the downgrade and this also worked like a charm!


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder