Technological Differences between HDR & RSS
Answered: amber (solid confidence) — Art Kagel gives a detailed, specific answer (synchronous HDR via DRINTERVAL=-1 can block primary commits pending DRTIMEOUT; RSS is always async/full-duplex and can lag intentionally); Madison Pruet adds the 11.70 pre-load feature. Never explicitly confirmed by the asker, who says only that they'll evaluate.
Advisory only.
Posted in 2012
Topics: High Availability & Replication, Performance & Tuning, Platform-Specific Issues
Hi All, We are using IDS 11.50.FC8W3 on Solaris Sparc. We are in process of migrating from one Data Center to another. In this scenario, we might require to run Primary - HDR from different Data Centers. Is it feasible (from performance perspective) that HDR wont impact Primary instances in a high volume OLTP Database ? Is there any technological difference as far as RSS & HDR are concerned ? Thanks.
You might want to try RSS with log staging / delayed apply of 1 second. With 11.70 we implemented the ability to pre-load pages on the primary which means that the impact is much less - on the order of 10 times faster. From: "SHAHZAD SALAM KASI" <skasi@i2cinc.com> To: ids@iiug.org Date: 01/03/2012 10:11 AM Subject: Technological Differences between HDR & RSS [25792] Sent by: ids-bounces@iiug.org Hi All, We are using IDS 11.50.FC8W3 on Solaris Sparc. We are in process of migrating from one Data Center to another. In this scenario, we might require to run Primary - HDR from different Data Centers. Is it feasible (from performance perspective) that HDR wont impact Primary instances in a high volume OLTP Database ? Is there any technological difference as far as RSS & HDR are concerned ? Thanks. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
We want to use HDR, as we can then switch HDR to Primary. Is there any technological difference between HDR & RSS, that might impact Transaction Processing on Primary Instance. Thanks.
In asynchronous mode (DRINTERVAL >= 0) there is little performance impact on the primary server from having an HDR secondary. In sychronous mode (DRINTERVAL -1) transactions on the primary must wait for the commit record to be transferred to the HDR secondary, processed, and acknowledged (or the server timeout [DRTIMEOUT] to expire) to complete the commit locally. This can affect primary server performance. RSS secondary replication is always asynchronous and is full duplex (HDR secondary is half duplex) and so it is a bit more forgiving of slow network connections between the primary and secondary server. Also you can configure the secondary to intentionally be <N> seconds behind the primary so you can use it to recover older data from fumble finger deletes and updates. Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Jan 3, 2012 at 11:10 AM, SHAHZAD SALAM KASI <skasi@i2cinc.com>wrote: > Hi All, > We are using IDS 11.50.FC8W3 on Solaris Sparc. > > We are in process of migrating from one Data Center to another. > In this scenario, we might require to run Primary - HDR from different Data > Centers. > Is it feasible (from performance perspective) that HDR wont impact Primary > instances in a high volume OLTP Database ? > > Is there any technological difference as far as RSS & HDR are concerned ? > > Thanks. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --14dae9340e0b6308d704b5a29f7a
Thanks. We'll look into the scenarios, and evaluates the best possible solution for us. Thanks.