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?

    Reply
  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…

    Reply
  3. 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!

    Reply
  4. 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.

    Reply
  5. 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

    Reply
  6. 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)

    Reply
  7. Kemal Sahin

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

    Please update them with mysql-5.5.18 release

    Reply
  8. Kemal Sahin

    When we want to compile a udf with this command
    gcc -shared -o ats.so -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 mysql.com’s generic linux distro for 5.5.18 it worked fine.

    Reply
  9. 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.

    Reply
  10. 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 – https://github.com/Sannis/node-mysql-libmysqlclient/issues/105. 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 :)

    Reply
  11. 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.

    Reply
  12. 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?

    thanks.

    Reply
  13. Joe Auty

    Hello,

    Thanks for making these packages available!

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

    Reply
  14. 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)

    Reply
  15. Guillaume Plessis

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

    Also,
    - 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.

    Reply
  16. Joe Auty

    Hello,

    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
    mysql-server-5.5
    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)
    (…)
    mysql-client-5.5
    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)
    (…)
    libdbd-mysql-perl
    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

    Reply
  17. Joe Auty

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

    The libmysqlclient18 pkg seems to also be missing /usr/lib/libmysqlclient_r.so.18 and /usr/lib/libmysqlclient_r.so.18.0.0 as well,

    Reply
  18. 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.

    Reply
  19. 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 _r.so for libmysqlclient16 then, right?

    Reply
  20. Webmaster Eddie

    Hi,

    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?

    Thanks

    Webmaster Ed

    Reply
  21. Webmaster Eddie

    Hello,

    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

    Reply
  22. 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/mysqld.pid ended

    Reply
  23. 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).

    Reply
  24. 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, tuning-primer.sh and mysqltuner.pl – 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

    Eddie

    Reply
  25. Webmaster Eddie

    Hello,

    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

    and

    ■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.

    Eddie

    Reply
  26. 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 : http://www.php.net/manual/en/datetime.configuration.php#ini.date.timezone

    Reply
  27. 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/solr.so 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

    Eddie

    Reply
  28. 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.
    MASTER_SSL=1, MASTER_SSL_CAPATH=”, MASTER_SSL_CA=”, MASTER_SSL_CERT=”, MASTER_SSL_KEY=’crap’

    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.

    Reply
  29. 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.

    Reply
  30. 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

    Reply

Leave a Reply

  • (will not be published)


eight − 2 =