Posted by & filed under MySQL.

MySQL 5.5.18 has been released by Oracle yesterday. The packages for Debian 6.0 “Squeeze” are now available on Dotdeb for both amd64 and i386 architectures.

As usual, please read the full Changelog carefully before upgrading.

Please also note that Oracle now provides .deb packages on their download page. That’s a great thing, but they’ll have to be improved :

  • no repository is available to ease the future updates
  • they’re monolythic and do not separate libraries from headers or binaries, configuration from server or client.
  • they do not take care of the official Debian naming convention

42 Responses to “MySQL 5.5.18 is out”

  1. t

    I have two problems.
    1. Is there any solution for disabling csv and mrg_myisam engines?
    2. Before this update the ssl parameter was set to true in phpMyAdmin config file but now it has to be set to false? Is there any reason for doing it?

  2. Sam

    MySQL wouldn’t start for me after the upgrade:

    #007/usr/sbin/mysqld: File ‘./mysql-bin.000074’ not found (Errcode: 13)

    The following command allows mysql to start:

    chmod 775 -R /var/lib/mysql

    However, running sudo apt-get upgrade still lists mysql as not being properly installed and attempts to start the service, which always fails with the same error.

    Seems like a permission problem but I’m not sure how to fix it…

  3. Maltris


    why is the download of packages from dotdeb limited to 30kb/s? Its really slow. >_>

    10 Minutes for 8,2 MB.

  4. Guillaume Plessis

    @Maltris : the main Dotdeb mirror is hosted at Sadly, some ISP (OVH, for example) have restrictive traffic policies. Maybe you can try another mirror.

  5. Offsuit

    Didn’t the dotdeb packages used to be compliled with –without-readline (do not use the bundled readline, which uses the crappy editline library)? Did you stop using that config option for some reason, or is it just an oversight? Here’s one request for you to please return to compiling a readline enabled client package, ASAP!

    # mysql –version (dotdeb 5.1.58)
    mysql Ver 14.14 Distrib 5.1.58, for debian-linux-gnu (x86_64) using readline 6.1
    # mysql –version (dotdeb 5.5.18)
    mysql Ver 14.14 Distrib 5.5.18, for debian-linux-gnu (x86_64) using EditLine wrapper (sad face)

    Thanks for your consideration!

  6. Guillaume Plessis

    @Offsuit : MySQL 5.5 does not use the same configuration tools as MySQL 5.1. This switch from autotools to cmake forced me to translate each former configuration option to new ones . Readline correct support has been forgotten. I’ll fix it in my next uploads.

  7. Guillaume Plessis

    @t :
    1. After looking at the documentation, there no way to disable the CSV and MRG_MyISAM storage engines without recompiling MySQL 5.5. Do they really bother you?

    2. To use SSL, you have to set the ssl_ca, ssl_cert and ssl_key parameters with valid information

  8. Phil

    SSL connections appear to be broken in these packages:

    # mysql -h *** -u *** -p –ssl –ssl-ca=/etc/mysql/ca.pem –ssl-cert=/etc/mysql/***.cert –ssl-key=/etc/mysql/***.key
    Enter password:
    ERROR 2026 (HY000): SSL connection error: error:00000001:lib(0):func(0):reason(1)

  9. Kemal Sahin

    You have put the wrong include files to /usr/lib/mysql/

    Please update them with mysql-5.5.18 release

  10. Kemal Sahin

    When we want to compile a udf with this command
    gcc -shared -o -I /usr/include/mysql ats.c -fPIC

    we get the error

    /usr/include/mysql/my_pthread.h:832:36: error: mysql/psi/mysql_thread.h: No such file or directory

    if you check the /usr/include/mysql/ you cannot find the psi directory and updated include files. We have updated the include files with’s generic linux distro for 5.5.18 it worked fine.

  11. Guillaume Plessis

    @Offsuit : your issue will be fixed in the next MySQL 5.5 packages.
    @phil : I’m looking at it. I need to do some more tests to find a fix.
    @Kemal Shain : the same thing happens in the official MySQL 5.5 Debian packages. I’m looking for a fix and I’ll report a bug report (and maybe the fix) to Debian.

  12. SonicGD

    Hello. We have problem with your mysql-5.5 package. mysql-libmysqlclient for node.js can’t find libmysqlclient_r and libmysqlclient. You can read full issue here – I have install mysql_server and libmysqlclient-dev and i get that error. But, if i install (or just extract and add to PATH) mysql from official debian package – error is gone. I hope you can fix this problem, because official package so… not debian 🙂

  13. Guillaume Plessis

    @SonicGD : it seems to be the same issue as Kemal Shain’s one.

    The libmysqlclient-dev package (version 5.5.18) from Dotdeb does not include some needed header files. I’m still investigating why (it happens in the official Debian packages too). This issue should be fixed in the next release.

  14. dpdt1

    just upgraded mysql from version 5.1 today and mysqldump (from backupninja) gives the following error :

    Warning: mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user ‘debian-sys-maint’@’localhost’ for table ‘cond_instances’ when using LOCK TABLES

    Warning: Failed to dump mysql databases performance_schema

    any ideas?


  15. Joe Auty


    Thanks for making these packages available!

    Shouldn’t your libmysqlclient-dev package create a /usr/lib/ file/symlink? I was having problems with some Ruby stuff that was wanting to build against this missing file.

  16. Joe Auty

    Also, shouldn’t mysql-server depend on libmysqlclient18 rather than libmysqlclient16? Otherwise, there is a version mismatch of server/client libraries (5.5.18 server, 5.1.58 client)

  17. Guillaume Plessis

    @Joe Auty :
    Some headers and symlinks are missing from the libmysqlclient-dev (5.5) package. I’m working on it.

    – mysql-server (5.1) depends on libmysqlclient16 as it should
    – mysql-server (5.5) does not depend on any libmysqlclient package

    Just be sure to install the same branch on the server and the client sides.

  18. Joe Auty


    mysql-server-5.5 does indeed depend on libmysqlclient16. I’m not saying it should, but it does now as you can see:

    # apt-rdepends mysql-server-5.5
    Reading package lists… Done
    Building dependency tree
    Reading state information… Done
    Depends: debconf (>= 0.5)
    Depends: debconf-2.0
    Depends: libc6 (>= 2.4)
    Depends: libdbi-perl
    Depends: libgcc1 (>= 1:4.1.1)
    Depends: libssl0.9.8 (>= 0.9.8m-1)
    Depends: libstdc++6 (>= 4.1.1)
    Depends: lsb-base (>= 3.0-10)
    Depends: mysql-client-5.5 (>= 5.5.18-1~dotdeb.1)
    Depends: mysql-server-core-5.5 (= 5.5.18-1~dotdeb.1)
    Depends: passwd
    Depends: perl (>= 5.6)
    Depends: psmisc
    Depends: zlib1g (>= 1:1.1.4)
    PreDepends: adduser (>= 3.40)
    PreDepends: debconf
    PreDepends: mysql-common (>= 5.5.18-1~dotdeb.1)
    Depends: debianutils (>= 1.6)
    Depends: libc6 (>= 2.11)
    Depends: libdbd-mysql-perl (>= 1.2202)
    Depends: libdbi-perl
    Depends: libgcc1 (>= 1:4.1.1)
    Depends: libncurses5 (>= 5.7+20100313)
    Depends: libssl0.9.8 (>= 0.9.8m-1)
    Depends: libstdc++6 (>= 4.1.1)
    Depends: mysql-common (>= 5.5.18-1~dotdeb.1)
    Depends: perl
    Depends: zlib1g (>= 1:1.1.4)
    Depends: libc6 (>= 2.4)
    Depends: libdbi-perl (>= 1.610.90)
    Depends: libmysqlclient16 (>= 5.1.21-1)
    Depends: perl (>= 5.10.1-13)
    Depends: perl-dbdabi-94
    Depends: perlapi-5.10.1

  19. Joe Auty

    Also, I tweeted this to @dotdeb, but just for your convenience:

    The libmysqlclient18 pkg seems to also be missing /usr/lib/ and /usr/lib/ as well,

  20. Guillaume Plessis

    @Joe Auty:
    mysql-server-5.5 does *not* depend directly on libmysqlclient16.
    The fact is that mysql-client-5.5 depends on libdbd-mysql-perl and that this last package, from the official Debian distribution, depends on libmysqlclient16.

    Anyway, having libmysqlclient16 and libmysqlclient18 on the same system is not a big deal and doesn’t lead to any conflict or bug. I won’t backport libdbd-mysql-perl to avoid this minor dependency.

    Thanks for the report on libmysqlclient18.

  21. Joe Auty

    Ahh, okay… I stand corrected then!

    The Ruby on Rails stuff I’m doing was probably complaining about the version mismatch because it was only finding the for libmysqlclient16 then, right?

  22. Guillaume Plessis

    @Joe Auty : yep, missing headers in the libmysqlclient-dev 5.5 package may have led to wrong linking and dependency. I hope releasing fixed packages soon.

  23. Webmaster Eddie


    I just made the mistake of upgrading to php 5.3.8 because 5.3.3-7 wouldn’t work with a client’s wordpress site, and I added your repositoru to my sources.list and mistakenly also upgraded mysql and now mysql won’t start. I was running 5.1.49 just fine. I tried the “fix” to chmod 775 -R /var/lib/mysql – but that doesn’t help me start mysql.

    I am running deb squeeze

    Should I just wait a day (max) and run apt-get update and upgrade? Should that solve my problem, or,

    is there a way to revert back to the former mysql?


    Webmaster Ed

  24. Webmaster Eddie


    No, I just figured out that I hadn’t actaully upgraded mysql – I did an aptitude full-upgrade and discovered that I hadn’ actually upgraded. So I did the upgrade, and mysql has started again – thanks for your help.

    All this because a client insisted on a wordpress site that didn’t w<ork – now i'm back to hand coding and drupal; Thanks

  25. Guillaume Plessis

    @Webmaster Eddie : please take a look at /var/log/syslog and search for what’s going wrong during the mysql startup. It’s usually verbose enough.

  26. Webmaster Eddie

    I think this is the relevant portion of the syslog when the problem began:

    Dec 8 09:01:12 server1 mysqld: 111208 9:01:12 [ERROR] /usr/sbin/mysqld: unknown variable ‘lc-messages-dir=/usr/share/mysql’
    Dec 8 09:01:12 server1 mysqld: 111208 9:01:12 [ERROR] Aborting
    Dec 8 09:01:12 server1 mysqld:
    Dec 8 09:01:12 server1 mysqld: 111208 9:01:12 InnoDB: Starting shutdown…
    Dec 8 09:01:17 server1 mysqld: 111208 9:01:17 InnoDB: Shutdown completed; log sequence number 1 1016904597
    Dec 8 09:01:17 server1 mysqld: 111208 9:01:17 [Note] /usr/sbin/mysqld: Shutdown complete
    Dec 8 09:01:17 server1 mysqld:
    Dec 8 09:01:17 server1 mysqld_safe: mysqld from pid file /var/run/mysqld/ ended

  27. Guillaume Plessis

    @Webmaster Eddie : you only upgraded mysql-common, not mysql-server (it’s stuck to 5.1). Then, as said in previous comments, just comment the lc-message-dir line in /etc/mysql/my.cnf. You only had to read 🙂

    (I’ll edit your comment to make it less huge and to keep only the relevant information in it).

  28. Webmaster Eddie

    The only other relevant info I can give oyu is that when I upgraded php I choose to always take the new php.ini iles – for all 3 /apache2/, /cgi/ and /cli/ – then I made adjustments to vastly increase memory size (from 128 to 1280 MB)and added lines for extensions – just uploadprogress and solr

    also, I had previously optimized mysql to vastly increase the bufer sizes – ollowing the advice of 2 mysql optimization scripts, and – in which I increasd the join_buffer_size and table_cache and innodb_bufer_pool_size and query_cache_limit query_cache_size table_definition_cache and table_cache

    the info in the syslog before the quoted part, above is all postfix and mail virus scan stuff working fine, and after that it is all postfix errors as it can no longer connect – i hat will help you, i’ll upload that, too


  29. Webmaster Eddie


    No I did update mysql server to 5.5.18 – that’s what my command line status call gives me. I don’t know if I have a problem currently – mysql is running and restarts ok.

    That line you speak about is uncommented – why should I comment it out? IS it necessary or important? Isn’t it there for a good reason?

    Maybe it wasn’t clear that I gave you the portion of the syslog relevant to when the problem began – exactly when i upgraded php to 5.3.8 i think. At that poin I was still running mysql 5.1.49 community – since then >I have successfully upgraded to 5.5.8

    Seems to be working fine now, except aegir in drupal is showing lots of errors about

    â– warning: mktime(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Europe/Berlin’ for ‘CET/1.0/no DST’ instead in /var/aegir/hostmaster-6.x-1.6/profiles/hostmaster/modules/hosting/site/hosting_site.module on line 513


    â– warning: strtotime(): It is not safe to rely on the system’s timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘Europe/Berlin’ for ‘CET/1.0/no DST’ instead in /var/aegir/hostmaster-6.x-1.6/profiles/hostmaster/modules/hosting/task/hosting_task.module on line 284.

    I think I noticed somehting different about time in the new php.ini files that came with php 5.3.8 and that might have something to do with these errors.


  30. Guillaume Plessis

    @Webmaster Eddie : the “‘lc-messages-dir” mention in your log files was related to MySQL 5.1. Glad that MySQL 5.5 works fine now. You can leave this line uncommented.

    About the date.timezone PHP warning, you have to follow what is says and set it explicitly in your php.ini. Previous Dotdeb packages and Debian official were patched and relied on the system timezone. They’re not anymore and now you have to configure PHP. That’s a common PHP warning, it’s not Dotdeb specific. Here is the doc :

  31. Webmaster Eddie

    Yes, I was getting around to that – with this new php I just had to uncomment the date setting and set it. Thanks.

    There may still be an error with the new php 5.3.8 as I am getting the error never before encountered:

    PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20090626/ cannot open shared object file : No such file or directory in Unknown on line 0

    Well, I am running solr, and the library is there, so I am looking into permissions problems for my user aegir – that is when I am encounteing the problem. I mention it because in this post there was a lot of talk about correct libraries, etc …

    I’ll report back


  32. terii

    For those with broken SSL. You need to leave out everything except for “ssl-key”.

    mysql -h XXX.XXX.XXX.XXX -u ssl -p –ssl-key=crap

    Same for replication.

    Yes, specify “crap” and not the actual key actually works. Not sure what Oracle did to SSL in MySQLd, but looks like it’s broken.

  33. Phil

    @terii Thanks, I’ll give this a try.

    I’m not convinced it’s a MySQL change though, at work we use 5.5.18 in production and make SSL connections without issue.

  34. Derick Dorner

    Okay found the problem… the (yum) upgrade to 5.5.18 creates a new my.cnf file and saves your OLD my.cnf file has my.cnf.rpmsave with a funny date. When you have SSL installed the upgrade process occasionally fails to xfer your SSL settings over to the new my.cnf file. Fixing this, along with regenerating a few keys and verifying that users had correct SSL type ANY and voila! All fixed and we’re running SSL once again.
    If anyone would like some help with this I can be contacted at D (AT) TRIQQER (DOT) COM