RE: omni-directional cascading Enterprise Replication
> -----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 excessive sig. Big Boss insists the mail server adds it. --------------------------------------------------------------------- This email is from Civica Pty Limited and it, together with any attachments, is confidential to the intended recipient(s) and the contents may be legally privileged or contain proprietary and private information. It is intended solely for the person to whom it is addressed. If you are not an intended recipient, you may not review, copy or distribute this email. If received in error, please notify the sender and delete the message from your system immediately.Any views or opinions expressed in this email and any files transmitted with it are those of the author only and may not necessarily reflect the views of Civica and do not create any legally binding rights or obligations whatsoever. Unless otherwise pre-agreed by exchange of hard copy documents signed by duly authorised representatives, contracts may not be concluded on behalf of Civica by email. Please note that neither Civica nor the sender accepts any responsibility for any viruses and it is your responsibility to scan the email and the attachments (if any). All email received and sent by Civica may be monitored to protect the business interests of Civica. ---------------------------------------------------------------------
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 excessive sig. > Big Boss insists the mail server adds it. > > --------------------------------------------------------------------- > This email is from Civica Pty Limited and it, together with any attachments, > is confidential to the intended recipient(s) and the contents may be legally > privileged or contain proprietary and private information. It is intended > solely for the person to whom it is addressed. If you are not an intended > recipient, you may not review, copy or distribute this email. If received in > error, please notify the sender and delete the message from your system > immediately.Any views or opinions expressed in this email and any files > transmitted with it are those of the author only and may not necessarily > reflect the views of Civica and do not create any legally binding rights or > obligations whatsoever. Unless otherwise pre-agreed by exchange of hard copy > documents signed by duly authorised representatives, contracts may not be > concluded on behalf of Civica by email. Please note that neither Civica nor > the sender accepts any responsibility for any viruses and it is your > responsibility to scan the email and the attachments (if any). All email > received and sent by Civica may be monitored to protect the business > interests of Civica. > ---------------------------------------------------------------------
Andrew, Thanks for the input. I agree on the 1-N performance, if it was all done in one replicate. But my -n databases are all on the same server. This means that I have to create seperate replicates for each 'N' server. My assumption is that each of those replicates will have to detect and analyze the row itself, therefore realistically effecting performance. I'm currently testing the performance of one replicate versus four (our N) replicates. And one replicate versus none to get a base line. I will update this thread with the results once I get them. Thanks again, and any other input is welcome. Paul 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 excessive sig. > Big Boss insists the mail server adds it. > > --------------------------------------------------------------------- > This email is from Civica Pty Limited and it, together with any attachments, > is confidential to the intended recipient(s) and the contents may be legally > privileged or contain proprietary and private information. It is intended > solely for the person to whom it is addressed. If you are not an intended > recipient, you may not review, copy or distribute this email. If received in > error, please notify the sender and delete the message from your system > immediately.Any views or opinions expressed in this email and any files > transmitted with it are those of the author only and may not necessarily > reflect the views of Civica and do not create any legally binding rights or > obligations whatsoever. Unless otherwise pre-agreed by exchange of hard copy > documents signed by duly authorised representatives, contracts may not be > concluded on behalf of Civica by email. Please note that neither Civica nor > the sender accepts any responsibility for any viruses and it is your > responsibility to scan the email and the attachments (if any). All email > received and sent by Civica may be monitored to protect the business > interests of Civica. > ---------------------------------------------------------------------