A third built-in extension point for MySQL Connector/J is the ExceptionInterceptor interface.  This is the third extension point covered in my recent JavaOne and Silicon Valley Code Camp presentations, and is very useful for diagnosing specific Exceptions encountered without modifying application-side code. This corresponds to slide #60 in my slide deck, and there are two Java files we’ll reference from my demo code:

• demo.connectorj.ExceptionInterceptorExample
• demo.connectork.plugins.ExampleExceptionInterceptor

To …

Ever hear of Red Hat Enterprise Linux 6.0? It was released on November the 10th of 2010 . . just over a year ago. In the last couple of days Oracle released the latest version of MySQL Server (5.5.18). Along with the bug fixes, etc they released RPM packages that cover RH EL 6.

Finally. A year later.

Not one given to griping, but really..does it take that long to roll packages for the new version? There were no significant changes in the operating system..in fact the RH EL 5 packages worked on RHEL 6 from my (albeit) limited experience with the combination.

I don't jump onto new versions of operating systems as soon as they come out. I prefer to let others be my beta testers before I put something into production. However, waiting a year seems a bit extreme for this release.

Even so, it's out now so enjoy! Now we have no excuse for not deploying 5.5.

km

…

Now that InnoDB is the default storage engine in MySQL, is it time to update the default configuration for the InnoDB log file size (innodb_log_file_size) setting?

In general, there are two settings that simply can’t be left at their historical defaults for a production installation. MySQL 5.5 increased the default buffer pool size to something more sane (128MB instead of 8MB), but the log file size remains at 5MB. That’s 10MB total, because there are two logs by default.

Is it time to update this? I think so. You simply can’t run a “real” server with 10MB of transaction logs. What’s a sane value? I’d say that something between 64MB and 256MB would be okay for a lot of entry-level workloads, but that would consume some disk space that might surprise people. Perhaps this is the reason that the default hasn’t been increased from 5MB. Regardless, I think that 64MB times two is okay as a default.

What do you …

As a storage engine developer, I am excited for MySQL 5.6. Looking at http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html, there has been plenty of work done to improve the performance of reads in MySQL for all storage engines (provided they take advantage of the new APIs).

What would be great to add is API improvements to increase the performance of writes, and more specifically, updates. For many applications that perform updates, such as applications that do click counting or impression counting, there are significant opportunities for improving write performance.

Take the following example of click counting (or impression counting). You have a website and want to save the number of times links on your website have been clicked. Your table may look something like:


create table …

The third edition is nearly done. I’ve committed first drafts of all chapters, and all but one appendix. I need to do the last appendix and then rewrite the preface, which is a few days of work at my current pace. After that, it’s the usual tech review, copyediting, updates to figures, etc — and then it’s off to production.

I’m really pleased with this edition. I was planning on it just being a refresh of the second edition to reflect what’s new in MySQL-land, but it’s almost a complete rewrite. There’s a lot more focus on a logical approach throughout: what happens in the server, what are the limitations, why this matters, what are the practical consequences and applications, and therefore…. The “and therefore” is the real reason you buy a book such as this one.

Further Reading:

• …

or… “the case of Stewart recognizing parameters to the read() system call in strace output”.

Last week, a colleague asked a question:

I have an instance of MySQL with 100 tables and the table_definition_cache set to 1000. My understanding of this is that MySQL won’t revert to opening the FRM files to read the table definition, but we can see from strace:

[pid 19876] open("./db/t1.frm", O_RDONLY) = 32 <0.000013>
[pid 19876] read(32, ""..., 10)         = 10 <0.000011>
[pid 19876] close(32)                   = 0 <0.000012>
[pid 19876] open("./db/t2.frm", O_RDONLY) = 32 <0.000014>
[pid 19876] read(32, ""..., 10)         = 10 <0.000012>
[pid 19876] close(32)                   = 0 <0.000012>
[pid 19876] open("./db/t3.frm", O_RDONLY) = 32 <0.000014>
[pid 19876] read(32, ""..., 10)         = 10 <0.000011>
[pid 19876] close(32)                   = 0 <0.000011>
[pid 19876] …

Some of you may be aware that MySQL is increasingly using an Oracle-internal bug tracker. You can see these large bug numbers mentioned alongside smaller public bug numbers in recent MySQL release notes. If you’re particularly unlucky, you  just get a big Oracle-internal bug number. For a recently fixed bug, I dug further, posted up on the Percona blog: http://www.mysqlperformanceblog.com/2011/11/20/bug12704861/

Possibly interesting reading for those of you who interested in InnoDB, MySQL, BLOBs and crash recovery.

As Mark pointed out, there isn’t a lot of detail in the release notes about what could potentially be a very serious problem that is fixed in MySQL 5.1.60. I’ll repeat here the full documentation from the release notes:

“InnoDB Storage Engine: Data from BLOB columns could be lost if the server crashed at a precise moment when other columns were being updated in an InnoDB table. (Bug #12704861)”

This wasn’t much detail…so I went digging. Even though the BZR trees have not yet been updated with the 5.1.60 release tags, there’s enough history there to attempt to piece together what the story is.

Sometime after 5.1.57, Marko fixed “Bug#12612184 Race condition after btr_cur_pessimistic_update()” (revision id: marko.makela@oracle.com-20110616072721-8bo92ctixq6eqavr ). I mention this bug as it …

The third edition is nearly done. I’ve committed first drafts of all chapters, and all but one appendix. I need to do the last appendix and then rewrite the preface, which is a few days of work at my current pace. After that, it’s the usual tech review, copyediting, updates to figures, etc – and then it’s off to production. I’m really pleased with this edition. I was planning on it just being a refresh of the second edition to reflect what’s new in MySQL-land, but it’s almost a complete rewrite.

There's now 2 weeks left of the Call for Papers for Percona Live MySQL Conference and Expo (Santa Clara, CA). This weekend I've been finalizing my abstracts for submission and I trust many of you are doing the same. (If nothing else, do it for the free entrance! Or because you're passionate about MySQL, yeah, that's what I meant...)

This is the main annual MySQL event, so I thought it is worth the bandwidth to use these two weeks for some discussion and brainstorming. We are the MySQL community, it's up to us to make this a great conference now! This year I'm on the program committee, so I'm looking forward to reviewing many, many great proposals. At the same time, I'm interested to hear what you, dear readers - and hopefully future conference visitors - are interested in seeing at the conference? I'll share my ideas here and you can share yours in the comments …