In Part 1 of this article series, we looked at how the Falcon transactional storage engine was architected and how it compared to some of the other MySQL storage engines. In this article, I?ll focus on how Falcon performs transaction management, including some special points on where Falcon differs from some of MySQL?s other transactional engines.

As of MySQL 5.0 there is no SHOW CREATE TRIGGER which is pretty annoying. I don’t like using “show triggers like
“, so I figured I’d write a wrapper around mysqldump. For the record, this was a huge pain the ass. I did this on Fedora, GNU sed version 4.1.5. You need to have your password stored in ~./my.cnf for this to work, I believe. I haven’t tried it without it.


mysqldump -dnt database | sed "/\/\*\!4.*\*\/;*/d" | sed "s_/\*\!5[0-9]*__g" | sed "s_DEFINER=.*\*/__g" | sed "s/\*\/;*//g" | sed "/SET/d" | sed "s/^[ \t]*//" | sed "s/\ \ */ /g" | sed "/--/d"


You will get a dump of ALL the triggers in your database, using this. However, since that’s what I need on this particular example, it’s what I’m sharing. I’m sure I could have cleaned up the code a little and used fewer calls to sed, but frankly I don’t mind, since it works fine.

I hope this helps someone.

If you're in the L.A. area, this weekend I will be speaking at the Southern California Linux Expo (SCALE) on SQL coding, schema and index tuning MySQL servers. Come meetup with me at the MySQL BoF or find me around in the sessions.

The third speaker in the spotlight series is Joe O'Brien, who, as it so happens, is the only other speaker than myself who lives in Columbus, Ohio. Joe is a principal at EdgeCase Consulting, a web design and development firm focusing fairly heavily on enterprise and web applications built with Ruby (on Rails).

Joe is teaching a 3 hour tutorial on Monday called "Vital Rails: An Introduction to the Rails Framework". The tutorial promises to be one of the most popular ones, as Ruby, and Rails in particular, is always a highly requested conference topic. Joe will be covering the Rails framework, with a focus on ActiveRecord, the framework's critical component for accessing and updating data in the database using the, uh, ActiveRecord …

I find it funny that in the middle of winter in Sweden that MySQL's
server farm requires both air conditioning and an open window!

Notice the excellent Swedish engineered racks :)

It's quite an effort to compile and test 3 versions of MySQL on 4 different machines, but that is what I have done for the first binary distribution of the PrimeBase XT pluggable storage engine.

Of course, its worth the effort because this is the "holy grail" of the pluggable storage engine strategy. Namely, binary plug-ins that work with the binary distributions prepared by MySQL and others in the community.

And by creating an installer script I have made it easier than ever to install the plug-in. So after you have downloaded the binary package from http://www.primebase.com/xt, all you have to do is:

1. Start your MySQL server.

2. Enter: sudo ./install

The installer will automatically determine the version of the server running and install the corresponding plug-in.

…

Just wanted to let you know that we’ve got a new 5.1 beta release ready for download (5.1.15). Lots of fixes and minor changes went into 5.1.15 so be sure to check the release notes.

To date, the most popular new features in 5.1 continue to be partitioning, row-based replication, events (internal scheduler), and disk-based cluster. If you haven’t done so already, check out the tech white paper I wrote on 5.1 that has lots of examples showing the new 5.1 features in action.

One other interesting fact: according to our latest survey results, 22% of community users and 12% of enterprise customers are already using 5.1 in production. Of course, we don’t recommend you use beta software for production use, but it’s nice to see folks finding that the 5.1 beta can hold up under that kind of pressure.

Be sure to drop me a line …

Have you ever seen connection in the SHOW PROCESSLIST output which is in "Sleep" state for a long time and you have no idea why this would happen ?

I see if frequently with web applications and it is often indication of trouble. Not only it means you may run out of MySQL connections quicker than you expected but it also frequently indicates serious problems in the application. If you do not use persistent connections and you have connection in Sleep stage for 600 seconds what could it be ? It may mean some of your pages take that long to generate (or might be the code simply gets into the tight loop and page never gets generated) it also could mean some of external Web Services are slow or not available and you're not dealing with timeouts properly. Or may be you have several connections to MySQL server and right now running query which takes that long ? In any case it is something frequently worth looking at.

…

In discussion the other day a co-worker was looking at a benchmark
that I had created for a problem I was studying on threads with write
performance.

He asked "What is open tables set at?"

I responded that I had it set to a thousand, which is normal the
value I keep on the machine I do development on. I normally look at
300 connections as an average load, but every so often I crank it up
to around a 1000 depending on the test (which is a pretty high
simulation, and not common among the average large websites).

It crossed my mind at this point that I had no idea how the database
behaved with default value in MySQL, which is 64, when you were
running with this many threads. Anyone who has a large number of
threads touching tables knows to crank up the table cache.

As the graph points out, depending on which engine you are …

Today I had a sort of short epiphany regarding getting progress of running statements in MySQL. MySQL already keeps a running count of rows touched in most multi-row statements (called thd->row_count1), so I figured there must be a way to make use of it. It was trivial to expose row_count through SHOW PROCESSLIST. After that, it was fairly obvious that another variable could be added: row_count_expected. For certain statements (currently only ALTER TABLE) it is easy to estimate how many rows will be touched, so that number can be used to calculate a Progress_percent column.

The Progress_rows number indicates progress within a given step of executing the query. For instance, if you run a SELECT with a GROUP BY that can’t be done using an index, you will see two cycles of Progress_rows: once with a State of “Copying to tmp table” and once with “Sending data”.

I implemented this all in …