Comments on: Recovery beyond data restore

By: peter

peter — Tue, 05 Aug 2008 01:21:11 +0000

Mark. I just figured out I answered to the wrong post. This is targeted to the one where you asked about MySQL Contributors agreement.

Regarding asking MySQL Management about release timing… I think you’re better off guessing yourself for the time being

By: peter

peter — Tue, 05 Aug 2008 00:41:19 +0000

Mark,

May be “Software Freedom Law Center” could be of interest here:
http://blogs.mysql.com/kaj/2008/06/27/david-axmark-and-michael-monty-widenius-donate-200-000-dollars-to-software-freedom-law-center/

By: Mark Callaghan

Mark Callaghan — Mon, 04 Aug 2008 16:14:26 +0000

@Peter – no, maybe MySQL product management can tell us?

By: peter

peter — Mon, 04 Aug 2008 16:06:27 +0000

Good to know Mark.

Do you have an idea what version is it scheduled for inclusion in the main MySQL tree ?

By: Mark Callaghan

Mark Callaghan — Mon, 04 Aug 2008 14:24:24 +0000

@Peter – it will work with intermediate nodes because one of the goals is to support hierarchical replication. It does not support master/master. The code at a slave assumes the tree has a root, not two or more roots. It is possible to extend this to support master/master and other advanced features. I will leave that to the MySQL team.

By: peter

peter — Mon, 04 Aug 2008 03:03:48 +0000

Well, When you’re looking at Inserts it is likely READs is what will limit you not writes (which happen in the background). The “dump” use of flash indeed will cause the issues you’re describing however there are solutions out there already which have various techniques to make random writes faster. Also you can use NVRAM same way as in RAID controllers to do fast ACID operations and write buffering. Anyway what I’m saying the flash may not be just there yet but it will come.

By: KirkH

KirkH — Mon, 04 Aug 2008 01:45:01 +0000

Thanks for the reply Peter. I did a lot of research on Flash SSD and came to the conclusion that random writes are often worse on SSDs than on conventional hard drives. I’m also not seeing the point of ACID compliance if the transactions aren’t written to a physical disk and the InnoDB log files are apparently the bottleneck here based on my testing today.

I’m assuming that somehow there are ways to stay ACID compliant and get more than a few hundred inserts per second but I’ve not yet figured that out. Thanks for the blog!

By: peter

peter — Sun, 03 Aug 2008 22:39:02 +0000

It is indeed off topic but why would you be surprised ? Using spindle free storage can improve performance dramatically though it is also quite expensive. At this point it is so expensive in many cases you can be better of to have a lot of memory (128GB/box is getting affordable) and keeping data in memory – which is going to be faster still. I expect this to change as Flash technologies mature and get down in price though

By: KirkH

KirkH — Sun, 03 Aug 2008 22:19:53 +0000

A bit off topic but I just did some benchmarking of InnoDB inserts on a RAMDrive and my Inserts per second went from 95 to about 9,600. From the InnoDB wikipedia article. “For typical hard drives or arrays, this will impose a limit of about 200 update transactions per second.”

I ran IOMeter on the RAM Drive and got 80,000 random 50% read / 50 %write IOPS which is more than a RAMSAN 300. I’m looking at moving my app to the RAM Drive.

By: peter

peter — Sun, 03 Aug 2008 16:54:11 +0000

Thanks Mark,

Good to know. Indeed the global transaction IDs are better, though I guess it was harder to implement. Are you going to support only master-slave replication or master-master and tree replication w filtering and writing to intermediate nodes as well ?