I had the interesting customer case today which made me to do a bit research on the problem.

You can create merge table over MyISAM tables which contain primary key and global uniqueness would not be enforced in this case, this is as far as most people will think about it. In fact however it is worse than that - if you have same key values in underlying base tables some of the queries may give you wrong results:

PLAIN TEXT SQL:

1. mysql> CREATE TABLE t1(id int UNSIGNED PRIMARY KEY);
2. Query OK, 0 rows affected (0.07 sec)
3.  
4. mysql> CREATE TABLE t2(id int UNSIGNED PRIMARY KEY);
5. Query OK, 0 rows affected (0.02 sec)
6.  
7. mysql> CREATE TABLE tm(id int UNSIGNED NOT NULL PRIMARY KEY) type=merge union(t1,t2);
8. Query OK, 0 rows affected, 1 warning (0.03 sec)
9.  
10. mysql> INSERT INTO t1 …

You might have noticed that MySQL is hiring. We need more people. Last time I looked, we had 29 open positions, nearly all of which worldwide.

Internally, we have an initiative to come up with a canonised list of “The Top Reasons To Work for MySQL“. This is my input to the internal group of people compiling that list:

1. You get to work with some of the smartest people on the planet, as users, customers and colleagues.
2. You don’t have to relocate, but you can, if you (or your spouse) want to.
3. You usually work from home and can be available for family emergencies.
4. You can influence your own daily working rhythm.
5. You get to travel, meet …

Today seems to be Innodb day in our Blog, but well this is the question which pops ups quite frequently in Innodb talks and during consulting engagements.

It is well known to get better performance you should normally set innodb_log_file_size large. We however usually recommend caution as it may significantly increase recovery time if Innodb needs to do crash recovery.

I'm often something like what recovery time would expect for 512MB total log file size. This is however question with no exact answer as there are many things which affect recovery time.

For example Paul mentioned YouTube has something like 4 hours recovery time even if logs are of reasonable size and wikipedia has 40 minutes or so with innodb_log_file_size=256MB. In other cases I know same log file time may have recovery time of 5-10 minutes.

To understand things affecting recovery time you better to understand how Innodb recovery …

It was long overdue, but now it has happened: Planet MySQL now provides a section to aggregate french blogs about MySQL! Thanks a lot to Jay for updating the code and Pascal Borghino for the localization. If you are a MySQL enthusiast located in France (or any other french-speaking country) and you enjoy writing about your passion in your native language, submit your feed now!

Eric Bergen from Proven Scaling (which I had the pleasure to meet in person during the MySQL Conference & Expo in Santa Clara last month) was kind enough to send me a patch for the mylmbackup tool, which justifies a new release:

Attached is a patch file for mylvmbackup that adds the ability to use
lvm version 2 and perform innodb recovery on the snapshot prior to
creating a tar ball. The option is named --innodb-recover.

I've also fixed a bug with default value handling for command line
options. In version 0.4 if a config file was specified default values
in the script were all changed to blank. This means that the config
file had to supply values for every variable instead of just the
values that need to be changed from default.

This …

It might look like it is too late to write about stuff happened at Users Conference but I'm just starting find bits of time from processing accumulated backlog. The Theme of this Users Conference was surely Storage Engines both looking at number of third party storage engine presented, main marketing message - Storage Engine partnership with IBM, "Clash of Database Egos" - Storage Engine developers showcase as one of keynotes.

Today let me start with most popular transactional storage engine for MySQL - Innodb.

Innodb Storage Engine was covered in a lot of talks, many of them done by Innodb users. I found these items forth interest

Innodb Zip Page Compression This feature was in development for a while. I believe it is at least 3rd Users Conference it is being talked about, but now it is working enough to do some tests. There seems to be still fair amount of work required to make it work well such as having …

The weather today was wonderful, time for the kilt.

I met up with sierrascape at her studio, picked up sushi at Hah-Nah, and ate lunch outdoors on the grass at Cal Anderson Park.

This afternoon I met up with krow at Victrola Cafe, and watched and assisted as he wrote up a skeleton UDF for MySQL. The idea is that I use the UDF mechanism to load my SNMP agent for MySQL into 4.0, 4.1, and 5.0.

This evening Paul came over, and we did Knuth, with Eric on Skype.

And now, Kidde keeps coming over and yelling at me to come to bed.

Just a little heads-up and a bit of MySQL-related technical content for all of you still out there following along…

At Proven Scaling, we take on MySQL performance problems pretty regularly, I’m often in need of good tools to characterize current performance and find any issues. In the database world, you’re really looking for a few things of interest related to I/O: throughput in bytes, requests, and latency. The typical tool to get this information on Linux is iostat. You would normally run it like iostat -dx 1 sda and its output would be something like this, repeating every 1 second:


Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sda 0.00 8.00 0.00 4.00 0.00 96.00 0.00 48.00 24.00 0.06 15.75 15.75 6.30


Most of the output of iostat is interesting and reasonable for its intended …

If you're at JavaOne this week, please do visit the "Solaris + AMP" pod (#976). We are demoing the use of SMF and dtrace on Cool Stack. You can see how dtrace can be used to debug and trace the code path through your entire application, starting from the Javascript in the browser, through PHP and finally to MySQL at the back-end. We are also distributing Cool Stack 1.1 on a DVD at the pod.

I will be there on Thursday between 11:00 - 3:00 PM, so please do stop by and say hi. 

Shanti 

If you've used the UNIX find command for more than a trivial find-and-print, you know how powerful it is; it's almost a miniature programming environment to find and manipulate files and directories. What if you could do the same thing with MySQL tables and databases? That was the inspiration for writing this tool. I was about to write several other tools to do some MySQL administrative jobs when I realized I could generalize and make something much more useful and powerful.