Blog | Admin | Archives

MySQL Conference Day 1

My first day at my first MySQL conference was a riotous success. I attended the “State of the Dolphin” keynote followed by talks given by Tim O’Reilly and Facebook’s own Mark Callaghan, who also won a MySQL Community Member of the Year Award during the opening talks. Congrats to Mark!

After the Keynotes, I synced up with other Facebookers at our expo hall booth, and then I went to Domas Mituzas’ talk on “High Concurrency MySQL”. The ballroom couldn’t hold all the people who wanted to watch — there was actually a line outside the door of people listening in on his talk! Although I wouldn’t suggest Domas give up his day job to write slides full-time, he had a great presentation overall that kept the audience interested and engaged.

Next, I attended a presentation on Sqoop by my two-time TA at the UW and now Cloudera co-founder and presenter extraordinaire, Aaron Kimball. Sqoop is a SQL-to-Hadoop translation layer that automates many of the steps of shuttling data from OLTP stores to HDFS for analytics. It is open source and Aaron is it’s primary developer. You can check out the code on github, or use it as part of Cloudera’s Hadoop Distribution.

After lunch, I went to a presentation by Lars Thalmann on new MySQL replication features in 5.1 and 5.5. Lead replication developer Mats Kindall was also there to answer questions. It’s good to see that MySQL is making progress on replication, but it is still woefully limited in a number of ways: not crashproof, single-threaded, and difficulty in replicating to non-MySQL data stores are all weak points of MySQL’s replication system today. These are all on the roadmap, but from the answers to my questions, I got the impression that these ideas are still mostly bullet points on a slide rather than almost-features in MySQL.

Make no mistake, these features are hard to add — I’ve dabbled around in the area myself — and it took Mark a concerted effort to port rpl_transaction_enabled from our 5.0 patch to Facebook’s 5.1 patch. Still, I hope MySQL takes the rpl_transaction_enabled patch and  into 5.1 or 5.5 officially, because in any large deployment, it is incredibly useful to not manually intervene when a slave crashes.

After the replication talk, I went back to the expo hall to talk with people, then I hacked on MySQL in the afternoon. Could there possibly be a better venue for this? Two (small) diffs later, and I was back into the expo hall socializing/recruiting for Facebook. The night ended well with a trip to In-and-Out.

MySQL Conference Begins Tomorrow

The 2010 O’Reilly MySQL Conference starts tomorrow in Santa Clara. Facebook’s Database Engineering team (which includes me!) will be there along with some of our Operations team and our one-man Performance team. Each team will be giving a talk at the conference:

On Tuesday, the Database Performance Team will be presenting on “High Concurrency MySQL.” Domas is an interesting, animated fellow, and I imagine that his talk will be quite entertaining as well as informative.

On Wednesday, the Database Operations Team will be speaking about Database Operations at Scale. Our DB Ops guys are some of the best in the business; they keep our database tiers, which are often under enormous pressure from growth and changing requirements, running remarkably well.

On Thursday, Mark Callaghan, Ryan Mack, and I will be presenting our talk on High-throughput MySQL (we claim that Domas stole our title rather than the other way around). Mark Callaghan is one of the leading advocates for MySQL at Facebook and in the MySQL community. Working with him and the original Ryan (as I call Ryan Mack, who preceded me on this team) has been nothing short of an extraordinary opportunity for me to learn from the best.

Safety Agains Reopen

What does this comment in the MySQL source mean? (log.cc, currently line 2295 in 5.1)

{ // Safety agains reopen

I think I understand what it’s supposed to mean — the writer is pointing out that the code is checking again, to be double sure that the log is still open (although, if it can close between this call and the last call to is_open(), I’d be worried about it closing after this call too… note that both checks are after LOCK_log has been acquired).

What I’m more interested in is what the comment, as written, actually means? The grammar is very odd. I’m open to suggestions.