If you think about it in logical terms - disk based databases are about IO, and a lot of access patterns require random IO which is something disks are quite slow with. You can tackle this problem by faster IO subsystem, larger cache sizes or both.

It is indeed often amount of IO required is the problem for large applications. If you have faster IO subsystem you can have your application performing with smaller amount of cache memory, which is expensive and power consuming.

in my case with IO I mean the channel to HD… Random IO is indeed a hard problem to tackle… There are some nice disk controllers with a heap of memory that can hanlde random IO better then disk controllers with less IO. Just pick a disk controller with a little battery so it can cope with power faults (Disk writes will continue from on-board memory as soon as power comes back up).

Sure for READs you can well relay on cache memory, though there is also the catch of warmup time which will heavily depend on your disk sysbsytem performance.
For writes (especially with Innodb) large cache sizes also dramatically improve performance. As soon as you can have logging load you just pretty much need your IO capacity to be large enough to handle background flushes from buffer pool during checkpoint - number of physical reads which need to be done decreases dramatically if you have a lot of memory but surely can’t be eliminated completely.

Right Financial and other installations is where storing binary logs on separate volume makes sense. For others having say nightly backup w multiple generations, more regular backup of binary logs + slave can offer decent recovery capabilities.

However if you are doing a lot of write to your database then IO performance is everything in the end of the transaction you want your data to be save on your HD, not floating around in memory.

The article above needs to clarify about what is needed under what condition…

Ries

I definitely support these statements from testing and experience.

This reminds me of a discussion with a virtualization vendor about IO rate limiting, of which the main point was that if you force specific IO requests to be reordered based on userspace priorities, you prevent the kernel (and bbwc units) from properly serializing IOs based on physical disk layout and end up with a large net reduction in disk performance. I believe a fairly similar case is also true when data/logs are physically separated (artificially “rate limiting” — may be imagined as “protecting” — io by splitting data/logs) and disk writes are not allowed to be globally managed; you’ll end up losing a lot of IO performance unnecessarily.

Only in sensitive situations where periodic backups would not be sufficient for recovery (financial etc.) would separate partitioning be necessary, as you mentioned.