jcole’s weblog

Eric and I gave a 3-hour tutorial on Monday morning at the MySQL Conference and Expo 2007 entitled “Scaling and High Availability Architectures“. The slides aren’t great, and of course you should have been there. Nonetheless many of you will find the slides useful, and we’re keen to provide them, so here they are:

• MySQL Scaling and High Availability Architectures

If you have any questions or need help validating or understanding how our recommendations may fit into your environment, contact us.

Back in late 2006, MySQL AB decided to split (or “fork” for the more common open source term) their source code and release structure into two parts: “Community” and “Enterprise”. This has caused quite a lot of stirring in the MySQL market, and a lot of confusion about what exactly the difference is and how the release structure works. It’s actually not easy to really explain the new structure, and I won’t try here. The key point for the purposes of this discussion, is that MySQL is effectively no longer providing builds (binaries) of their community releases, and they don’t provide enterprise builds at all to the public. They are providing source releases of community, but fairly infrequently.

This is a big problem, because it means that there is no realistic way for the average developer or MySQL user to get regular builds (and ones that quickly address bugs) without paying MySQL for a support contract. Most of Proven Scaling‘s customers do not have support contracts with MySQL AB, and have been quite unhappy about the change, and personally I’ve lost a reasonable way to get new features pushed out to the public without excessive delays (up to 6 months to the next community release, and years for enterprise).

Back when MySQL originally polled me on this issue and told me of their plans, I told them that they would just force the community to repair the “damage” in the ecosystem, by providing the builds themselves. I even warned that the one doing the repairing could possibly be myself and Proven Scaling…

So, to get to the point…

This week, at the MySQL Conference and Expo, Solid Information Technology and Proven Scaling have announced a collaborative project to address the needs of the community for frequent releases with interesting features, bug fixes, and new patches: DorsalSource. Immediately, we have begun providing over 40 binaries of MySQL community and enterprise forks on Linux, Mac OS X, and Windows. We plan to add many additional platforms and variations of the builds, in addition to many more features to build a real developer community around MySQL.

We will continue the development of DorsalSource, adding many great new features—we have a ton of ideas, it’s just a matter of implementing them and getting them out there for users to use. If you have any questions, comments, or ideas for how to improve the site, or really anything at all, please feel free to contact me directly or leave a comment here.

One of the main questions we get at Proven Scaling is “Where do we find MySQL DBAs, Architects, and Developers?”

Next week is the MySQL Conference and Expo in Santa Clara, California. Inspired by the success of our impromptu job board at MySQL Camp last year (although whiteboards with no moderation tend to get messy), we decided to make a more formal job board this year. Something much more prominent, more organized, cleaner, and easier for both employers and job seekers to use. With great thanks to Solid for allowing us to use some of their Expo Hall space, we will have a formal job board in the Expo Hall, which is open April 24th and 25th.

We will have several “wall” panels at the edge of Solid’s Expo Hall space, and a kiosk (with Internet access) where you can enter your own job postings on the spot. Each posting will be printed out as a nice PDF, which will be mounted on the wall, and take-away cards will be printed with your contact information for candidates to take with them.

Posting your open jobs is completely FREE as a service to the community.

If you’re not going to the conference yourself, you just want to get your posting in early (please do!), or you want to post from the comfort of your own computer, head over to ExpoJobFair and sign up to post your open jobs!

If you’re going to the MySQL Conference and Expo next week, and you want to get MySQL-certified, we still have a number of vouchers for free certification left!

Get yours today!

In the spirit of our Free Ride program, Proven Scaling is offering fifty (50) free MySQL certification vouchers at this year’s MySQL Conference and Expo in Santa Clara, California from April 23 through April 26.

You must be present at the conference to pick up the free passes, and they are only good at the at-conference certification testing area during the conference itself on April 24-26. Each voucher is good for one test, but it’s up to you which test you take.

Go to Proven Scaling FreeCert to enter!

In MySQL 5.0, with the introduction of information_schema, the SHOW commands were changed to really be wrappers around SELECTs against information_schema. This means that when you issue e.g., a SHOW VARIABLES command, Created_tmp_tables is incremented once, and Handler_write and Handler_read_rnd_next are incremented about once per row in the result. Keep this in mind in your monitoring systems; these numbers could be wildly inaccurate if some part of your application is doing many SHOW commands.

This came to my attention because Connector/J’s ReplicationDriver runs SHOW VARIABLES LIKE 'tx_isolation' whenever you switch between setReadOnly(true) and setReadOnly(false), so in large, complex Java applications don’t be surprised if you see a high number¹ of Created_tmp_tables. How can this be solved? Use SELECT instead of SHOW. If you need to access one variable, instead of doing:

SHOW VARIABLES LIKE 'tx_isolation'

This will copy all variables into a temporary table, and apply the LIKE filter to that temporary table.

Use this instead:

SELECT @@session.tx_isolation

This will just fetch the tx_isolation variable from memory directly. This is much more efficient and to-the-point.

¹ Like, say, 8,000 per second. Creating so many temporary tables burns up a pretty big chunk of CPU time for nothing.