MySQL 5.5

[freethought]

Hi Scott and co. thanks for the awesome ART repository I was just wondering if you guys are looking at adding MySQL 5.5 at some point soon? I try to keep the number of repositories we use to a trusted minimum, but we've got a couple of boxes that we think could really benefit from some of the multithreaded performance enhancements that are reportedly in 5.5.

[scott]

Yeah I was checking that out yesterday. Ive never run it myself so I'd be curious on what others experiences with it have been

[Highland]

Looks like Monty has moved on from pure griping about Oracle to running MariaDB (which doesn't seem to have a lot of development). But he offered his thoughts on 5.5 GA
http://monty-says.blogspot.com/2010/12/ ... 55-ga.html

I have been really questioning the future of MySQL lately. Oracle still says it's committed to open source but it seems like more and more resources are being moved away. MariaDB is more or less Monty's attempt to fix what he sees is wrong with MySQL. I still think that Drizzle is going to replace it in the long run because it fragments the core from everything else. They are claiming to have GA by the end of February and there is heavy active development (which Rackspace is funding because they want to use it for their cloud).

[scott]

in that case maybe the path forward is to use atomic-bleeding (we almost never ever use this channel, even internally) for all the latest packages, ie: httpd 2.2.17, mysql 5.5, php 5.3, etc. New packages like maria & drizzle could always go to the atomic channel since they don't overlap.

[Highland]

That explains why there's no asl-bleeding then.

I would certainly welcome that to try out new paths. I've been eying Drizzle mainly because MySQL replication has given us major fits in 5.1. With Drizzle going with a pure modular setup it means we can ditch plugins that don't work (replication, storage engines, logging, etc) and find new ones without ditching the software we're built on (i.e. you would have potentially have packages like drizzle.x.x, drizzle-haildb.x.x, drizzle-rabbitmq.x.x, etc just like PHP). Multicore support is merely icing on the cake at this point.

[scott]

Actually there is an asl-2.0-bleeding channel Thats where 3.0 lives

[RS_Jelle]

in that case maybe the path forward is to use atomic-bleeding (we almost never ever use this channel, even internally) for all the latest packages, ie: httpd 2.2.17, mysql 5.5, php 5.3, etc. New packages like maria & drizzle could always go to the atomic channel since they don't overlap.

Any plans on MySQL 5.5 (or MariaDB)?
As they have better performance compared to MySQL 5.1, I'm interested in experimenting with them.

[scott]

Yup, probably into -bleeding. I know for a fact that plesk is not compatible with 5.5 yet

[RS_Jelle]

I know for a fact that plesk is not compatible with 5.5 yet

That's a problem indeed
What's the exact issue with it?

[aus-city]

Scott,

yes if its not plesk compatible then bleeding. I think php-5.3x and httpd-2.2.17 stay in testing they are compatible and I have them running on a production server. Bleeding needs to be for non compatible rpms, else what is the point of testing, may as well push to stable and users can always yum downgrade.

testing should be run like fedora-testing. Packages that are set for stable and are simply there for testing and final QA. It should be safe to enable testing channel if your prepared to yum downgrade on an issue.

bleeding need to be like rawhide future development

[scott]

Its an SQL syntax error, happening on an upgrade event as I recall.

[RS_Jelle]

It's fixed in Plesk 10.2:

61. [-] Issue resolved: If MySQL 5.5 was installed on the server, Panel installation or upgrade failed because Panel tried to use a deprecated option to configure it.

http://download1.parallels.com/Plesk/PP ... htm#10.2.0

[scott]

Yeah, I saw that one yesterday too. Its good news