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…
why is the download of packages from dotdeb limited to 30kb/s? Its really slow. >_>
10 Minutes for 8,2 MB.
@Maltris : the main Dotdeb mirror is hosted at online.fr. Sadly, some ISP (OVH, for example) have restrictive traffic policies. Maybe you can try another mirror.
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.
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
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
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
@Kemal Sahin : could you be more specific/precise, please?
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.
Do you still maintain/update the MySQL 5.1 packages?
@Jpae: Yes, I am, depending on what’s available in Debian Sid or experimental. 5.1.58 at this time.
@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.
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.
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
@dpdt1 : please do not dump the virtual database called performance_schema.
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.
– 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.
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: libc6 (>= 2.4)
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: perl (>= 5.6)
Depends: zlib1g (>= 1:1.1.4)
PreDepends: adduser (>= 3.40)
PreDepends: mysql-common (>= 5.5.18-1~dotdeb.1)
Depends: debianutils (>= 1.6)
Depends: libc6 (>= 2.11)
Depends: libdbd-mysql-perl (>= 1.2202)
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: 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)
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,
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.
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?
@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.
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 Eddie: have you run the mysql_upgrade command to upgrade to MySQL 5.5?
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
@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.
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).
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
@Webmaster Eddie : just comment the lc-message-dir line in my.cnf and restart mysql. Just tell me if it fixes your issue .
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.
You can (and should) get rid of those timezone warnings by defining your timezone in your php.ini files.
@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
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
@Webmaster Eddie : about solr, there’s no link with previous comments about missing libraries in the MySQL packages. You’ll have to build your own PHP-5.3.8-compatible php5-solr package, following these steps :
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