First, are you certain that 4.0.5a is working "perfectly"? A lot of bugs have been fixed since then. Is it possible you just haven't seen them?
I would start by reading the change history in the manual <http://www.mysql.com/doc/en/News.html>. For each revision from 4.0.5 to 4.0.17 there is a page of changes. I'd pay particular attention to the list of fixed bugs. Note that there is also a page documenting changes in the not-yet-released 4.0.18. That could give you a heads up on any bugs in 4.0.17. There's also this list.
Then, it seems to me, you are faced with the usual administrator dilemma: What are the odds and consequences of hitting a known bug versus the odds and consequences of hitting a new, unknown bug? I'm not sure there's a simple, one-size-fits-all answer to that. I suspect that most managers would not be sympathetic when bitten by a known bug that you chose not to fix. On the other hand, once bitten, known bugs are easier to fix (upgrade) than new ones. And, of course, if your application is so critical that you stop everything else and test for a month (or six) before rolling out a server upgrade, then you can't practically upgrade every time a new version comes out.
In your case, consider that your testing environment (more or less latest) is increasingly unlike your production environment (4.0.5a). Hence, it seems to me, the quality of your testing is decreasing. The problem you ran into here seems to me to be a symptom of that. If you won't be upgrading the production server, you probably ought to revert the test box to the same version. I doubt you want to do that, though.
A better idea might be to decide how much testing must be done before you put a new version of the server into production, including how long it will take. Then decide how often you are willing to do that. Every 6 weeks? Quarterly? Once a year? Say you decide on quarterly upgrades with 1 month of testing. Then you could put the latest mysql on your test box 6 weeks before the quarterly upgrade date and test. You don't upgrade the server on the test box during the test period, unless a new version has a critical bug fix (security or data corruption), in which case you restart the test clock. The key here, I think, is to make sure that your testing method and timing makes you confident that upgrading the production server will work. If not, I suggest the problem lies with the testing scheme rather than with the upgrade.
There are a lot of good administrators on this list. Perhaps someone else will add to that or suggest a better way.
Michael
Richard S. Huntrods wrote:
My problem with deletes/inserts corrupting the database table has been resolved. I was using version 4.0.15, and the very bug I experienced was reported for version 4.0.14. As of 4.0.17, it is fixed. Interestingly, the bug does not appear in 4.0.5a on my Solaris box.
Which brings me to my more "global" (a.k.a. of importance to many persons using MySQL) question...
When do you justify upgrading to a new version of MySQL on a production server?
I've been upgrading MySQL versons pretty regularly on my development machine. Not every time, but about every quarter (3 months). Until this particular bug, I've never had a big problem with the devel version being newer than the production version. (in this case, the bug was discovered during my servlet junit tests, and so prevented me from distributing the new code until I had resolved the problem).
However, because the current "production" version I'm using (4.0.5a on Solaris SPARC 2.8) is working perfectly, I am very reluctant to upgrade the production version unless I have a good reason to do so. The problem is that I'm at a loss to explain what a "good reason" might be. :-)
How do those of you using MySQL in production mode make your upgrade decisions? As a related question, what version would you run on a Solaris 2.8 (SPARC) server?
Cheers,
-Richard
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
