If at all possible, you should use /scripts/mysqlup to do a MySQL upgrade, however, if you need a version of MySQL outside of what they are offering in current cPanel versions, it is possible to upgrade manually.

These are the instructions for performing a manual upgrade of MySQL to 5.1.30, but this typically applies to all versions over 4.1 and higher. Typically it is best to upgrade to whatever the latest stable branch of MySQL is and apply these instructions to install the RPMS.

If this is on a live system, make sure to make backups of the databases.


mkdir /root/dbbackups

touch /root/dbbackups/list
for db in `mysql -e 'show databases' |awk '{print $1}' | grep -v Database`


do

mysqldump --add-drop-table $db > /root/dbbackups/$db.sql && echo $db >> list

done
mkdir /root/sqllibs
cp /usr/lib/libmysqlclient.* /root/sqllibs

Do a search for all installed MySQL packages to be removed:
rpm -qa | grep -i mysql-

This should present a list of 5 or 6 MySQL RPM’s that are installed, likely. Uninstall them one by one with the rpm -e like so:
rpm -e MySQL-devel-4.1.21-0.glibc23

Some packages are dependencies of each other, so you may need to remove one before being able to remove another.

Download the binaries for the OS version and MySQL version you are using from the cPanel repo:
http://httpupdate.cpanel.net/mysqlinstall/

execute rpm -i for each package (ex: pm -i MySQL-client-5.1.30-0.glibc23.i386.rpm)

Edit /var/cpanel/cpanel.config and change the MySQL version to 5.1 (or whatever version you’re running now). Then run this command:
touch /etc/mysqlupdisable

This will keep cPanel from resetting or reverting back to its original MySQL version during updates.

Restart MySQL first to make sure that it can at least start (which it should). Once you’ve verified this, run mysql -V to make sure that the correct version is installed. You should see output similar as below:
root@server [~]# mysql -V
mysql Ver 14.13 Distrib 5.1.30-beta, for pc-linux-gnu (i686) using readline 5.0


MySQL should now be up and running, but it’s likely that trying to log in directly as the root user will fail. Before Following the below steps, make sure you can do a ‘mysql -u root’ and log in successfully. If not, you’ll need to set the root password. By default, MySQL has a blank root password which will need to be set to ours…twice.
Recopy the libs, but don’t overwrite any that already exist:
mv /root/sqllibs/libmysqlclient.* /usr/lib/mysql/

Next update cPanel’s PHP and DBD MySQL bundle for perl by executing the following:
/scripts/perlinstaller --force Bundle::DBD::mysql
/scripts/makecpphp

Verify that phpMyAdmin and php -m load properly and without errors.

After upgrading to cPanel 11.28, a number of our users indicated that databases were missing from their cPanels, despite the actual databases existing on the server.  There are a number of things that can cause this, including corrupted Perl modules and MySQL not running, but the major cause that I’ve seen is from the new database mapping functionality.  As you may know, cPanel has vastly improved their migration capabilities by recently changing how databases are mapped to user accounts, now allowing database names without user prefixes.  However, this seems to cause an issue when databases exist on the server with invalid names.

Check your /var/lib/mysql folder and see if you maybe have folders in there named incorrectly. On one of my servers, the admin renamed several of the databases to $dbname.bak when making changes, and when the database quota script ran it was erroring out. After you move or remove these folders, run the following commands:

/scripts/update_db_cache

/usr/local/cpanel/bin/setupdbmap

Assuming you’ve removed all the invalid databases from the MySQL folder, you should now be able to see the ones that were previously missing.

It was announced by cPanel on April 14, 2010 that cPanel 11.25.1 will include a new database mapping feature that’s been long requested: the removal of cPanel username prefixes from the database names.  This is a non-reversible, opt-in feature that some hosts may find very valuable. But is it a feature that you need?

Who is this feature for?

• Hosts migrating entire servers from other control panels like Plesk or Ensim
• Single-customer environments

Who is this feature not for?

• Shared hosting providers
• Larger-scale hosts

The concerns that are initially raised is in regards to shared hosting servers. With the new database mapping feature turned on, if one user takes a database name, no one else on the server can use it. Additionally, you’re creating a conflict if you move that user from one server to another, where the recipient server already has a user with that database name.  For these reasons alone, I would not advise this option being enabled for the general shared hosting provider, if the end users are going to be allowed to pick database names.

