postgresql master slave setup on the same machine

postgres.sh

pg_createcluster 9.1 testing --start #/etc/postgresql/9.1/testing/
pg_lsclusters 


pg_dropcluster 9.1 testing --stop
#follow with rm -rf or potential error
rm -rf /var/lib/postgresql/9.1/testing/


Moved the Write Ahead Log (WAL) to its own partition (so fsyncs of the WAL don't flush all of the dirty data files)
Moved the WAL to its own pair of disks (so the sequential writes of the WAL are not slowed down by the random read/write of the data files)

 We still had to migrate merchants to a different shard (without downtime). We did this with londiste, a statement-based replication tool. We set up the new database servers and used londiste to mirror the entire database between the current cluster (which we renamed to shard 0) and the new cluster (shard 1).

Then, we paused traffic[1], stopped replication, updated the shard column in the global database, and resumed traffic. The whole process was automated using capistrano. At this point, some requests went to the new database servers, and some to the old. Once we were sure everything was working, we removed the shard 0 data from shard 1 and vice versa. 

 don't increment the timeline on failover. Instead, we stop PostgreSQL, remove the recovery.conf, and restart.
We use a keepalived pair to shoot the old node in the head and promote a synchronous slave to a master in case of failure.

https://www.braintreepayments.com/braintrust/switching-datacenters
http://library.linode.com/linux-ha/highly-available-file-database-server-ubuntu-10.04?format=source
http://drewolson.org/braintree_ha/presentation.html#slide-15
https://www.braintreepayments.com/braintrust/scaling-postgresql-at-braintree-four-years-of-evolution