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@xxxxxxxx> 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@xxxxxxxx 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
