Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hello Adam, You issue is that your secondary peer is running 8Mbyte behind and you could not make it primary without dumping the original primary. Yes, For a setup that has a link between the two peers with a close (I am assuming close) near zero-latency. The main difference is the write commit rates on the backing stores. If the backing stores are not matched with rates then you can expect to have corruption issues, especially if a failure on the primary occurs. You secondary will always be out of date. Either you speed up the secondary or you slow down the primary peer to make the issue go away. I don't have this issue since we purchase matching gear, which is also backed by lots of secondary cache (100Gb per peer). Primary caches are battery backed on the arrays. Small writes are always deferred. James ----- Original Message ----- From: Adam Goryachev [mailto:mailinglists at websitemanagers.com.au] Sent: Sunday, December 23, 2012 03:31 AM To: Prater, James K. Cc: drbd-user at lists.linbit.com <drbd-user at lists.linbit.com> Subject: Re: [DRBD-user] Fwd: Re: Secondary Performance On 22/12/12 02:02, Prater, James K. wrote: > Drbd can only go as fast as the slowest backing store unless you use > more buffer/page cache. But since you are using software based RAID, > I would advise against it. Your setup dictates "write-through". > Yes, the two different RAID sets appear to quite closely matched but > you would be better off reversing their roles. I thought I already responded to this email, but maybe not... I really don't understand how reversing the roles will help? The secondary (spinning disks) can't keep up with the writes happening, if I make it the primary, it will have a lot more load to deal with (reads plus al updates, etc). This would make the entire system much slower. I'm just not able to see how making the slower system the primary would be an improvement? I was of the understanding that it was somewhat "normal" for the secondary to be somewhat less capable than the primary ? Thanks for your effort in explaining this. Regards, Adam > -----Original Message----- From: drbd-user-bounces at lists.linbit.com > [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Adam > Goryachev Sent: Friday, December 21, 2012 8:12 AM To: > drbd-user at lists.linbit.com Subject: Re: [DRBD-user] Fwd: Re: > Secondary Performance > > 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. > > Regards, Adam > > -- Adam Goryachev Website Managers www.websitemanagers.com.au > > _______________________________________________ drbd-user mailing > list drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > -- Adam Goryachev Website Managers www.websitemanagers.com.au