This is a hack I've heard about a couple times now:

Paul wrote a script that reads from the logfile the queries that are going to be executed moments later. He parses the queries and constructs new select queries that populate the cache with the data that speeds up the upcoming writes. He claims, if I remember correctly, a three to four times speed-increase.

Here's the problem in a nutshell. The master can write transactions in parallel but slaves can only write them in series. [1]

This means you have a lot of optimizations on the master (TCQ and NCQ being examples) that aren't possible on the slave.

What this patch would do is precache the data so it's already available in memory. Since you're pre-reading the binary log you can run SELECTs in parallel on the SLAVEs so that the cache is hot when …

Having just moved apartments, it’s obviously time to get on a plane again.

On Monday I fly off to Stockholm again to attend the MySQL Cluster team meeting. Somehow we’re going to squeeze everybody into the Stockholm office (I’ll post humorous cramped photos, I promise).

Of course the thing to do now is to prepare for the meeting… packing can be done on sunday night or something.

Of course, if you’re in the area, come for food/beer!

...is something that you influence what it will be.

The problem with replication is that we have so many things that we want to do, but we are not that many people. What we do is what everybody does when the to-do list is to long: prioritize. Since the replication features are developed for you (yes, you), we have added a quickpoll on the http://dev.mysql.com/ where you can pick the three most important replication features that you would like to see us focus on next (after the 5.1 GA).

Do you think that on-line checks for table consistency is for weenies that cannot write a simple little script to do that? Please tell us that.

Do you prefer to live on the edge and think that semi-synchronous replication is for safety junkies? Well, we'll be glad to hear your opinion.

Do you think that the YouTube …

We’re on the verge of releasing our code and we’ve spent a lot of time looking at other projects to see what works what doesn’t as far gaining widespread adoption and building a vibrant developer community. There were some obvious differences in the way some projects are managed: Some have paid contributors others do not. Some use OSI approved licenses, others do not. Some had rigid roadmaps set by a small group (or even a single individual) others were more consensus oriented with their planning. Outside of the obvious, it was all terribly confusing and difficult to glean any useful insight from our ad hoc analysis.

Last month when we were at the mySQL conference I was talking to Tony Wasserman of CMU West and he mentioned to me his work in this area. He sent me a draft of his paper titled: A Framework for Evaluating Managerial Styles in Open Source Projects (I don’t have a link yet). In it he analyzed 75 commercial and community …

I had dinner with Zack Urlocker (EVP of Products at MySQL) and Luis Sala (one of my very best hires, ever) last night in San Diego. We talked about a wide range of things, but spent a fair amount of time talking about the people at MySQL, and especially the management team. Zack has recently been sporting long hair (pictured at right) and was pretty open about the nature of the people with whom he works. He didn't say this, but the description I inferred from the conversation was "confident but humble." Those of you who know Zack, or Marten,... READ MORE

This is a hack I’ve heard about a couple times now:

Paul wrote a script that reads from the logfile the queries that are going to be executed moments later. He parses the queries and constructs new select queries that populate the cache with the data that speeds up the upcoming writes. He claims, if I remember correctly, a three to four times speed-increase.

Here’s the problem in a nutshell. The master can write transactions in parallel but slaves can only write them in series. [1]

This means you have a lot of optimizations on the master (TCQ and NCQ being examples) that aren’t possible on the slave.

What this patch would do is precache the data so it’s already available in memory. Since you’re pre-reading the binary log you can run SELECTs in parallel on the SLAVEs so that the cache is …

I’ve written before about how to make MySQL replication reliable. One thing I think you need to do to make statement-based replication reliable is eliminate temporary tables. I found an elegant way to replace temporary tables with real tables in the systems I maintain. This article explains how. The problem Temporary tables are anathema to reliable MySQL replica servers. If you have a temporary table and the replica crashes in between accesses to the temporary table, when you restart replication the temporary table no longer exists, and you are in trouble.

Someone should really check the label before mass producing. Doesn't this look like SQL from SQL Server????

This is more of an essay than a blog post, but this subject comes up time and again, and since I tripped across this interesting blog post by Pedro Timóteo about why he has decided not to be a sysadmin any more, I thought now’s as good a time as any to comment on what [...]