Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
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 ----- Original Message ----- From: Felix Frank [mailto:ff at mpexnet.de] Sent: Thursday, December 20, 2012 03:56 AM To: Adam Goryachev <mailinglists at websitemanagers.com.au> Cc: drbd-user at lists.linbit.com <drbd-user at lists.linbit.com> Subject: Re: [DRBD-user] Secondary Performance On 12/20/2012 08:31 AM, Adam Goryachev wrote: > The primary has 5 x 480G Intel SSD drives in a RAID5 configuration > The secondary has 4 x 2TB WD RE4 drives in a RAID10 configuration Huh. SSD RAID vs. rotaries? That's about as far apart as you can set primary and secondary performance-wise. Have you considered switching their roles? If I understand this correctly, you're looking for a way to keep your maximum performance and trade in the stability of your replication. Are you sure the gain is wort the risk (and pain)? Is your iSCSI maxing out the I/O on that SSD RAID? > In general, most of those are small amounts of data over small amounts > of time, so it would be nice to add a little more buffering 'somewhere' > so that instead of getting out of sync, the secondary just has more data > un-written to disk in a buffer somewhere. > > Any suggestions or advice would be greatly appreciated. DRBD Proxy springs to mind, even though that's not a free option (monetarily speaking). HTH, Felix