Have you looked at a 'shared storage' solution based on DRBD ? I configured a test environment using SLES HAE and DRBD with relative ease and it behaved very well (can probably supply a build script if you like), there are lots of people running production systems on similar setups although I think it deserves a solid test and soak period. I was looking at this to form a high performance storage tier based on fusion-io hardware.
I guess you need to evaluate the failover and failback mechanisms for each scenario (shared storage on DRBD and streaming replication with trigger file etc) and see if block level replication complexity up front is more or less of a headache than managing the application side replication with somewhat more clunky control mechanisms. ________________________________ From: Tim Uckun <timuc...@gmail.com> To: Andy Colson <a...@squeakycode.net> Cc: John R Pierce <pie...@hogranch.com>; pgsql-general@postgresql.org Sent: Tuesday, 17 January 2012 12:21 PM Subject: Re: [GENERAL] HA options > > I wonder. If its a write heavy database, I totally agree with you. But if > its mostly read-only, and mostly fits in ram, then a pgpool of servers > should be faster. > > Be nice to know the usage patterns of this database. (and size). > In this case the databases are small to medium and the usage is relatively light. The main concern is availability and not scalability although that will probably come into play later on. For our performance profile we are OK with using virtual servers *at this time*. I will need HA no matter what underlying hardware I use but as you guys have pointed out using virtual servers means a shared nothing approach for now so I was asking about the pros and cons of the various projects I listed and people's experiences of them. I have read the basic introductions to the various projects and have a rough idea of what they are trying to do but when it comes to implement something like this the devil is in the details. I am curious if anybody has used them in production environments and if given a chance they would go the same route or try something different. My use case is pretty simple and I would think extremely common which is that "the database must be up no matter what". In addition to having some sort of a failover I want to implement log shipping to a remote location and keeping a hot/warm standby there. Anything over and above that would be icing on the cake.. Things like adding nodes on the fly, being able to upgrade without downtime, failing back without having to do a full backup, multi master, etc are very desirable things to have but *at this time* I can do without them. Cheers. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
