Categories
MySQL

MySQL 5.5.18 is out

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 replies on “MySQL 5.5.18 is out”

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?

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…

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!

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

By Post Author

@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

By Post Author

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)

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

Please update them with mysql-5.5.18 release

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.

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

By Post Author

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 🙂

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

By Post Author

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.

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.

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)

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

By Post Author

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

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,

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

By Post Author

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?

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

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

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

@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).

By Post Author

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

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

@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

By Post Author

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

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.

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

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

Comments are closed.