Update 8 June 2009
Be sure you to check out some of my research including Understanding your RAID Configuration and Understanding PERC RAID Controllers.

Last week I got caught thinking a MySQL production system wasn’t configured with RAID when it actually was. The following is the Linux dmesg output of 3 different client MySQL servers, where the H/W is all the same, a Dell 2950.

In the first two cases you will see individual references to the internal disks, however in the third you do not. This threw me, but as Matt Yonkovit correctly pointed out to me, the sizes are not standard drive sizes. …

Last week I posted the following twitter request — “Can somebody loan me (or buy me) a Dell 2950 decked out so I can run and publish some benchmarks. Please!”

In a same day response I was offered access to use 2 x Dell 1950’s, and today I’m now actually using these machines for my own testing. I would like to thank cafemom (Barry, Anthony & Dan) for the loan of hardware.

And now the chance to better understand the RAID configuration of the DELL PERC Controllers, trying out some different RAID types, LVM configurations and disk tests. When I’m done with my System Administrator refresher, I’m then be trying some different MySQL Benchmarks to test various MySQL configuration settings including using the new Juice …

Cloudera lands funding. SourceForge acquires Ohloh. Novell reports Linux growth. And more.

Follow 451 CAOS Links live @caostheory

Cloudera shows signs of progress
GigaOM reported that Cloudera raised $6m Series B funding from Accel and Greylock and is now looking beyond web applications to wider enterprise adoption of Hadoop. Cloudera also announced its first certification program for Hadoop.

Open source goes mainstream in the UK
There have been signs of change recently with regards to open source adoption in the UK, which has traditionally lagged behind the rest of Europe and the US. CBR Magazine provided an analysis of …

Reading through the comments in Ronald's second post about More Basic MySQL Security, I noticed that there seems to be a misunderstanding about the implications of providing passwords to the mysql command line client via the "-p" option:

Jaka Jančar wrote:

What’s more insecure is passing password as an argument to MySQL, like you’ve written (-p[password]), since that can really be seen by anyone.

Shlomi Noach wrote:

While Linux security is often considered good, an astonishing weakness is “ps aux”, where every user can see …

I came across the following configuration today on a Production MySQL system (5.0.67) running 30+ blogs using Wordpress MU.

$ cat /etc/my.cnf
[mysqld]
set-variable = max_connections=500
safe-show-database

No I did not truncate the output. I could say I’ve seen worse, but that’s a stretch.

So the quiz and a prize for the best response, for the next 48 hours I’ll accept your comments as responses to this post for the top 5 settings you would add, and additionally what information you may need to add these settings. Bonus points for giving a reason why you would add the settings as well.

For example, I’ll give you the most obvious.

key_buffer_size = ????

To determine a key_buffer_size to start with I would look at the size of all Indexes via I_S, and combine with some estimate of growth, say 2x-5x.

For the best answer …

Just a short announcement: I am going to join Ulf for his PHP Barbeque Tour across Germany, which will take place between June 15th until the 21st. We will start in the south of Germany and will work our way up north in one week, stopping by at various cities in Germany to enjoy a barbecue with local PHP User Groups and to talk about PHP (of course), MySQL, Open Source, The Web and anything else. We've set up a Wiki page that outlines the various stations of our journey. At the Moment, we will visit the following cities:

• Monday, 15th: Munich
• Tuesday, 16th: Frankfurt
• Wednesday, 17th: Karlsruhe
• Thursday, 18th: Berlin
• Friday, 19th: …

If you can do either of these on your MySQL production server, you need to correct immediately.

1. Login directly to your MySQL server as the ‘root’ Linux Operating System user. For example:

$ ssh root@server-name
Password:  ************

2. Connect to MySQL database as the ‘root’ MySQL user without a password.

$ mysql -uroot

Here are the 60 second fixes to address these major security flaws.
To disable direct root access to your server, first ensure you can login as a normal user, then su - or sudo su - appropriately. Then, disable ssh root access with the following configuration change.

$   vi /etc/ssh/sshd_config
    # ensure this is commented out and set to no
    PermitRootLogin no

$   /etc/init.d/sshd restart

This will stop any brute force attack on your server by automated bots and password generators.

Second, the default installation …

So I spent several hours over the last few days on the Secondary index bug. Out of frustration I decided to try and bypass the LRU concept all together and try going to a true secondary page cache. In standard Waffle a page is written to memcached only when it is expunged ( or LRU’d ) from the main buffer pool. This means anything in the BP should not be in memcached. Obviously with this approach we missed something, as Heikii pointed out in a comment to a previous post, it seems likely we are getting an old version of a page. Logically this could happen if we do not correctly expire a page on get or we bypass a push/lru leaving an old page in memcached to be retrieved later on.

So I was thinking why not bypass the LRU process? While I feel this is the most efficient way to do this, its not the only way. I modified innodb to use the default LRU code and then modified the page get to push to memcached on any disk read. Additionally I added …

Dear Kettle friends,

Will Gorman and Mike D’Amour, Senior Developers at Pentaho, are presenting Pentaho’s Google integration work at the Google I/O Developer Conference. (at the Sandbox area to be specific)   Yesterday, Pentaho announced that much.

Here are a few of the integration points:

• Google maps dashboard (available in the Pentaho BI server you can download)
• A new Google Docs step was created for Pentaho Data Integration Enterprise Edition
• Running (AVI, 30MB) the …

Writing small volume of data (Bytes-MBs) with sync (fsync()/fdatasync()/O_SYNC/O_DSYNC) is very common for RDBMS and is needed to guarantee durability. For transactional log files, sync happens per commit. For data files, sync happens at checkpoint etc. Typically RDBMS does syncing data very frequently. In this case, overwriting is much faster than appending for most filesystems/storages. Overwriting does not change file size, while appending does. Increasing file size requires a lot of overheads such as allocating space within the filesystem, updating & flushing metadata. This really matters when you writes data with fsync() very frequently. The following are simple benchmarking results on ext3 RHEL5.3.


1. creating an empty file, then writing 8KB 128*1024 times with fdatasync()
fdatasync per second: 3085.94321
(Emulating current binlog (sync-binlog=1) behavior)

2. creating a 1GB data file, then …