Re: Replication - Mailing list pgsql-performance

On 6/14/07, Craig A. James <cjames@emolecules.com> wrote:
> Looking for replication solutions, I find:
>
> Slony-I
>   Seems good, single master only, master is a single point of failure,
>   no good failover system for electing a new master or having a failed
>   master rejoin the cluster.  Slave databases are mostly for safety or
>   for parallelizing queries for performance.  Suffers from O(N^2)
>   communications (N = cluster size).

with reasonable sysadmin you can implement failover system yourself.
regarding communications, you can cascade the replication to reduce
load on the master.  If you were implementing a large replication
cluster, this would probably be a good idea.  Slony is powerful,
trigger based, and highly configurable.

> Slony-II
>   Seems brilliant, a solid theoretical foundation, at the forefront of
>   computer science.  But can't find project status -- when will it be
>   available?  Is it a pipe dream, or a nearly-ready reality?

aiui, this has not gone beyond early planning phases.

> PGReplication
>   Appears to be a page that someone forgot to erase from the old GBorg site.
>
> PGCluster
>   Seems pretty good, but web site is not current, there are releases in use
>   that are not on the web site, and also seems to always be a couple steps
>   behind the current release of Postgres.  Two single-points failure spots,
>   load balancer and the data replicator.
>
> Is this a good summary of the status of replication?  Have I missed any important solutions or mischaracterized
anything?

pgpool 1/2 is a reasonable solution.  it's statement level
replication, which has some downsides, but is good for certain things.
pgpool 2 has a neat distributed table mechanism which is interesting.
You might want to be looking here if you have extremely high ratios of
read to write but need to service a huge transaction volume.

PITR is a HA solution which 'replicates' a database cluster to an
archive or a warm (can be brought up quickly, but not available for
querying) standby server.  Overhead is very low and it's easy to set
up.  This is maybe the simplest and best solution if all you care
about is continuous backup.  There are plans (a GSoC project,
actually) to make the warm standby live for (read only)
queries...if/when complete, this would provide a replication mechanism
similar. but significantly better to, mysql binary log replication,
and would provide an excellent compliment to slony.

there is also the mammoth replicator...I don't know anything about it,
maybe someone could comment?

merlin