Phorum needs to get to the MySQL Conference. Perhaps you do, too? Or perhaps you want to help people get there? Technocation, Inc is a not-for-profit committed to helping folks get the education and networking contacts so important to IT professionals. So, they’re opening up their very first campaign!

Technocation, Inc. is a not-for-profit organization. Your contributions are tax-deductible to the fullest extent of the law. You may choose to donate money, goods or services. Money may be donated through PayPal at http://tinyurl.com/28fa76, and services should be arranged through e-mailing donate@technocation.org . To send payment by mail, see details at . Technocation’s EIN/Tax ID is 20-5445375
Currently, this campaign is …

I will be giving a webinar today at 10am PST/1pm EST entitled "Understanding MySQL Query Execution Performance", which is for novice to intermediate MySQL users, and covers the EXPLAIN command and analyzes various SELECT statements against the Sakila SampleDB. The slides are available here:

Understanding MySQL Query Execution Performance

Enjoy, and feel free to email me feedback and suggestions on the slide content: jay at mysql dot com.

Found a great article about Linux IO Schedulers today which is quite interesting. It goes in details about schedulers and explains in which of workloads which of schedulers is best.

The interesting thing this article points out is - there are multiple versions of each of the schedulers, while name remains the same. This means unless you really know mapping between kernel versions and scheduler versions it is very hard to evaluate benchmark results.

This could be noticed by benchmarks we've done over years. Long time ago "AS" scheduler could be several times slower than deadline for MySQL workloads such as SysBench or DBT2 when it went down to 30% difference and in the last runs we've done difference was not really significant.

This article also points out benchmarking IO schedulers you should look at more numbers than aggregate bandwidth - you also better to …

Yesterday, I wrote about some examples of disruption.  When an industry gets disrupted, there's usually a consistent pattern that emerges:

• A new entrant joins the market
• Their offering is perceived as limited and technically inferior
• The new entrant starts to gain a toehold in a few niches
• The incumbent waits and watches
• The entrant becomes "good enough"
• The niche market starts to boom
• The incumbent responds by trying to cram disruption
• The new model wins

I think the same pattern that happened with PCs disrupting minicomputers and …

I received an email the other day from someone at MySQL AB. They are offering free Phorum booth space in the .org Pavilion at the 2007 MySQL Conference. The .org Pavilion is for Open Source projects that are somehow related to MySQL. Not only does Phorum use MySQL as its primary database (our PostgreSQL layer stays 99% done it seems) but MySQL.com also uses it for their support forums.

So, we had a problem. The Phorum team is not by any means wealthy. We all have jobs and work on Phorum in our spare time. So, getting everyone there is going to be problem number one. There are 3 primary team members. I am in the US. Thomas Seifert is in Germany and Maurcie Makaay is in the Netherlands. We decided to turn to our users for help.

I made a …

FOSDEM, the Free and Open Source Software Developers' European Meeting will again take place in Brussels, Belgium on February, 24th & 25th. I went there last year and really had a great time. This year, I submitted a proposal for a lightning talk, which has been accepted! I've just been informed that the lightning talk schedule is now published. My talk "What's new at MySQL AB" will be on Saturday, at 17:00. I look forward to being there!

Kevin Burton writes about making MySQL Replication Parallel. Many of us have been beaten by the fact MySQL Replication is single threaded so in reality it is only able to use only single CPU and single disk effectively which is getting worse and worse as computers are getting "wider" these days with multi-core CPUs.

Kevin proposes to execute queries in parallel and it is generally good idea, the problem is however implementing it right without changing MySQL Replication semantics - which is - Slave database state corresponds to master database state at certain point in time. It is delayed but threads reading from the slave never will see state of the database which never existed on master.

As I commented in Kevins blog the problem is very simple to illustrate - assume you have 2 queries modifying 2 different tables, query A and query B. On the Master …

With the current version of MySQL there are two threads used by a slave to implement replication. One reads from the binary log of the master and the other one executes the SQL.

If you have a master which is being pounded with individual inserts that are happening on parallel threads these will be serialized by the slave and executed one by one.

The master would in theory fully saturate the disks since it would be bottlenecked. Since the INSERTs are happening in parallel and on multiple threads the disk subsystem would get more effective write performance since it can take advantage of tagged command queueing and so forth.

Since the slave doesn't have the ability to execute the INSERTs in parallel and can only use one thread it will quickly fall behind replication.

In practice the only way to fix this is to make sure the that the master isn't fully loaded or that the slaves are more powerful than the master. …

Also packed in an environment where MS Access may be present, as it does [Col Name] for identifier quoting (and Access users often use spaces in identifiers).

I have been asked numerous times what does “load average” means in top. If you don’t know what top is and you have access to linux machine, go type top now and see what it shows.

load average: 2.05, 2.17, 1.93

Quick answer is: first number (2.05) is 1 minute avg, second number (2.17) is 5 minute avg, third number (1.93) is 15 min avg. Generally system admins look at these #’s to see how is their server is doing. But now you wonder, if this is the #’s you look at, why is there cpu %? Isn’t that computer load also? Ofcourse it is. BUT, meaning of cpu % shown in [ Cpu(s): 14.2% us, 1.7% sy, 0.0% ni, 80.7% id, 3.1% wa, 0.0% hi, 0.3% si, 0.0% st ] actually just means how much % of time was spent doing stuff on cpu. On the other hand, load average takes other things such as how much cpu’s were being used and how many process had to wait for their turn to use cpu, etc. Thats why sometimes you will see high % for Cpu …