If you're using MySQL with the MyISAM engine for a high-writes application, delay_key_write is usually very good.

Let me explain further: delay_key_write is a table option which causes the database NOT to flush the MyISAM key file after every write. This is a really good thing, as if you're doing another write very soon anyway, this is likely to just waste I/O time.

This doesn't sound like a good idea right, because it means that if the power fails (or mysql crashes, or something), then you'll be left with a broken index file? No, it's still a very good idea:

• delay_key_write does NOT appear to affect the MyISAM data file - that will still be flushed according to the normal policy.
• If you had delay_key_write off, then a power failure or crash during the index write would cause the same level of corruption.
• Broken MyISAM index files need to be rebuilt, regardless of how little …

Recently I had one customer for consulting and aside from mysql optimization, etc they asked me for cacti installation/setup to monitor their pretty generic LAMP application. I’ve started setting up all this stuff and I’ve never thought it could be so painful… lots of different templates for the same tasks, all of them are incompatible with recent cacti releases, etc, etc… So, this post is generally a list of used templates with a fixes I’ve made to make them work on recent cacti release.

(more…)

So Im now back from our developer conference in Heidelberg via a short stop in Munich for some 1L beers at Oktoberfest.

We had representatives from cross departments and overall it was a great success. We got a ton of good work done in short time. Theres something unique when you get 100+ people in one physical location working day and sometime night over a few days. Its a burst of very effective energy though not sustainable over a longer period and with local beer being way to good to avoid, sometimes in excess...It can't be done over a longer period of time though, regardless of cost, it's to intense and one need to work independently on the identified action items before regrouping again. A week or just short of that is optimal.

Having a department cross section attend is also great. Getting input from other services groups than support also widens the decision making process and becomes more in tune with the overall …

I was reading, this article (subscription required) by Ben Worthen on WSJ about a study on how well companies are prepared for a disaster. I was not at all surprised by (one of) the findings (paraphrased):

…While 70% of 189 tech leaders surveyed by Forrester Research Inc. said that their companies are prepared for a disaster, the reality was quite different…

We run into this all the time, in talking to (prospective) customers. People “think” they are prepared for a disaster. The truth hits them when you start peeling the layers of the supposed plan. Some things to keep an eye on are

• Is it robust and reliable?
• Do you have the right resources engaged in the plan - both design and implementation?
• How often are the plans tested?
• How well is the plan documented?
…

(Also see the follow-up post about some progress)

Today I was (again) facing a log file from a machine that had for some reason not been able to start a temporary MySQL daemon during the night to prepare for a streaming MySQL slave installation. The necessary 2nd daemon had created its new ibdata files, however just after that aborted the startup process with the following message:

Can't start server: Bind on TCP/IP port: No such file or directory
071001 23:09:55 [ERROR] Do you already have another mysqld server running on port: 3310 ?
071001 23:09:55 [ERROR] Aborting
071001 23:09:55 [Note] mysql\bin\mysqld.exe: Shutdown complete

As you can see, the port is a different one from the default MySQL port, so I can be …

Our friend Dathan recently suggested that The Quality of mySQL lately sucks.

I’ve just ran into yet another obvious bug that has made it’s way into production.

While I’m not going to argue that more unit tests would be a good thing, I’d like to point out that what he’s referring to is not so much a bug as it is a change that happened (and was documented) in 5.0.12:

Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. The changes include elimination of redundant output columns for NATURAL joins and joins specified with a USING clause and proper ordering of output columns. The precedence of the comma operator also …

When I was comparing performance of UNION vs MySQL 5.0 index merge algorithm Sinisa pointed out I should be using UNION ALL instead of simple UNION in my benchmarks, and he was right. Numbers would be different but it should not change general point of having optimization of moving LIMIT inside of union clause being cool thing.

But So is UNION ALL indeed faster than UNION DISTINCT (the UNION is shortcut for UNION DISTINCT) ?

Indeed it is. I did not have the same data as I used for the other test but I created similar test case - table with separate indexes on "a" and "b" columns with cardinality of 100, having about 40.000.000 of rows

PLAIN TEXT SQL:

1. SELECT * FROM test.abc WHERE i=5 union  SELECT * FROM test.abc …

Today I was (again) facing a log file from a machine that had for some reason not been able to start a temporary MySQL daemon during the night to prepare for a streaming MySQL slave installation. The necessary 2nd daemon had created its new ibdata files, however just after that aborted the startup process with the following message:

Can't start server: Bind on TCP/IP port: No such file or directory
071001 23:09:55 [ERROR] Do you already have another mysqld server running on port: 3310 ?
071001 23:09:55 [ERROR] Aborting
071001 23:09:55 [Note] mysql\bin\mysqld.exe: Shutdown complete

As you can see, the port is a different one from the default MySQL port, so I can be sure there was no conflict with the primary instance. Even more curiously the same process has been working on that and other machines flawlessly for some …

Today is make public old trees day. Someone is probably going to
wonder why I am making Gemini public again, and the answer is
"someone asked". I've discovered that the only real way for me to
keep code around is to put it up publicly on my revision control system.

http://hg.tangent.org/gemini

The code is old, and I've not made this branch compile in a while. It
will not work with a modern version of MySQL, in fact only ever
worked on a 4.0 Alpha version. I am told that the code for Progress's
current database is not all that different (in the core of the
storage engine), but I really do not know. I can tell you that the
code does require assembler for one operation and that this tree does
not have a working piece for my 64bit AMD. There are a couple of
additional branches out there of …

About one month ago we posted a call for interns to work with us on various MySQL Performance related things.

We got good number of replies and a lot of people wondered what tasks exactly we could offer as surely this sort of involvement should be fun and should teach you something.

Really we did not have a list - Cool opportunities and
ideas constantly pop up plus we expect you to bring your ideas on what
you would be interested to work on and we will see if there is an
interest for us to mentor and sponsor your work.

Generally the tasks we see Interns working on are either Open Source
projects or research which would be published so besides minor
financial compensation there is publicity and education components.

Here are few things we have in mind: