Re: omni-directional cascading Enterprise Replication

Madison, Thanks for the reply. Yes, this is exactly what I'm trying to do: > If you want to replicate a table from A->B->C, then you would need to > define the participants as: > > cdr define replicate ........ \\ > "P db@serv_A....." "Select * from ...." \\ > "R db@serv_B....." "Select * form ...." \\ > "R db@serv_C....." "Select * from ...." Unfortunately I didn't know the optimal way to define the server, so I did it similar to: > cdr define server -c serv_A -I serv_A > cdr define server -c serv_B -I -S serv_A serv_B > cdr define server -C serv_C -I -S serv_A serv_c > Previously I was going from A-B and then had a different replicant to defined to go from 'B-C'. I preferred this method, because my 'C' is actually 4 different databases, so I wanted to get the load off of 'A'. I came to the reality that data that is replicated from A-B will not be forewarded on by a replicant defined on B. That is when I switched to the method discussed above. Now using this method I run into a different issue. It has a problem with the fact that all of my 'C' servers are really just different databases all on the same server. So it allows me to do A->B->C, but if I try and define it with multiple DB's on the 'C' server, I get an error that the server is already present in the replicant. For Example: cdr define replicate ........ \\ "P db@serv_A....." "Select * from ...." \\ "R db@serv_B....." "Select * form ...." \\ "R db@serv_C....." "Select * from ... where cd = '1'" \\ "R db1@serv_C....." "Select * from ... where cd = '2'" \\ "R db2@serv_C....." "Select * from ... where cd = '3'" \\ Errors out, so what I have to do is the following: cdr define replicate ........ \\ "P db@serv_A....." "Select * from ...." \\ "R db@serv_B....." "Select * form ...." \\ "R db@serv_C....." "Select * from ... where cd = '1'" \\ cdr define replicate ........ \\ "P db@serv_A....." "Select * from ...." \\ "R db1@serv_C....." "Select * from ... where cd = '2'" \\ cdr define replicate ........ \\ "P db@serv_A....." "Select * from ...." \\ "R db2@serv_C....." "Select * from ... where cd = '3'" \\ Now my assumption here is that this will infact impact performance, because we are going to incur the overhead of determining if a row needs to be replicated 3 times. As I said in my other post, I'm working on benchmarking this, and will post results when I have them. My assumption is that this is occurring because I have serv_c in the replicant multiple times. Is there anyway around this? Could I somehow in my sqlhost file just add additional server groups that point back to the same server? So my solution to this was to create 4 different replicants. Like so: cdr define replicate ........ \\ "db@serv_A....." "Select * from ...." \\ "db@serv_B....." "Select * form ...." \\ "db@serv_C....." "Select * from ... where cd = '1'" \\ "db1@serv_C....." "Select * from ... where cd = '2'" \\ "db2@serv_C....." "Select * from ... where cd = '3'" \\ mpruet@us.ibm.com (Madison Pruet) wrote in message news:<60188682.0305220405.4c7c7404@posting.google.com>... > ER makes a distinction from the topology and the peer replicate nodes. > > If you have somthing like A <---> B <---> C, then you will need to > define what the source/target nodes are. So you might define the > topology to be 'A' is the parent of 'B' and 'B' is the parent of 'C'. > But if you want to replicate between A and C, then A and C must be the > defined terminal points in the replicate. > > As an example, we could define the topology as all connect --- > > > A > / \\ > B---C > > > cdr define server -c serv_A -I serv_A > cdr define server -c serv_B -I -S serv_A serv_B > cdr define server -C serv_C -I -S serv_A serv_c > > or we could define a hierarchy > > A > / \\ > B C > > > cdr define server -c serv_A -I serv_A > cdr define server -c serv_B -I -N -S serv_A serv_B > cdr define server -c serv_C -I -N -S serv_A serv_C > > But the same replicate definitions could be done on either topology. > > If you want to replicate a table from A->B->C, then you would need to > define the participants as: > > cdr define replicate ........ \\ > "db@serv_A....." "Select * from ...." \\ > "db@serv_B....." "Select * form ...." \\ > "db@serv_C....." "Select * from ...." > > Andrew Hamm <AHamm@civica.com.au> wrote in message news:<bah4m2$rup$1@terabinaries.xmission.com>... > > > -----Original Message----- > > > From: paul.esposito@attbi.com [mailto:paul.esposito@attbi.com] > > > Sent: Thursday, 22 May 2003 05:35 > > > To: informix-list@iiug.org > > > Subject: omni-directional cascading Enterprise Replication > > > > > > Is A-B B-C possible? I found other posts that says it is not, but one > > > that seems to say if it is one directional, that it can be done. > > > > > > I can get it to replicate A-B and A-C, so I know the set up is > > > correct, but I'm concerned about the performance, because their are > > > actually multiple C-level servers I need to go to. I would rather use > > > B as the driver to populate the C's rather than A. > > > > My understanding is that cascading isn't "ready" yet - although I might be > > wrong about that. The course was two years ago and the last time I setup ER > > on a site was probably a year ago. However... > > > > The ER manual, which you will find on the Informix Online CD, covers all the > > details and if it can work then you should find details in there. > > > > I am quizzical about your concerns about performance. I'm not sure that's a > > realistic problem. Detecting, analysing and queuing rows to replicate has > > got to be the hardest part of the job. Once it's in the send queue, A only > > has to transmit the rows to the other machines, and that's quite > > light-weight work. > > > > Then it falls to the B machine to analyse the new row within it's own > > context and decide how to handle it, and that work does not affect A. So I > > really don't expect 1:N replication to cost much in performance compared to > > 1:1. I'm sure you'll be able to notice the difference as you bring on more B > > servers if it's going to cause a slow-down. > > > > So in the meantime I suggest setting up a simple 1:N relationship to all the > > target machines, pay attention to how the performance "feels" and get the > > machinery working for people. > > > > Don't forget, your goal is to take load off A for reporting purposes, so if > > the reporting load is that high, the load from a bit of ER ain't gonna feel > > that bad in comparison. > > > > -- > > Apologies for the exces