Hi Mitani, thank you for your quick answer! > Hi Markus, > > First of all, compsition of replication server is single master and multi > slave. > Therefor, cluster2 should be use replicator1 as same as cluster1. > > As you know, rlog data alway send to lower replication server from upper > replication server. > If upper replication server failed down during replicating commit query, > lower replication server might send rlog commands to each clusters in order > to finish transaction. > ok, now i understand a bit more!
so if i keep my configuration as mentioned only overhead is produced, because each query to cluster2 is sent to replicator2 and then replicator2 will check if query was executed. right? > I know that this rlog function is a bit complicated. > When you have any question, please feel free to inquire. > > Regards, > -------------- > At.Mitani another question: will replication work if i keep the mentioned config but remove cascading and rlog?? Regards, Markus Schmidleitner > -- original message -- > From: Markus Schmidleitner<[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Fri, 27 Jun 2008 09:50:11 +0200 > Subject: [Pgcluster-general] rlog issue > > >hi list, hi mitani! > > > >i'm currently working on backporting some stuff from the cybercluster > >project to pgcluster and doing some code-refactoring (make > >network-operations centralized and non-blocking, remove dead code and so > >on). > > > >while invastigating the rlog code i found out that rlog's are always > >sent to lower cascade but never to the upper one. could anyone explain > >why? > > > > > >for example assume following system composition: > > > >replicator1 ---- replicator2 > > | \ / | > > | /\ | > > | / \ | > > | / \ | > > cluster1 cluster2 > > > > > >- cluster1 has replicator1 as replication server > >- cluster2 has replicator2 as replication server > >- replicator1 has cluster1 and cluster2 as cluster server > >- replicator2 has cluster1 and cluster2 as cluster server > >- replicator1 is upper and replicator2 is lower > > > >(i know this is quiet a little strange config but it is necessary for us > >- we have multiple database nodes (server) and each of them runs a > >cluster and a replication server - each cluster is connected to it's > >local replicator, each replicator is connected to all clusters and the > >replicators are cascaded) > > > > > >for example performing INSERT on cluster1: > > > >？？as far as i understand rlog is working the following way: > > 1. cluster1 sends query to replicator1 > > 2. replicator sends query over rlog-method to lower cascade > >(replicator2) > > 3. replicator1 executes query on cluster2 and cluster1 (eg. sends some > >ok-message to source (cluster1) and executing query on cluster2) > > 4. cluster2 sends query to replicator2 > > 5. replicator2 recognizes the executing query comes from rlog, check > >wheter the query was executed on cluster2 and send result back to > >cluster2 > > 6. cluster2 and cluster1 send result back to replicator1 > > 7. replicator1 send some ok-message back to cluster1 (source) > > > >i think that's a short description of how rlog is working. > > > > > >so what about if source is cluster2? > >replicator2 will not perform any rlog becouse rlog-messages are only > >sent to lower cascade! > >is this expected behavior or a bug???? > > > >is there any other check to prevent replication missbehavior and if so, > >why using still rlog? am i missing something? > > > > > >my backport is working nicely so far and as soon as i finished all of my > >tests i will put a patch on the list! > > > > > >regards, > >Markus Schmidleitner > > > > > >__________________________________________________________________________________ > >Dieses Mail wurde vom Infotech SecureMail Service ueberprueft und fuer > >sicher befunden. > >Fuer weitere Informationen zu Infotech SecureMail Service waehlen Sie bitte: > >www.infotech.at > > > >This email has been scanned by Infotech SecureMail Service and it has been > >classified as secure. > >For more information on Infotech SecureMail direct your web browser to: > >www.infotech.at > > > >_______________________________________________ > >Pgcluster-general mailing list > >[email protected] > >http://pgfoundry.org/mailman/listinfo/pgcluster-general > > > _______________________________________________ Pgcluster-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgcluster-general