One of the advantages of cPanel is that you can move accounts between cPanel servers, even those from other hosts. If one host has the new mapping feature enabled, and one doesn’t (or has an older version of cPanel), you’re likely going to have a problem. For hosts with high conversion rates, this can be a deal breaker if the ease of moving cPanel accounts from other hosts isn’t there anymore.  This feature also creates a break in the standardization that all cPanel servers inherently have.  Most users by now that have already used cPanel know about the current database naming scheme, so enabling this feature without any technical justification can also create confusion among users that are familiar with and have been using cPanel for a long time.

Update: A rep from cPanel added this comment:

As cPanel 11.25.0 builds 46057 and higher, accounts transferred from a cPanel 11.25.1 system will preserve the YAML mapping file. Any databases and database users that lack the old-style prefix will not be manageable in the 11.25.0 cPanel interface, but the information is at least retained for later use (e.g. if a system with such an account is later upgraded to cPanel 11.25.1+ then the pre-existing YAML file will be updated and the databases and user will be manageable in the cPanel interface).

On the other hand, this feature is extremely valuable for hosts converting from other control panels or fulfilling requirements of single-customer environments. Other control panels do not prefix usernames to the database name, so large transfers would be especially painful for a cPanel host that acquires a non-cPanel host. The new mapping feature will help eliminate downtime due to incorrect database connection parameters and the need for mass reconfiguration.

Finally, for hosts that offer VPS and Dedicated hosting to single-customer environments, it’s nice to finally be able to remove the prefix that annoys web developers and IT people in charge of moving their customer sites.

So while this new feature is exciting, it’s opt-in for a reason – and that doesn’t mean it’s right for your hosting setup.

Additional Information:

http://www.cpanel.net/blog/integration/2010/04/a-general-overview-of-database-mapping.html
http://www.cpanel.net/2010/05/backwards-incompatible.html
http://www.cpanel.net/blog/integration/2010/05/more-details-about-db-mapping.html

When you upgrade from cPanel 11.24 to 11.25, your users may notice that in cPanel, their MySQL databases show 0MB of disk space used, when they know their databases are much larger. This is due to an option in cPanel that you specifically have to enable. To enable MySQL disk usage tracking:

1) Edit /var/cpanel/cpanel.config

Change:

disk_usage_include_sqldbs=0

to

disk_usage_include_sqldbs=1

Then run the following:

/scripts/update_db_cache
This may take a few minutes if you have a ton of users with databases, but after this, you should see the database disk usage show up accurately in cPanel.

Cpanel has a lot of supporting software that you may be using on your server. In case something goes amiss, here is a list of scripts that reinstall cpanel-provided software on your system. For most all of these, you can pass a –force as an argument to force a reinstall of the application.

cPanel
/scripts/upcp

MySQL
/scripts/mysqlup

PostgreSQL
/scripts/installpostgres

Roundcube
/usr/local/cpanel/bin/update-roundcube

Horde
/usr/local/cpanel/bin/update-horde

Squirrelmail
/usr/local/cpanel/bin/update-squirrelmail

phpMyAdmin
/usr/local/cpanel/bin/updatephpmyadmin

pureFTP
/scripts/ftpup –force (See: Installing and Configuring pure-FTP)

Exim
/scripts/eximup

Courier IMAP
/scripts/courierup –force (See: Installing/Configuring Courier IMAP)

Dovecot
/scripts/dovecotup –force (See: Installing and Configuring Dovecot)

cpAddons
/scripts/cpaddonsup

NSD/BIND
/scripts/setupnameserver (NSD:/scripts/nsdup)

Apache/PHP
/scripts/easyapache (See: EasyApache)

suPHP
/scripts/suphpup

cPanel Internal PHP
/scripts/makecpphp

FrontPage Extensions
/scripts/fpupgrade

Mailman
/scripts/reinstallmailman (will not remove list data)

cpHulkd
/usr/local/cpanel/bin/hulkdsetup

Ruby
/scripts/installruby

Click here for instructions on manual upgrades

You can easily change the major version of MySQL running on your server, keeping in mind that the actual version will be dependent on what cPanel has released in their repository. You may notice that in WHM > Tweak Settings, where MySQL upgrades and downgrades are usually done, you can no longer downgrade to versions under 5.0, nor (at the time of this writing) can you choose MySQL 5.1. Luckily cPanel gives you a way to get around this.