I am by no means a expert on this, but I believe that by default with only one node left, the cluster goes into Read Only and won't accept writes, so in theory, with a two node cluster you would just have to bring back the failed node. You may however, just to be on the safe side, bring the failed node up with -R since, well, who knows if you had file corruption when the node went south.
The relevant cluster.conf setting is <When_Stand_Alone> read_only </When_Stand_Alone> If you've changed that, then yes, you absolutely have to bring back a failed node with -R as the replicator does not keep track of transactions that have occurred. On Thu, 2008-08-28 at 09:04 -0500, David Schlenk wrote: > I'm new to pgcluster and have a question about how its supposed to work. > > In my test cluster, I have two DB/cluster nodes. I have two cascaded > replicators working using RLOG (which, btw, it would be nice to add a blurb > to the install document about how to do this... I had to dig through the > mailing list to figure out how to configure it properly) and a couple load > balancers (although the intent is to use only one at a time and have the > second kill the first if it detects a problem and then take its IP). I've > been testing recovery, and my question is this: > If I shut down one of the DBs, then perform a write, then bring that DB back > up, should the replicator notice that it's behind and push any pending > writes to it? Or do you have to start with the -R option for recovery to > happen? My concern is that if one DB goes down, some writes happen, then the > 2nd goes down, if you bring up the node that went down first, then bring up > the other node in recovery mode you'll lose any writes that happened after > the first DB went down.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Pgcluster-general mailing list [email protected] http://pgfoundry.org/mailman/listinfo/pgcluster-general
