[Pgcluster-general] Failover of PGReplicate

Josef.Bajada at go.com.mt Josef.Bajada at go.com.mt
Tue Jan 9 09:13:25 UTC 2007


Hi Tomas and Mitani,

Thanks for your answers. Yes I understand that once the master replicator 
goes down and the stand-by is promoted to master, it becomes the master. 
However, the problem becomes more complicated when one brings up the node 
that failed and, if one starts first the original master replicator and 
then the ClusterDB, the started ClusterDB connects to the original master 
replicator and not the current master replicator.

Do the replicators communicate between each other? Maybe makes sense to 
have some kind of framework which helps a ClusterDB connect to the correct 
replicator and not the first one in the list. I think this problem will 
happen easily, even if you have each module running on an independent 
physical server. Ex: when more than one nodes fail simultaneously due to 
some power problem and the failover servers kick in, the same issue might 
happen when the failed nodes are being restarted.

regards,
Josef





"Tomás A. Rossi" <tomas at mecon.gov.ar> 
Sent by: pgcluster-general-bounces at pgfoundry.org
08/01/2007 19:19
Please respond to
pgcluster-general at pgfoundry.org


To
pgcluster-general at pgfoundry.org
cc

Subject
Re: [Pgcluster-general] Failover of PGReplicate






I've done some experiments (and made failover work, at least for a while). 
It seems that when the "primary" replicator restores (i.e. the situation 
Josef described), it doesn't get active again till the "secondary" goes 
down :)

Now I understand Mitanis answer... the "secondary" becomes master and the 
"primary" becomes a slave (when restored), and this only changes if the 
current master goes down. So, there's no primary/secondary/... scheme, 
only a single current replicator and N idle replicators waiting to be 
useful is master falls.

Regards,
--
Tom;

Tomás A. Rossi escribió: 
Sorry, as I see it, the question hasn't been answered. He asked if the 
"secondary" node should detect that the "primary" is up again, and then 
restore the original behavior (i.e. root replication server getting active 
again in the whole replication schema).

Regards,
--
Tom;

a.mitani at sra-europe.com escribió: 
Hi,

The replication server is used for queueing queries.
Therefore, all cluster db must connect same replication server.

Replication server has not primary / secondary order.
It has just active / stand-by mode.

Regards,
-------------------
At.Mitani

 
Lets say I have 2 nodes, each running PGReplicate and ClusterDB. The node
running the primary PGReplicate fails and the ClusterDB on the second node
automatically fails over the PGReplicate of the first node. However, when
I restart node1, the ClusterDB of node2 seems to remain connected to
PGreplicate of node2, and thus any changes done on node 2 are no longer
reflected on node1, and viceversa.

Is ClusterDB supposed to realise that the primary replicator has been
restored so that all clusterDBs access the same replicator?

regards,
Josef

_______________________________________________
Pgcluster-general mailing list
Pgcluster-general at pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgcluster-general

 

_______________________________________________
Pgcluster-general mailing list
Pgcluster-general at pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgcluster-general
 



_______________________________________________
Pgcluster-general mailing list
Pgcluster-general at pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgcluster-general
 
_______________________________________________
Pgcluster-general mailing list
Pgcluster-general at pgfoundry.org
http://pgfoundry.org/mailman/listinfo/pgcluster-general

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/pgcluster-general/attachments/20070109/9f0f827c/attachment.html 


More information about the Pgcluster-general mailing list