Re: PostgreSQL in Shared Disk Failover mode on FreeBSD+CARP+RAIDZ

Well, under this point of view I feel a bit lucky now. Having built-in
streaming replication is a big advantage and gives me the chance to
avoid third party applications. Despite there are good solutions out
there I believe that less complexity is always better.
Plus, I would really like to avoid a STONITH device .... sounds an
expensive and pretty critical solution.
Of course everything has his advantages/disadvantages but I'd like to
build something reliable/not too much expensive and most important thing
scalable. In the future you never know. I wouldn't like to regret being
successful because of a very bad initial design. :)

Cheers.

On Wed, 2010-12-22 at 21:58 +0000, robin wrote:
> With such low volumes you can probably take your pick of technologies
> based on your other requirements/interests/desires.
>
> That said, I too would start with the built in streaming replication - we
> would have done that with our project, but it wasn't available when we
> started (a looooong time ago ;-)).
>
> Instead we used DRBD and Heartbeat, plus a STONITH device, to provide
> resilience against disk or other hardware failure.
>
> When the current hardware gets replaced, we'll almost certainly migrate to
> streaming replication as part of the migration to new hardware.
>
> Cheers,
> Robin
>
> On Wed, 22 Dec 2010 20:52:28 +0100, Snoop <snoop@email.it> wrote:
> > It's hard to say Robin, I'm still in testing.
> > At the beginning I'd say very low ... probably something between 2000
> > and 5000 transactions a day (even harder to imagine how this load it's
> > gonna be distributed within 24 hours)?!
> >
> > Thanks for your reply.
> >
> > On Tue, 2010-12-21 at 08:02 +0000, robin wrote:
> >> How much data and what sort of write rates do you actually expect?
> >>
> >> Cheers,
> >> Robin
> >>
> >> On Tue, 21 Dec 2010 02:23:25 +0100, snoop@email.it wrote:
> >> > Hi everybody,
> >> > I'm trying to figure out a way to setup a PostgreSQL HA cluster
> >> solution.
> >> >
> >> > For the record:
> >> > - I've already tried pgpool-II 2.x in Synchronous Multi Master
> >> Replication
> >> > mode and I was satisfied by it's functionality but concerned about
> >> having
> >> > the same data growing on several nodes
> >> > - I've upgraded to pgpool-II 3.0.x on FreeBSD (from ports) but it's
> >> > very
> >> > buggy at the moment
> >> > - I don't like the idea of having fixed size (16 megs regardless of
> the
> >> > committed transaction number!) WAL logs often "shipped" from one node
> >> > to
> >> > another endangering my network performance (asynchronous replication)
> >> >
> >> > I've done some research and I've an idea of different possible
> >> solutions,
> >> > but I'd honestly like to implement it using CARP in a "Shared Disk
> >> > Failover"
> >> > fashion.
> >> > Unfortunately this doesn't really seem to be a common way according
> to
> >> the
> >> > very limited information available on the net and that's why I'm
> going
> >> to
> >> > ask here.
> >> >
> >> > My idea: two nodes (i386) with FreeBSD 8.1 and PostgreSQL 9.0.2, CARP
> >> > providing network failover and a shared data dir on a RAIDZ solution.
> >> I'm
> >> > pretty sure that CARP would do the job properly indirectly avoiding
> >> > even
> >> > the
> >> > dangerous writing on the data dir from both nodes at the same time
> >> > (that
> >> > would apparently badly screw up the DB) by redirecting any network
> >> > connection to the active DB and to him only.
> >> >
> >> > BUT ... I'm seriously concerned about the already active connections
> >> client
> >> > <-> server during the failover.
> >> > Example:
> >> >
> >> > client A connects to server A
> >> > server A fails so does the client A connection
> >> > CARP redirects any upcoming connection to the DB to server B now
> >> > client A reconnects and is now operating on server B
> >> > THEN
> >> > server A comes back up
> >> > CARP now obviously redirects any new connection to the DB to server A
> >> again
> >> > client B connects to server A
> >> > what about the existing connection of the client A to the server B?
> >> there's
> >> > an existing connection state between client A and server B
> >> > now there's the chance that a transaction can be committed on the
> >> > server
> >> B
> >> > while there's someone else operating on server A too!
> >> >
> >> > I understand that in a server that doesn't commit many transaction
> but
> >> is
> >> > mainly answering queries this could be a remote situation but it can
> >> > probably happen.
> >> > Please correct me if I'm wrong (as I really hope to be).
> >> >
> >> > Did anyone here try such a configuration by any chance?
> >> >
> >> > Many thanks in advance for your time.
> >> >  --
> >> >  Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e
> >> SMTP
> >> > autenticato? GRATIS solo con Email.it: http://www.email.it/f
> >> >
> >> >  Sponsor:
> >> >  Paghe e stipendi, consulenza e collocamento, tutto con Emailpaghe!
> >> Provalo
> >> > gratuitamente fino al 31/12/2010
> >> >  Clicca qui:
> >> http://adv.email.it/cgi-bin/foclick.cgi?mid=10682&d=20101221
> >
> >
> >
> >
> >  --
> >  Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e
> SMTP
> >  autenticato? GRATIS solo con Email.it http://www.email.it/f
> >
> >  Sponsor:
> >  MisterCupido.com crea i tuoi regali personalizzati ai prezzi più bassi
> >  del web... e questa settimana ci sono più sconti che mai!
> >  Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11031&d=22-12