I would be interested in participating in the sourceforge repository too. Here
at work we're planning to go live with pgcluster, and any improvements that
can be applied to the product are most welcome.
I have already duplicated work with Rick, implementing a configurable
delta-rsync instead of the current full one, so it's obviously desirable to
have a common repository.
I think it would be interesting to know how A. Mitani feels about this
proposal. And in case he's alright with it, if he has more recent sources
than 1.5.0rc7.
Diego Gutierrez
On Wednesday 23 August 2006 13:59, Rick Vernam wrote:
> On Wednesday 23 August 2006 11:42, Chahine Hamila wrote:
> > > Good. We need it to be fault tolerant in fact. We should be able to
> > > savagely unplug a node without affecting the cluster's stability,
> >
> > When trying to connect to an unavailable node the replicator will, by
> > default, make numerous attempts to contact a node, stalling for a good
> > amount of time between each connection attempt. The client side
> > experience in this scenario is that the database is just not responding.
> > I changed that behavior so that the replicator tries once, and drops the
> > node if that attempt failed.
> > Also, even with the load balancer, existing connections to the downed
> > node are not 'forwarded' to one of the other cluster nodes. The client
> > will have to reconnect. This is one feature I've wanted to add to the
> > load balancer, but just have not had the time.
> >
> > I would be interested in that patch. To make development/integration of
> > those patches easier, would you be interested in participating in a CVS
> > repository (say on sourceforge) where we?d commit our respective changes?
>
> Sure. Btw, that would be a new experience for me...so you'd have to
> forgive my lack knowledge in that area.
>
> > (If my company decides to move on with it of course which is not a given,
> > this kind of problem has made some people nervous with pgcluster).
> >
> > > while
> > > running in reliable mode and keeping read_write for each standalone
> > > node. Rejoining nodes should rsync anyway, so that shouldn't be a
> > > problem (we don't mind losing data on the unplugged nodes as long as
> > > they resync with the cluster on joining back). So far, we haven't
> > > succeeded in doing that on a consistent basis. Have you experienced the
> > > death of a node or similar conditions? If yes, what was the impact?
> >
> > Yes, I've created that scenario many times over. You said that you
> > haven't succeeded on a consistent basis. what kind of problems are you
> > encountering?
> >
> > I haven?t identified exactly the conditions in which it occurs, but I
> > can reach a state where all nodes hang on their next query respectively,
> > until we stop pgreplicate, in which case they resume normal operations,
> > though in stand alone mode (meaning we have to restart pgreplicate and
> > resync).
>
> Does this happen during normal operation, or during recovery?
>
> > During recovery, the replicator will, by default, move your database
> > files to a backup location and rsync the entire database over. I?ve
> > created a patch that allows you to change this behavior, via one of the
> > configuration files, so that the replicator does not do the backup and
> > only rsyncs the necessary files. Potentially saves lots of time and
> > bandwidth during recovery. Also, during recovery the cluster can only
> > absorb so many replicated queries before it chokes and dies (queue gets
> > full), and leaves the cluster in general in a very unreliable state. I
> > have not really fixed the problem, but can provide you with lots of
> > details about the problem if you?d like.
> >
> > Definitely, a non robust or non fault tolerant system is not an option
> > for us, so if we decide to go on with pgcluster, we?ll have to fix those
> > problems.
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Get on board. You're invited to try the new Yahoo! Mail.
>
> _______________________________________________
> Pgcluster-general mailing list
> Pgcluster-general@xxxxxxxxxxxxx
> http://pgfoundry.org/mailman/listinfo/pgcluster-general
|
