[DRBD-user] Fwd: Re: Secondary Performance

Adam Goryachev mailinglists at websitemanagers.com.au
Fri Dec 21 14:12:10 CET 2012

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 20/12/12 23:43, Felix Frank wrote:
> Thanks, James, you seem to keep forgetting the list CC though ;)
> -------- Original Message --------
> Subject: Re: [DRBD-user] Secondary Performance
> Date: Thu, 20 Dec 2012 11:40:27 +0000
> From: Prater, James K. <jprater at draper.com>
> To: 'ff at mpexnet.de' <ff at mpexnet.de>
> What Felix suggested (switching roles) should work.  Personally,  I
> would not use SSDs for that type of deploy.  It is best placed to speed
> up certain processes (swap, scratch pad database location used for
> indexes or anythi
I think your message was truncated, but I was of the understanding that
SSD's were perfect for random I/O performance, which essentially is what
a bunch of VM's do.

With the performance I was getting when the primary was using a 2 disk
RAID1, I either needed to move to a 6 or even 8 disk RAID10, or else
move to SSD's. The linux-raid list seemed to agree that SSD would
provide the best performance/etc, the trade-off was of course, cost.
Also the suggestion against "consumer grade" SSD's (which I did ignore).
So far, the SSD solution on the primary has produced the desired result
and is working well, but spending the same cash on the secondary isn't
an option at the moment, so I'm doing my best to find a low-cost solution.

Currently, with the secondary "falling behind" about 40 or so times per
day, it could be considered "acceptable", but I'm a little concerned
about reliability. If that's the best I can get, then so be it, but if I
can reduce that to less than 5 times per day by increasing some
buffering/value somewhere, then I'd be a lot happier.


Adam Goryachev
Website Managers

More information about the drbd-user mailing list