Of the many things I noticed last week at the MySQL Conference, one of the most notable was how many companies have not upgraded from MySQL 5.0 to 5.1 yet. Craigslist is in that camp and it seems that we're joined by the likes of Facebook, Google, Yahoo, and about half a dozen other companies that use MySQL heavily.

Come to think of it, SmugMug are the only folks I've talked with who've made the jump (video).

So it's not much of a surprise that Percona is asking if they should backport 5.4 fixes to 5.0.

Given our usage of MySQL to date, the only really compelling reason to upgrade is to get access to the InnoDB plug-in (and XtraDB). I'd like to get compression, some of the various performance patches, and tuning options, so plug-in support is a requirement. But beyond that, I just don't see anything new in 5.1 that we need.

As I noted in The Real or Official MySQL? Does Not Matter!, the storage engines matter more than the various add-on features in the server itself.

Have you upgraded or are you thinking about it? If so, why? If not, why not?

Posted by jzawodn at April 30, 2009 08:00 AM

Reader Comments
# Mark Callaghan said:

5.1 is very compelling for me because of partitioning and incredibly compelling because of the InnoDB 5.1 plugin and XtraDB.

But upgrading takes a very long time.

on April 30, 2009 08:57 AM
# Ryan Lowe said:

I've got a few customers who have made the jump to 5.1. Without exception, partitioning was the primary motivating factor. Personally, I'm still on 5.0, will probably make the switch within the year.

on April 30, 2009 09:12 AM
# Scott Metcalf said:

Isn't that just remaking 5.4? Any version migration is work and risk so jumping on a patched up version of 5.0 seems like more work and risk. Although I do see a situation where a delayed GA supported release of 5.4 could push people to a 5.0 patched up GA supported fork.

on April 30, 2009 09:14 AM
# Emmanuel D├ęcarie said:

I needed to store XML and be able to do xpath queries against it. So I had no choice than to update to MySQL 5.1 or choose another database. I must say that I'm very happy with this choice, and I'm able with the new MySQL XML functions to implement a system that use MySQL as an almost free-form database, i.e. modifying a Web form without the need to modify whatsoever the DB schema or any configuration files (like in Rails). I did the update on FreeBSD 6.3 with the ports system and it went well, although it took some preparation. On OS X, on my dev box, I used the package format provided my MySQL and the upgrade went also very well.

http://dev.mysql.com/tech-resources/articles/mysql-5.1-xml.html

on April 30, 2009 09:54 AM
# Arjen Lentz said:

We mainly regard 5.1 as an improved 5.0, although for some clients the partitioning is useful. The plugin architecture for storage engines also provides opportunity, for instance for checking out PBXT, and the InnoDB plugin (or XtraDB in 5.1)
That said, 5.1/5.4 is fairly similar from my perspective in terms of "desire to upgrade".

on April 30, 2009 04:49 PM
# joe p said:

We designed a few applications based on partitioning that we went production with in fall 2007 on 5.1.19. We had very little problems and only very minor issues. We now run most of our production databases on 5.1 and should be totally converted to 5.1 this fall.

on April 30, 2009 10:37 PM
# Philip said:

Actually at Y! we skipped right over 5.0 and made the jump from 4.1 to 5.1.

on May 1, 2009 07:52 AM
# Jeremy Zawodny said:

Philip:

Interesting. I guess I'm hearing conflicting stories then. Not surprising, given the size of Yahoo. I guess the real numbers would come from packagedb (or whatever it may be called nowadays).

on May 1, 2009 08:13 AM
# Sheeri K. Cabral said:

I share the same view as Arjen. When a client needs to upgrade their 5.0 version for some bug, we recommend just jumping to 5.1. Sure, you don't have to upgrade if you don't need the features, but remember that 5.0 support is ending in about 6 months. And this mentality would have many people still on 3.23.26 (when replication first started really working...)

About half our clients have switched. The upgrade is pretty painless, though there are important things to note, it's not that much different from a regular minor version upgrade. (I even have a list of "things to know when upgrading" at http://www.pythian.com/news/1414/new-in-mysql-51-sheeris-presentation )

I don't think it's worth backporting to 5.0. Many people have a fear of upgrading to a new release series because the 4.1 -> 5.0 switch was so very painful. But 5.0->5.1 has been relatively painless for all our clients that have switched. (of course, they also tested a lot...)

on May 1, 2009 12:13 PM
# Shlomi Noach said:

Hi,

I've had customers using 5.1 while in late beta stage, and in two cases had fatal server crash (signal 10/signal 11). A downgrade to 5.0 helped out in their case.
I would guess by now 5.1 should be stable enough.
For me, a must-have in 5.1 is the ability to dynamically turn general_slow logs on/off... such a simple yet important feature.

I will probably jump next to 5.4 (assuming it is GA soon enough)

on May 2, 2009 11:29 PM
# Justin said:

Twitgoo is running on all 5.1 - Photobucket is close to upgrading a bunch of databases. For twitgoo, having query cache on prepared statements is hugely awesome, and for Photobucket we're going to take advantage of partitioning and some of the pluggable engines.

on May 3, 2009 08:50 AM
# Log Buffer said:

"Jeremy Zawodny wants to hear your thoughts on the question, is MySQL 5.1 a compelling upgrade?"

http://www.pythian.com/news/2393/log-buffer-145-a-carnival-of-the-vanities-for-dbas

on May 8, 2009 12:49 PM
# Waleed Eissa said:

One nice new feature in 5.1 is the event scheduler

on May 25, 2009 08:55 AM
# Kent Davidson said:

MySQL 5.0 was causing consistent, regular index corruption on a large index table with a 32-character key pretty much every day, a few times a day. My application code would auto-repair the tables, but it was becoming a nightmare, even after I reduced the concurrency as much as possible, and even modified the code to bracket all updates between locks.

After upgrading to 5.1 (aside from a few tables getting messed up in the upgrade) the problems went away.

So, I would recommend upgrading if you have any issues with index corruption in big tables.

on July 5, 2009 08:02 PM
# said:

i am extremely unhappy with MySQL 5.1. I upgraded half of our production servers to MySQL 5.1 and stop upgrading because we are facing performance issues, queries are stucking on regular intervals and when i kill particular thread to minimize the query queue then processlist state shows killing but it still comes in processlist. Also when there processlist queue grows heavily mysql doesn't restart.

We directly upgraded from MySQL 4.1.22 to MySQL 5.1.32. And we are quite happy with MySQL 4.1.22. I need to upgrade because of new features. We have all of our db tables on MyISAM. Please help me out on this.

Thanks,

on September 13, 2009 01:51 PM
Disclaimer: The opinions expressed here are mine and mine alone. My current, past, or previous employers are not responsible for what I write here, the comments left by others, or the photos I may share. If you have questions, please contact me. Also, I am not a journalist or reporter. Don't "pitch" me.

 

Privacy: I do not share or publish the email addresses or IP addresses of anyone posting a comment here without consent. However, I do reserve the right to remove comments that are spammy, off-topic, or otherwise unsuitable based on my comment policy. In a few cases, I may leave spammy comments but remove any URLs they contain.