Updating MySQL

When MySQL was first released publicly, it was at version 3.11.1. It's currently in the version 4.0.x series for stable releases and the 4.1.x series for development releases. Updates appear fairly often and are issued for both the stable and development series. The pace of ongoing development raises the question for the MySQL administrator as to whether you should upgrade your existing MySQL installation when new releases appear. This section provides some guidelines to help you make this decision.

The first thing you should do when a new release appears is to find out how it differs from previous releases. To make sure you're aware of new releases, subscribe to the [e-mail] mailing list. Each announcement includes the new change notes, so this is a good way to remain apprised of new developments. (Alternatively, check the "Change Notes" appendix in the MySQL Reference Manual to familiarize yourself with what's new.) Then ask yourself the following questions:

• Are you experiencing problems with your current version that the new version fixes?

• Does the new version have additional features that you want or need?

• Is performance improved for certain types of operations that you use?

If the answer to all of these questions is No, you don't have any compelling reason to upgrade. If the answer to any of them is Yes, you may want to go ahead. At this point, it's often useful to wait a few days and watch the MySQL mailing list to see what other people report about the release. Was the upgrade helpful? Were bugs or other problems found?

Some other factors to consider that may help you make your decision are as follows:

• Releases in the stable series are most often for bug fixes, not new features. There is generally less risk for upgrades within the stable series than within the development series. (Of course, if you're running a development series server, you may not be that concerned about risk anyway!)

• It's possible that if you upgrade MySQL, you'll need to upgrade other programs that are built with the MySQL C client library linked in. For example, after a MySQL upgrade, you may also need to rebuild the Perl DBD::mysql module and PHP to link the new client library into them. (An obvious symptom that you need to do this is when all your MySQL-related DBI and PHP scripts start dumping core after you upgrade MySQL.) It's not generally a big deal to rebuild these programs, but if you prefer to avoid it, you may be better off not upgrading MySQL. If you use statically linked rather than dynamically linked programs, the likelihood of this problem is much reduced. However, your system memory requirements then increase.

If you're still not sure whether to upgrade, you can always test the new server independently of your current server. You can do this either by running it in parallel with your production server or by installing it on a different machine. It's easier to maintain independence between servers if you use a different machine because you have greater freedom to configure it as you want. If you elect to run the new server in parallel with an existing server on the same host, be sure to configure it with unique values for parameters such as the installation location, the data directory, and the network port and socket on which the server listens for connections. See the "Running Multiple Servers" section earlier in this chapter.

In either case, you'll probably want to test the new server using a copy of the data in your existing databases. See the "Backing Up and Copying Databases" section earlier in this chapter for instructions on copying databases.

If you do decide to upgrade, see if there are any remarks in the "Change Notes" appendix in the MySQL Reference Manual about any special steps you must take when upgrading. Usually there aren't any, but check anyway. This is particularly important if the new release introduces a behavior that is incompatible with earlier releases.

If you upgrade to a version that is not backward-compatible with older versions and then decide to revert to the earlier version, it may not be so easy to downgrade. For example, if you upgrade from MySQL 4.0.x to 4.1.x and convert your tables to 4.1 format, they'll be incompatible with 4.0.x servers. Downgrading can be difficult in this case.

Don't Be Afraid to Try Development Releases

It's not a wise idea to use a development release for production purposes, such as managing your business assets. On the other hand, I do encourage you to test new releases, perhaps with a copy of your production data. The greater the number of people who try new releases, the more thoroughly they are exercised. This improves the likelihood of finding any bugs that may exist, which is a good thing. Bug reports are a significant factor in helping MySQL development move forward because the developers actually fix problems that the user community reports.

If you want an ongoing source of queries for a test server, consider using a production server as a replication master and set up the test server as a replication slave. That way, queries executed by the master server will be sent to the slave server, providing it with a continual stream of queries. This also gives you a chance to see how the test server performs under conditions that mirror production use.