We've been running replication poll and we've got some answers, so I thought I would comment a little on the results of the poll and what our future plans with respect to replication is as a result of the feedback. As I commented in the previous post, there are some items that require a significant development effort, but the feedback we got helps us to prioritize.

The top five items from the poll above stands out, so I thought that I would comment on each of them in turn. The results of the poll were (when this post were written):

Disclaimer - views expressed in this blog (and this entry) are my own and do not necessarily reflect the views of MySQL AB

Ever since I wrote my blog entry about Google Gears and the query tool for the browser embedded offline Google Gears database service, I have been wondering how MySQL might fit in here.

I have heard an idea to write a MySQL storage engine for SQLite and although I do not think this is necessarily a bad idea, I don't think it will be immediately useful for typical …

jag.singh@dwoptimize.com

Optimizing performance and usability of large data warehouses using parallelism, partitions, and aggregate summaries, in conjunction with dimensional modeling, across the complete application stack comprising of ETL, databases, and reporting.

This is a personal blog with personal opinions.

Banner picture adapted from wikimedia.

Since starting the innotop and mysqltoolkit projects on Sourceforge, I have learned a lot about how to use source control more effectively – especially how branching and tagging can be used. Still, I have limited experience. I want to package all the tools in MySQL Toolkit together and release them in one archive, but I don’t know the best way to do it; every idea seems to have drawbacks. Read on for the details, and if you have suggestions, would you please leave comments for me?

MySQL Table Checksum 1.1.6 enhances chunking, adds features and fixes bugs. The chunking functionality is where I continue to put most of my effort. This release’s behavior is incompatible with the last release, and it will probably change again in the future. Thanks to everyone who has been helping me chase down bugs, including one user who sent me a major patch! It’s a great feeling to get a patch.

The other day I blogged about the fact that I thought partitioning was broken in 5.1.18.

There does in fact appear a bug that was introduced somewhere between 5.1.17 and 5.1.18 which is causing MySQL to dump core.

I tried recompiling 5.1.18 from source and the problem remained. Installing a 5.1.17 source build fixed the problem and we’ve been online for almost 72 hours without a core dump. By way of comparison 5.1.18 wouldn’t stan up for more than a few hours.

I’m not sure I have a ton of time to debug the issue but I wanted to get the information out into the public.

Assumptions:

RHEL
x86_64
EXT3
RAID

What Raid to use?
RAID-10

Why?
It's faster. RAID-5 offers more disk space but the parity bit messes things up, unless you have some uber hardware-raid card that caches that operation. Personally I am not a fan.


Stripe Size:
128K - this is really good for INNODB, you'll see a huge boost in responsiveness by making your Stripe Size 128K. I had a 64K stripe size, and I was blown away by the improvement of 128K


Mount options:

mkfs.ext3 -T largefile | mkfs.ext3 -T largefile4

Unless your going to have millions of files, this is a good option.


Make sure /etc/fstab mounts the mysql partition or the data that mysql resides on with noatime.

atime is accesstime: this is a huge boost in performance, tracking each time …

Ok, so I knew about innodb_table_monitor and innodb_tablespace_monitor. I’ve tried them before, looked at the output and given up, partly because it didn’t serve the purpose I wanted it to at the time, and also because it’s format was a little cryptic.

What I didn’t know was there are actually 4 monitors via this “create table functionality”. You can also do innodb_monitor which is the same as SHOW INNODB STATUS, and you can also do innodb_lock_monitor .

Another thing I didn’t know is that these commands don’t send the output just once, it’s on a timer. I’ve found the timers to be different. For innodb_monitor you get every 15 sec, as well as a nice line given time of averages which seems to always say 16 seconds.

=====================================
070601 15:11:25 INNODB MONITOR OUTPUT
=====================================
Per …

I've been looking through the Fedora Core 7 release notes this morning. One thing which stood out was their inclusion of Smolt.

Smolt is a hardware profiler which sends out put back to a public webserver being run by Redhat. Turn it on, and Redhat can see what hardware you are running. This type of phone home service is one that we have talked about for a long time at MySQL.

Would users be open to us sending back non private data about their systems? OS, machine type, config parameters, storage engines used... information found in show variables. What is the level of detail?

Would any detail be too much? Even if the code laid dormant unless turned on, what would users think?

I'm happy to see one of the open source vendors take this leap. I think open information like this is great, since it allows software writers to …

In a previous post, I mentioned the availability of the dtrace extension for Cool Stack's PHP.  Using this extension and the Cool Stack MySQL, it is possible to analyze the performance of your application running on this stack. At JavaOne, we demoed this using the open source MediaWiki and SugarCRM applications.  dtrace is especially useful in analyzing complex multi-tier applications like AMP. Thanks to Angelo Rajadurai for the creation of the scripts that I describe below.

Analyzing PHP calls

So, let's look at a simple dtrace script that counts how many times a particular PHP function is called :

#!/usr/sbin/dtrace -Zqs

php*:::function-entry
/arg0/
{
        @[copyinstr(arg0)]=count();
}

You can copy the …