Here’s the background: I’m testing many features of MySQL 5.6.7-RC due to two reasons:
- I’m verifying my common_schema installs and works properly on 5.6
- I promised I would present a 45 minute “what’s new in MySQL 5.6” seminar in the upcoming OracleWeek (Israel)
In the case of common_schema, I have managed to find one weird bug (a behavior regression from 5.5) and one server-crashing bug, by merely running the project’s tests, known to pass on 5.1 and 5.5 (and not utilizing any 5.6 features).
In the case of my presentation, I’m getting acquainted with new syntax and functionality, and am getting unexpected results. I’ve hit replication issues and locking issues in online DDL.
If I am able to find these bugs within a few hours of experimenting & testing, then it is safe to assume we can extrapolate to many more bugs. This is not surprising; 5.6 boasts some 120 new features (I didn’t actually count them). Of course they would introduce new bugs.
The moral is this: if you’re interested in 5.6 as I am – and there’s a lot to wait for – please consider experimenting with it, and report as many bugs to bugs.mysql.com as possible. Reporting bugs is the user’s authoritative way of improving an open source product and pushing towards a stable release. Provide your feedback today!
Quora, yes, there are some pretty major places that are already making some use of 5.6 in production, typically with substantial throughput improvement. It’s part of how we’re getting some excellent feedback about irritations and bugs. We also know of others that are well into testing migration to it.
If you’re not trying it yet and have lots of servers, please consider at least running a few replication slaves on it so you can be sure that you’ll quickly find out about any issues that affect you and can file any related bugs. If you only have one production server, now would be a nice time to set up a low power slave that you can use to verify at least some compatibility with your applications.
We expect to find some new crash bug reports during RC. The first RC is when we tend to see a lot of people who haven’t previously looked trying it. And naturally that exposes more code paths and causes some more bugs to be found. Our internal testing is still what finds the largest number of issues but it has much less variety of code than all users of MySQL combined.
There’s another surge just after GA, when use again increases substantially and more combinations get exercised.
Part of the purpose of my act NOW blog post was to encourage people to get in early, so that we get things reported earlier in the process. You’re probably in an excellent position to do some of that, so you’ll be able to benefit from the performance and other improvements sooner after GA.
You should look to 5.6 to see what it can do to decrease the rate at which you’re spending money on new servers to keep up with growth.
That doesn’t mean that you should jump in without extensive testing but it does mean that you have a good chance of saving significant amounts of money if you’re regularly buying new servers or using increasing numbers of instances on cloud services.
Justin, if something could potentially be used in some form of attack it’s likely that Oracle will mark it private to avoid giving clues to anyone hostile. Any crash bug that has a predictable set of SQL to cause it is likely to be treated this way. It can be frustrating but it beats alternatives like telling black hats about unfixed problems and providing them with ready to use attack scripts via our test suite. At least for this one you could ask Shlomi to confirm that making it private conforms to standard industry practice, so you know we’re not doing it without good cause.
M, in 5.5 you might start by exploring Performance Schema from http://dev.mysql.com/doc/refman/5.5/en/performance-schema-instance-tables.html . Then move on to http://dev.mysql.com/doc/refman/5.5/en/setup-instruments-table.html and finally to http://dev.mysql.com/doc/refman/5.5/en/setup-instruments-table.html that tells you what is instrumented so you can monitor it. All those in 5.5 but you’ll find that more things are instrumented in 5.6 than in 5.5. You may find http://dev.mysql.com/doc/refman/5.6/en/performance-schema-instrument-naming.html useful when trying to understand the instrument names.
If you do find something not instrumented that you need to observe, please file a bug report to let us know about it. There’s a lot to learn about the power that PS exposes and it’s worth spending some time with it.
Views are my own, for an official view, seek a PR person.
James Day, MySQL Senior Principal Support Engineer, Oracle
James,
I understand that Oracle doesn’t want black hats to be a problem but seriously, if I want to test my app and there is a crash, I should be able to see if the crash has already been reported by someone else!
Also, what if I want to look for open 5.6 bugs and try to fix them myself? MySQL is supposed to be open source.
Hiding bugs is just wrong, in my opinion. Information should be free.
Justin,
Say I trust you and write you a check for a prize for finding a bug in a programming book I write. That works well, except… even with such limited distribution, Knuth found that people were abusing the details on the checks to commit fraud on his bank account. If you don’t know the Knuth story, see http://sunburn.stanford.edu/~knuth/news08.html . He could have tried to tell just people he thought he could trust but he already had a pretty high hurdle and that wasn’t working. So he picked an alternative non-discriminatory approach instead.
That’s sad but it’s the reality of a world with some unpleasant people in it.
If you get such a crash please do just what I’d do: file the bug anyway and let those who have a need to know see if it’s a known issue or not.
If you want to fix such bugs, please do. You’ll have to find them yourself, first.
Views are my own, for an official view, consult a PR person.
James Day, MySQL Senior Principal Support Engineer, Oracle