Sunday, May 26, 2013

Fun with bugs #7, still mostly about 5.6.11

It looks like now Oracle will release new 5.6.x every 2 months, so while I'd happily write about bugs fixed in 5.6.12 we still have to wait for the official release to happen. I am too impatient to wait for 5.6.12, so let me write this post of a classical kind - just a summary of my MySQL bugs' related posts on Facebook since the previous one.

I have to start with replication-related bugs in 5.6.11 pointed out by Giuseppe Maxia:
  • Bug #69095 -  replication fails with GTID enabled and master changes from SBR to RBR. This bug is "Verified" since April 30, but got no public comments since that.
  • Bug #69135 - mysql.slave_master_info is not updated. This serious bug is verified since May 6, but, again, got no visible attention since that.
It's really sad, but looks like most of new replication features (GTID-based replication and "crash safe" replication are among them) in 5.6 works well only in simple cases and, in general, were not really well tested before GA (no matter what explicit or hidden messages about MySQL-related QA activities Oracle makes).

While searching for something else, I've noted Bug #60101 in "Patch pending" status for more than 2 years. As usual, I've complained in public and got this bug... "Closed" with a comment saying nothing about specific versions where the fix first appeared. Well done, Sinisa, really, but this bug report is still a yet another example showing that Oracle does NOT always care to keep public bugs database in sync with real development and follow their own procedures of bugs processing. Unfortunately...

And now back to performance that 5.6.x is all about. Mark Callaghan had not only reported in public about his findings on singe-thread performance of 5.6.11 (in Bug #69236), but later had provided a detailed enough analysis showing that it's not only a client or UTF-8 related problem, but something else as well... Still the bug is "Open" since May 15. I had written about it at least 3 times, but it seems this does not help any more to get anybody's attention. I wonder should I become more annoying blogger again and publish new "Fun with Bugs" issue every week.

Obviously I was so impressed by "300 man-years of QA experience" Oracle now invests into MySQL (statement from famous keynote session Tomas Ulin gave during PLMCE 2013) that now I pay extra attention to every bug report that points out some problem with tests that QA engineers are supposed to run. Here are the recent examples:

Bug #69252 - All the parts.partition_max* tests are broken with MTR --parallel. If nobody ever tried to run these tests with --parallel (as it seems), then we can safely assume that nobody cared to run them at all in production, as "--parallel" feature was added (long time ago) to make test runs faster in production environment...
Bug #69265 - -DBUILD_CONFIG=mysql_release -DWITH_DEBUG=ON fails 4 and skips 27 MTR tests. Similar situation - if nobody runs tests on debug builds on a regular basis (as it seems), what QA is really doing instead? This bug report is still "Open".

One may say that all these problems are known internally and are in the internal bugs database (reported long time ago), but I have no way to verify this kind of statement, so feel free to ignore it if it ever made. Make your own conclusions, but personally I do not understand how or why quality may increase without regular testing. Fortunately, many community members had NOT given up yet and continue to report bugs and test failures - this gives me some more hope to see MySQL 5.6 as the "best release ever" one day.

On a positive side, InnoDB team rocks as usual when they see useful bug report. Check Bug #69276 - it was accepted and verified by developers in a matter of hours.

Surely there are things to note in older MySQL server versions as well. Recently my Bug #67259 had got more evidence from my colleague (as customers continue to hit it or something similar to it), so note that the problem is still repeatable on Oracle's MySQL 5.5.31 as well.

I'd like to end this post with a word of warning about Federated storage engine. It is still able to provoke crashes, like in Bug #68354, and users hit these crashes in production. Unfortunately Oracle is hardly going to fix any bug in this storage engine (or any other storage engine but InnoDB actually), so here MariaDB may be our only hope. Others would just happily remove it once and forever, while I am not sure there are good alternatives for all use cases it covers...

That's all for now. I skipped "funny" reports, "not a bugs" and hot discussions not really interesting to anybody but participants this time. Let's hope next release of "Fun with Bugs" will be about great fixes in MySQL 5.6.12.

Monday, May 20, 2013

More details on "MySQL 5.6 Experiences" coming soon...

I've already shared my presentation few hours before I made it during PLMCE 2013, back on April 24. The idea behind the presentation was simple (and I think that any MySQL user who is planning to upgrade to MySQL 5.6.x in production should do something like this): let's read the "What Is New in MySQL 5.6" manual page and check new features one by one.

This is what I am going to do with the content of that manual page in the upcoming blog posts (and what was done as background work for the presentation):
  • Remove extra details and add references to each major feature
  • For every feature description add extra references (articles about the feature, bugs related to the feature).
  • Add some comments based on personal experience (if any)
References in the presentation are "tagged" with "#" (if they are about bugs), "?" (if they are about problems either solved with this new feature or appearing because of the way this new feature is implemented or operates with other features or typical user assumptions) or with "!" (if they are about solutions, HOWTOs or explanations on how to use new features in the best way, or describe positive experience with this new feature). This way you can easily pick up what to read, depending on your needs and preferences. Some people, like me, prefer to be informed about problems, while others care mostly about positive experience.

During the upcoming weeks I plan to explain every slide in more details (as 50 minutes were not enough for this) here, grouping them by topics (security improvements, InnoDB improvements etc) and check status of all the active bugs mentioned in it (it makes even more sense now, when 5.6.12 is released). I'll also check and comment on new bugs for each major feature mentioned (if any).

The goal of this upcoming series of posts ("MySQL 5.6 Experiences") is to give enough information and references for any interested MySQL user to be able to decide if any of new features are important and mature enough to be used in production and, thus, does it really make sense to upgrade to MySQL 5.6 right now. I do not want to just share optimistic "the best release ever" or pessimistic "buggy and not mature to be used in production" statements - I want to provide some background.