ER Domain behaviour

Hi All, Sorry in advance if I'm posting something obvious (busy, stressed, mostly little sleep), but I'm getting something I didn't expect. Setting up Replication - 11.70.FC8 server A - group 1 - machine x server B - group 2 - machine y server C - group 3 - machine z init A (RIS,ATS) cdr list server = connected local init B (RIS,ATS) --sync A. cdr list server = connected local and server A active This is all fine as expected, A and B are talking. OAT shows 2 servers with a line between them. init C (RIS,ATS) --sync A. cdr list server = connected local and server A active BUT cdr list server also shows server B (found my magic without me telling) not active though OAT shows as part of the domain with a triangle connecting all three Can I assume it finds by magic? And that no network traffic is going on unless active. Because I have to setup - potentially - DR using ER between site X and site Y with about 30 instances. And if they all suddenly find each other, my OAT picture looks like something from spirograph. But hopefully not actively connected. Or can someone suggest me a DR topology. As a side note... machine X has 20 servers synced to 20 servers on machine Y and on machine Z I have a single datawarehouse server built from 11 servers from machine X. How do I setup a DR failover scenario from X to Y and still write to DataWare on Z when the hardware breaks and I failover to Y? Primary target, update anywhere, grid somehow, oncm. And whilst I'm asking, if I use oncm where should I put copies of it. And the most basic setup for this DR topology. T (very much) IA, PP

Really I'm just interested for any potential overheads in having 100s of servers knowing about each other. If there is no overhead unless they are actually defined as being part of replication then it's fine. If there is a link to a manual page talking about what represents a domain and it's overhead (I like to try and know internals / why). The unexpected part is the OAT diagram, it's a little misleading drawing lines between B and C (in the linked example g_two sees g_three). fig 9 from here: http://www.ibm.com/developerworks/data/library/techarticle/dm-1003idsopenadmin/i ndex.html?ca=drs DR - Yes, I know about HDR and it's mainly sync vs async advantage. We use XML in blobs everywhere. And yes, we've been testing in table for blobs which is 10 times quicker and HDR looks good. We have to do some ER tests for the business.

"cdr define server - The cdr define server command defines a replication server in an Enterprise Replication domain. You can add a replication server to an existing domain or create a new domain" i.e. You start with an initial ER server in it's own domain, and then you add servers to the existing domain Not a lot of overhead, just a few "0,1,2,4,8,16,32" bit setting and comparison to establish whether data has been sent out to a sepcific ER id (not the group ID) and then that bit is reset when an ack is sent back from a target server. What do you see for "cdr list server"? That is your ER domain (in a fully connected topology)

Hi Jon, Thanks for the info. Good to know that there is very little overhead on the "non-used" connections if you get me. FYI: As you requested. Below cdrmajdevtar_rep_group is part of the domain but not [informix@ocvld-dbi*** er]$ cdr list server SERVER ID STATE STATUS QUEUE CONNECTION CHANGED ----------------------------------------------------------------------- cdrlnxdevtar_rep_group 164 Active Local 0 cdrmajdevpri_rep_group 160 Active Connected 0 Jul 2 11:58:58 cdrmajdevtar_rep_group 162 Active 83 Jul 2 11:59:06

Hi, The line between g_two and g_three in fig 9 in OAT is because they are part of the same domain (along with g_one) in an update-anywhere replication topology. The link below describes the various replication topologies that can be configured: http://www-01.ibm.com/support/knowledgecenter/SSGU8G_11.70.0/com.ibm.erep.doc/id s_erp_083.htm?lang=en Also in OAT, the number of messages sent/received between the nodes is listed in Replication -> Node Details (there's a Network section at the bottom of the Summary tab. There's also a separate Network tab with more details of network messages between the nodes). Regards, Sumanth. On Mon, Jun 30, 2014 at 11:09 PM, PETER PAIN <web@peterpain.com> wrote: > Really I'm just interested for any potential overheads in having 100s of > servers knowing about each other. If there is no overhead unless they are > actually defined as being part of replication then it's fine. If there is a > link to a manual page talking about what represents a domain and it's > overhead > (I like to try and know internals / why). > > The unexpected part is the OAT diagram, it's a little misleading drawing > lines > between B and C (in the linked example g_two sees g_three). > fig 9 from here: > > http://www.ibm.com/developerworks/data/library/techarticle/dm-1003idsopenadmin/i ndex.html?ca=drs > > DR - Yes, I know about HDR and it's mainly sync vs async advantage. We use > XML > in blobs everywhere. And yes, we've been testing in table for blobs which > is > 10 times quicker and HDR looks good. We have to do some ER tests for the > business. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --089e0158c74e03158304fe3158aa