----- Original Message -----
> From: "Chao Zhu" <zhuchao@stripped>
> One Q: Can mysql binlog use raw device on Linux?
Mmm, good question. Don't really know; but I'm not convinced you'll get huge benefits from
it, either. Modern filesystems tend to perform pretty close to raw throughput.
From a just-thinking-it-through point of view, I'd guess no - mysqld never seems to open
binlogs for append, it always opens a new one. This may have something to do with the way
replication works; not to mention the question of what'll happen if the log is full - it's
not a circular buffer.
> Can we use asynch IO for binlog writing? sequential non-qio fsync is slowing our
Mmm... Theoretically, yes, you could use an async device (even nfs over UDP if you're so
inclined) but async means that you're going to be losing some transactions if the server
You can also tweak
- basically, this controls how often the binlog fsyncs. Same caveat applies, obviously:
set this to ten, and you'll have ten times less fsyncs, but you risk losing ten
transactions in a crash.
If your binlogs are async, then you also risk having slaves out of sync if your master
Personally, if your binlogs are slowing you down, I would recommend putting them on faster
storage. Multiple small, fast disks in RAID10 are going to be very fast, or you could
invest in solid state disks - not all that expensive anymore, really. Maybe even just a
RAM disk - you'll lose data when the machine crashes (and need an initscript for save/load
of the data on that disk), but not if just the mysqld crashes.
Weigh the benefits of each option very, very carefully against the risk of losing data
before you go through with this.
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel