At TcX, MySQL has worked without any problems in our projects since mid-1996. When released to a wider public we noticed that there were some pieces of 'untested code' in MySQL that were quickly found by the new user group who made queries in a different manner. Each new release has had fewer portability problems than the previous one, even though they have all had a lot of new features, and we hope that it will be possible to label one of the next releases 'stable'.
Each release of MySQL has been usable and there have only been problems when users start to use code from 'the gray zones'. Naturally, outside users can't know what the gray zones are and I hope this section will clarify those currently known.
We will here try to answer some of the more important questions that seems to concern a lot of people and clarify some issues. This section has been put together from the information that has come forward in the mailing list which is very active in reporting bugs.
How stable is MySQL? Can I depend on MySQL in this project?
This is about the 3.21.x version of MySQL. All known and reported bugs are fixed in the latest version with the exception of the bugs listed in the BUGS file which are things that are 'design' related.
MySQL is written in multiple layers and different independent modules. Here is a list of the different modules and how tested each of them are.
--skip-lockingflag. Known problems are some Linux systems and SunOS when using NFS-mounted file systems.
--skip-locking. Some people have reported lockup problems with the 0.5 release.
TcX provides email support for paying customers, but the MySQL mailing list usually provides answers to all common questions. Bugs are usually fixed right away with a patch that usually works and for serious bugs there is almost always a new release.
Well, MySQL is evolving quite rapidly here at TcX and we want to share this with other MySQL users. We try to make a release when we have a very useful feature that others seem to have a need for.
We also try to help out users who request features that are easy to implement. We also take note of what our licensed users want and we especially take note of what our extended email supported customers want and try to help them out.
No one has to download a new release. The News section will tell you if the new release has something you really want. See section MySQL change history.
If there is, by any chance, a fatal bug in a release we will make a new release as soon as possible. We would like other companies to do this too. :)
The 3.21.x version incorporates major portability changes for many different systems. When the 3.21 release is stable we will remove the alpha/beta suffix and move active development to 3.22. Bugs will still be fixed in the stable version. We don't believe in a complete freeze, as this also leaves out bug fixes and things that 'must be done'. 'Somewhat freezed' means that we will maybe add small things that 'almost surely will not affect anything thats already working'.
If you are running and old system and want to upgrade, but you don't want to take chances with 3.21 you should upgrade to 3.20.32. I have tried to only fix fatal bugs and make small, relatively safe changes in this version.
If you are trying MySQL for the first time or have a little time to test out that your current system, you should use 3.21.
If MySQL crashed (for example if the computer is turned off) when all data is not written to disk the tables may have become corrupted. To check a table use:
isamchk -e table_name
isamchk -ei table_name
We at TcX run a cron job on all our important tables once a week.
35 0 * * 0 /path/to/isamchk -s /path/to/dbs/*/*.ISM
This prints out any crashed tables so we can go and examine and repair them when needed.
As we haven't had any unexpected crashed (without hardware trouble) tables for a couple of years now (this is really true), once a week is more than enough for us.
Of course, whenever the machine has done a reboot in the middle of a update one usually has to check all the tables that could have been affected. (This is a 'expected crashed table'.)
We recommend that to start with one should do a
isamchk -s on all
updated tables each night until one comes to trust MySQL as much
as we do.
Naturally, one could add a check to safe_mysql that, if there is an old pid file left after a reboot, it should check all tables that have been modified the last 24 hours.
The file format that MySQL uses to store data has been extensively tested, but there are always instances (like a hard kill on the mysqld process in the middle of a write, a hardware error or a unexpected shutdown of the computer) when some tables may be corrupted.
The sign of a corrupted table is usually when queries abort unexpectedly and one gets errors like:
In these cases you have to repair your tables. The isamchk external utility can usually detect and fix most things that go wrong. See section The MySQL table check, optimise and repair program.
If you are going to use isamchk on very large files, you should first decide how much memory you want to give to isamchk. More memory gives more speed. For example, if you have more than 32M ram, try:
isamchk -O sortbuffer=16M -O keybuffer=16M -O readbuffer=1M -O writebuffer=1M ....
shell> mysql database mysql> delete from table_name; mysql> quit
One can always move the MySQL form and data files between
different versions on the same architecture as long as one has the same
base version of MySQL. The current base version is of course
3. If one changes the character set (sort order) by recompiling
MySQL one has to do a
isamchk -rq on all tables.
If you are paranoid and/or afraid of new versions you can always rename your old mysqld to something like mysqld-'old-version-number'. If your new mysqld then does something unexpected you can simple shut it down and restart with your old mysqld!
When you do a upgrade you should of course also take a backup of your old databases. Sometimes its good to be a little paranoid!
If you already have a version older than 3.20.28 running and want to switch to 3.21.# you need to do the following:
You can start the
mysqld 3.21 server with
--old-protocol to use it with the original 3.20 data. In this case the
new client function,
mysql_errno(), will not return any server
CR_UNKNOWN_ERROR, (but it works for client errors)
and the server uses the old password() checking instead of the new one.
If you are NOT using
scripts/add_long_passwordmust be run to convert the password field in the 'mysql/user' table to
MySQL 3.20.28 and above can handle the new user table format without affecting clients. If you have a MySQL version below 3.20.28, passwords will not work on it anymore if you convert the user table. So to be safe, you should first upgrade to at least 3.20.28 and then upgrade to 3.21.#.
The new client code works with a 3.20.# version, so you can use the old 3.20.# server if you experience problems with 3.21.# without having to recompile the clients again.
If you are not using the option
old clients will issue the error message:
ERROR: Protocol mismatch. Server Version = 10 Client Version = 9
Go to the first, previous, next, last section, table of contents.