On Mon, Dec 20, 2010 at 8:03 PM, <snoop@email.it> wrote:
>> On Mon, Dec 20, 2010 at 6:23 PM, <snoop@email.it> wrote:
> Well, I'd prefer a big single storage instead of "too many spinning disks"
> around mainly for maintenance reasons, to avoid replication and too much
> network traffic.
Sure, but that then makes your single point of failure your storage
system. With no replication the best you can hope for if the storage
array fails completely is to revert to a recent backup, since without
any streaming replication you'll be missing tons of data if you've got
many updates. If your database is mostly static or the changes can be
recreated from other sources that's not so bad. However, if you have
one storage array and it has a carastrophic hardware failure and goes
down and stay down, then you'll need something else to hold the db
while you wait for parts etc.
>> > - 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)
(P.s. that was pre 9.0 PITR...)
>> Streaming replication in 9.0 doesn't really work that way, so you
>> could use that now with a hot standby ready to be failed over to as
>> needed.
>
> Mmm, so I can use an hot standby setup without any need for replication
> (same data dir) and no need for STONITH?
> Sorry if my questions sound trivial to you but my experience with PostgreSQL
> is quite limited and this would be my first "more complex" configuration and
> I'm trying to figure out the best way to go. Unfortunately it's not that
> easy to figure it out going through the documentation only.
No no. With streaming replication the master streams changes to the
slave(s) in real time, not via copying WAL files like in previous PITR
replication. No need for STONITH and / or fencing since the master
database writes to the slave database. Failover would be provided by
whatever monitoring script you want to throw at the system, maybe with
pgpool, pgbouncer, or even CARP if you wanted (I'm no fan of carp, had
a lot of problems with it and CISCO switches a while back). Cut off
the main server, put slave server into recovery, when recovery
finishes and it's up and running, change the IP in the app config,
bounce app and keep going. With slony you'd do something similar, but
use slonik commands to promote the first slave to the master where
you'd bring up the slave in recovery mode in the streaming replication
method.
All of that assumes two machines with their own storage. (technically
you could put it all on the same big array in different directories).
If you want to share the same data dir then you HAVE to make sure that
only one machine at a time can ever open that directory and start
postgresql there. Two postmasters on the same data dir are instant
death.