[Pgcluster-general] Failover of PGReplicate

a.mitani at sra-europe.com a.mitani at sra-europe.com
Tue Jan 9 10:11:50 UTC 2007


OK, I got your issue now.

In this case, please start the Cluster DB with recovery option ahead of
the "original master replicator" re-start.

Because the status of replication server is stored in each Cluster DB,

I think that replication server should do life check each other...

Regards,
---------------
At.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疽 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疽 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
>
> _______________________________________________
> Pgcluster-general mailing list
> Pgcluster-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgcluster-general
>



More information about the Pgcluster-general mailing list