Upgrading to MySQL 5.0.48 on RHEL and CentOS

September 19, 2007 by · 42 Comments 

Yeah, I know last month I said that I probably wouldn't be doing any more releases of MySQL from the Enterprise-only sources but I guess I lied. As soon as I saw that 5.0.48 was out I checked it out from BitKeeper and started working to turn that into a package that I could use to build my RPMs. Not wanting to unleash an untested copy of MySQL on the masses, and not knowing how my readers would react to my releasing packages made from an unofficial source tarball, I decided to keep that one private for a while and test it on my own systems.

Well, just about when it got to the point when I was going to release it to the wild, some kind soul went and released the official tarball for 5.0.48 Enterprise. The 5.0.48 binaries currently in my repo are made from the official sources, not my original BitKeeper sources. That said, given how well they worked out for me I am still not opposed to, in the future, releasing Enterprise versions of MySQL that are made from the BitKeeper sources and then later doing a respin if the official source tarball leaks out. If you have a concern about that, let me know.

As always, a link to the release notes is below, as is the src.rpm needed to build this package yourself (although I really don't know why you'd want to do that, it's a very painful experience).

UPDATE (9/21/2007): The Source & Binary RPMs has been updated to include a patch for Bug #31001 which caused "ORDER BY" to not work correctly for InnoDB tables. All users of InnoDB are urged to update if you care about the order of your results.

MySQL 5.0.48 Release Notes

Update (9/24/2009): Packages deleted, use the yum repository instead.


42 Responses to “Upgrading to MySQL 5.0.48 on RHEL and CentOS”
  1. Allan Wang says:

    I am using centos5, so EL5 I suppose.

    When installing your 5.0.46, I upgraded from centos's base repository's mysql-5.0.22, so could that be an issue?

    What could I do to figure out what the problem is? Even after removing mysql completely to install your mysql package, the problem still existed when I upgraded to 5.0.48.

  2. Jeremy Cole says:

    Hi Jason,

    Note that MySQL 5.0.48 was just recalled due to some a very stupid regression (MySQL Bug #31001, see http://bugs.mysql.com/bug.php?id=31001).

    You can always find the newest sources for these releases on http://mirror.provenscaling.com/mysql/enterprise/



  3. Ron Reed says:

    I have your 5.0.46 mysql for x86_64 installed currently, but what I am looking for is the clustering tools. Are the ndb_mgmd and ndbd in a separate package? Some of the reading that I have done seems to point to the MaxDB package, do I need to compile that myself for the latest version?

  4. Jason says:


    Are you using the 64-bit version of CentOS 5? If so, are you running a pure 64-bit environment or a mixed 32-bit/64-bit system? You should be able to tell fairly easily by running "rpm -qa | grep mysql" and seeing if multiple copies of your packages show up on the list. If so, get rid of the 32-bit packages and the problem will (hopefully) go away.


    I compile my packages in the same style as the ones that ship with RHEL/CentOS/Fedora, what I call the "Red Hat style". They differ somewhat from the official binaries distributed by MySQL in that the packaging is different and that the cluster components are not included.

    A modified spec file was posted by another user in the MySQL 5.0.45 comments but I did not merge his changes into my spec file. You may be able to use his spec file, modified to look for the newer source version, to build the packages you need.

  5. Jason says:


    Thanks for the recall notice. I'll do a respin now with the patch for that issue.

    As to the sources, Thanks! That will save me some time not having to screw around with BitKeeper.

  6. Allan Wang says:


    Yes, I'm running a 32/64 environment, and there are two copies on the list. Removing the 32-bit version seems to have fixed it.


  7. Jason says:


    Glad to hear it!

  8. CentOS builds the latest mysql for the centosplus repo for CentOS-4 (the CentOS Web Stack) ... we will soon be building the same for the centosplus repo for CentOS-5.

    In fact we currently have 5.0.48 (with the bug ... will fix that now) in CentOS-4 centosplus repo, and we have 5.0.44 in the CentOS-5 testing repo.

    The CentOS rebuilds are based on upstream spec files from the Red Hat Web Application Stack:


  9. Jason says:


    Good to know. One of the reasons I started building these packages was because even the centosplus repo was stalled at a much older version of MySQL and, at the time, hadn't even updated past PHP 5.0.4. On that, are you guys planning on adding packages for PHP 5.2.x or are you going to leave EL4 at 5.1.6? 5.2.x has made some remarkable improvements over 5.1.x.

  10. @jason:

    We are going to use the version from the RHWAS stack (currently 5.1.6), as they are releasing that. The reason we are using the "Current Enterprise" is that RH will not normally release the mysql SRPM ... see this bug:


  11. Tyler says:

    Hey, question for you, and I know this is a fairly old post. I'm fairly green to the whole Linux thing, not that I don't like it, just I've had quite a few years starting with MS-DOS, so I'm far more comfortable with Windows.

    Anyway, I have a server running CEntOS 4.4 and after running the RPM file on your Repo for mySQL 5.0.48-jason.2 i386, I tried running it and it tells me that:

    sh: /etc/rc.d/init.d/mysqld: No such file or directory

    Help? Or is there a better version I should be using. I'm not very adept at finding RPM's so having your Repo has been great. The Apache updgrade to 2.2.6 went very smoothly as did the update to PHP 5.2.4, thank you very much.

  12. Jason says:

    If all you installed was "mysql" then you didn't actually get the MySQL server. You want "mysql-server".

    As to picking and choosing RPMs from my repo, be careful with that. Many of My RPMs (httpd & PHP most notably) have dependencies on each other which is why I created a yum repository, rather than just posting links to the binary packages.

  13. p0x says:

    Can MySQL 4.1.20 be upgraded directly to 5.0.48 using the rpm here in the repo? I ask, as I want to upgrade MySQL and then proceed to the PHP upgrade (4.3.9 > 5.2.4), or should I simply attempt the "yum install" command specifying both packages?

  14. Jason says:


    If you're using my yum repository then you should probably just run "yum update" to update everything you've got installed and then "yum install" on anything else you might want (such as 'php-xcache'). There may be a couple packages blocking the update as I do not provide an updated version of everything in the EL4/EL5 repos, basically just the stuff I use and the stuff other people have asked me for.

  15. John says:

    So, I set up your repository as documented, and I run yum update. I get a couple of errors:
    --> Processing Dependency: mod_jk-ap20 for package: psa-tomcat-configurator
    --> Finished Dependency Resolution
    Error: Missing Dependency: php <= 4.4.0 is needed by package php-sqlite2
    Error: Missing Dependency: libmysqlclient.so.14(libmysqlclient_14) is needed by
    package php5sb
    Error: Missing Dependency: mod_jk-ap20 is needed by package psa-tomcat-configur
    It seems to be pulling stuff from your repository ok, but fails to do anything. How can I fix this? (CentOS4/i386)

  16. John says:

    So, I removed the 2 packages and got the update to roll just fine... now, I have a more insidious error when trying to start apache.
    httpd: Syntax error on line 209 of /etc/httpd/conf/httpd.conf: Syntax error on l
    ine 2 of /etc/httpd/conf.d/fcgid.conf: API module structure 'fcgid_module' in fi
    le /usr/lib/httpd/modules/mod_fcgid.so is garbled - expected signature 41503232
    but saw 41503230 - perhaps this is not an Apache module DSO, or was compiled for
    a different Apache version?
    This is a problem that I can solve how?

  17. p0x says:


    Thanks. After a long 5 hours, I am where I want to be, thanks to your repos for some pieces and differing ones for others. Always performedin isolation of each disparate repo. One thing I will note for any poor soul upgradind MySQL from 4.1.20 to current, running a Plesk Control Panel (8.2.1 in my case), and taking advice (verbatim) from eva2000 regarding the my.cnf file. He notates to "skip innodb". Well, why that may be fine in most cases, it ain't with Plesk. Took me 2 hours of log surfing to resolve that hidden little gem. InnoDB is used by PSA, and without, it no worky. Beyond that and some other minor issues with IonCude loader (referential paths were incorrect in .ini file) and XCache messing with me, all was good in the end. I learned a $hitload from your writings, and I thank you for that !!


  18. John says:

    I solved the majority of my issues by manually copying over the distro ini files for apache and php, then doing a little hand editing to link things up right. 99% of the core stuff appears to be working now - still trying to get some custom e-tail LAMP application working (it uses Smarty, which seems to be broken still). At least I'm learning a lot...

  19. Jason says:


    httpd modules are tied to a specific version of httpd. If you had an additional httpd module installed then (assuming that the other RPM had proper deps set) yum wouldn't let you install something that would cause a problem. It sounds as if whatever package supplied 'mod_fcgid.so' didn't include a proper dependency on the version of httpd it wanted.

    As to 'mysqlclient14.so', you can get that from the "mysqlclient14" package in my repository.


    Yeah, Plesk uses InnoDB tables for itself. All of your content will work fine but the Plesk app will refuse to load.

  20. Jason says:


    Yup. I noticed that a couple hours ago. I should have packages built some time tomorrow.

  21. Jason says:

    Yeah, I didn't get those 5.0.50 packages built today. I ran into an issue with SSL tests failing and just didn't have the time to work through it.

  22. Jesse says:

    New version of PHP came out too. Also, it looks like 5.0.52 might be coming out shortly http://dev.mysql.com/doc/refman/5.0/en/releasenotes-es-5-0-52.html

  23. Jason,

    I have the exact same problem with 5.0.50 ... all of the SSL tests are failing

  24. Jason says:


    Yup, the files have been in the repo folders since yesterday but I didn't rebuild the repo until a few minutes ago.


    Let me know if you figure it out. I assume that your build attempts are failing for the same reason as mine ("unable to connect" or something like that)?

  25. Jesse says:

    Looks like 5.0.51 of the community server has been released


  26. Jason says:


    Yeah, I noticed that release page. Unfortunately, the source (or prebuilt binaries, for that matter) doesn't actually seem to be available anywhere. Hopefully it will pop up within the next couple days.

  27. Jesse says:


    I noticed that after I posted...

  28. Jason says:


    Excellent. Hopefully this one will go better than 5.0.50...

  29. @jason

    I have not tested this patch (building 5.0.54 from the MySQL BitKeeper tree now) ... however the patch at the bottom of this bug is supposed to fix the openssl test errors:


  30. Jason says:


    That's excellent news! I'm out of the office right now for the holiday but I'll be trying it out on Wednesday as soon as I get back.

  31. OK ... that patch did work on CentOS-4, all the ssl tests passed and the rpms did build.

  32. @Jason

    FYI ... here is the SRPM I just did for CentOS-4 centosplus repo. It is from the MySQL bitkeeper tree and should be what they released for their Monthly Release Update (plus 2 patches {openssl and a mysqldump bug} ... the changelog has the bug numbers):


  33. Jason says:


    Yeah, the BK sources were what I used for the first Enterprise packages I made after they stopped distributing the sources. It wasn't too difficult, and it worked perfectly, it just took longer.

    In any case, thanks for the link. I'll probably use the code you checked out for my packages (which are basically identical to yours except that the 'mysql-libs' package is integrated with 'mysql').

  34. Jesse says:


    I just upgraded to your 5.0.54-jason.1 and within phpMyAdmin, it shows the following:

    Server version: 5.0.54-log
    MySQL client version: 5.0.48

    Shouldn't these be the same?


  35. Jesse says:

    Nevermind that last post...delete that and this one. My error.

  36. Jason says:


    Nah... I don't delete comments unless they're spam.

    I'm guessing from your second comment that you've already figured this out, but just in case someone else has the same question, the answer is, in this case, no, they should not be the same.

    The client version reported by PHP is lower than the server version because the PHP binaries you are using were compiled while 5.0.48 was installed. If I respun the PHP packages now that 5.0.54 is available then they'd match (except for the "-log" part which is there because you've got the binary log enabled).

  37. Jesse says:


    Actually I had to restart apache...once doing that, the server and client versions matched to 5.0.54.

  38. Patrick says:

    I know this post is a bit old, but just wanted to say PHP has been a huge building block for my site. Unfortunately, I'm still not very good at writing it so I haven't fully unlocked its potential, but I'm getting there!

    Founder, Ubscure.com
    Located at: "Ubscure Article Directory"


Check out what others are saying about this post...
  1. Mighty Linuxz » Upgrading to MySQL 5.0.48 on RHEL and CentOS says:

    [...] read more | digg story [...]

This site is no longer updated. If you have a need for RHEL/CentOS LAMP Stack updates outside the normal channels, I recommend ART. https://updates.atomicorp.com/channels/