phpMyAdmin stuck on 2.11 even though update set to "current" tier

[aww]

I noticed my other servers are now running phpmyadmin 3.4 but I have one server stuck on 2.11

Is there any setting that might be blocking the auto-upgrade?

The server is on older centos 4.8 with mysql 4.1 but that really shouldn't stop an update, right?

(whm set to Current tier and now on 11.30.2)

[cPanelMichael]

Hello

phpMyAdmin 3.4 is only available on servers that use MySQL 5 or higher. If your server uses MySQL 4.1, then you must continue using phpMyAdmin 2.x.

Thank you.

[aww]

Ah okay, thanks for the insight.

I guess I am waiting for 5.5 in 11.32 later in the year.

[cPanelTristan]

I would suggest updating to MySQL 5.0 to check that everything functions, and then to MySQL 5.1 afterward rather than trying to update from MySQL 4.1 to MySQL 5.5 when that becomes available. Going in increments now would be preferable to waiting to do that profound of an upgrade path. I've seen enough issues with MySQL 4.1 to 5.1 upgrades when the server administrator did not do MySQL 4.1 to MySQL 5.0 first, so I can only imagine the possible database corruption issues that might occur if going MySQL 4.1 ==> MySQL 5.5.

Of note, please ensure to have full MySQL backups prior to performing any MySQL upgrade(s):

mysqldump --add-drop-table --all-databases | gzip > /home/alldatabases.sql.gz

This will save a copy in /home called alldatabases.sql.gz for all MySQL databases.

If you ever need to restore from that backup, the command would be:

gunzip < /home/alldatabases.sql.gz | mysql -u root

[aww]

Thanks for the tips.

I do a remote rsync backup of the daily backup directory nightly so mysql is pretty safe, at least right after 3am lol.

I've never experienced a problem with 4.1 after several years of using it and hesitated to upgrade because benchmarks show myisam to be measurably faster in 4.1 vs 5.1

I guess I will step through 5.0 to 5.1, etc. since nothing else has to be rebuilt for it.

I've also read to run

mysqlcheck -A –check-upgrade

aha:
http://dev.mysql.com/doc/refman/5.1/en/upgrading.html

"If you perform a binary (in-place) upgrade without dumping and reloading tables, you cannot upgrade directly from MySQL 4.1 to 5.1. This occurs due to an incompatible change in the MyISAM table index format in MySQL 5.0. Upgrade from MySQL 4.1 to 5.0 and repair all MyISAM tables (see Section 2.4.4, Rebuilding or Repairing Tables or Indexes). Then upgrade from MySQL 5.0 to 5.1 and check and repair your tables."

[cPanelTristan]

Are you only using MyISAM for the table engine? I ask because rsync of flat files for InnoDB storage engine tables wouldn't be the ideal way to perform a backup of MySQL. A proper MySQL backup using the command I've noted would be optimal for InnoDB table engine data, since it doesn't try to perform a copy of the data while it is being written to the database and /var/lib/mysql/ibdata1 file. You can end up with data not synced between the database and the ibdata1 file, causing MySQL to refuse to start up with InnoDB enabled.

Now, if you are only using MyISAM and InnoDB is disabled, this wouldn't be a concern.

[aww]

Yup, only MyISAM, I wouldn't be crazy enough to use innodb with 4.1

Apparently cpanel backs up the .myd .myi files as well as does a .sql export, so it would seem pretty safe for recovery.

But I will probably do an export right before upgrade anyway, you can never have too many backups.