Skip site navigation (1) Skip section navigation (2)

Re: Thoughts on the mirroring system etc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
Cc: "Magnus Hagander" <mha(at)sollentuna(dot)net>, pgsql-www(at)postgresql(dot)org
Subject: Re: Thoughts on the mirroring system etc
Date: 2005-01-22 19:15:20
Message-ID: 24564.1106421320@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-www
"Dave Page" <dpage(at)vale-housing(dot)co(dot)uk> writes:
> The major problem with wwwmaster is that we need multimaster replication
> to handle it properly, without having a single point of failure. Slony 1
> will not resolve that basic issue.

This is a bogus conclusion, and the later-proposed solution involving a
UNION view is just silly.

Supposing that you replicate the database to one or more other machines
via Slony-I, you have a defense against complete loss of wwwmaster,
namely you can just (manually) decree that one of the other copies is
now the master.  So that solves one of the problems posed.  The other
problem this poses is getting the web server machines to hit a working
copy of the database when they need to serve up dynamic content.  That
problem has zero to do with your replication technology.  I think a
DNS-based solution similar to Magnus' proposal would work fine.

Multimaster replication is only important if you need reliable 24x7
updating of the database, which as far as I understand isn't needed for
this one.  So a single master (at a time) ought to work fine, and that
can be handled just fine with Slony-I.

Having just returned from Afilias' mini conference about design of
Slony-II, I can tell you that multimaster replication isn't right
around the corner ;-).  It's gonna take some work.

			regards, tom lane

In response to

pgsql-www by date

Next:From: Magnus HaganderDate: 2005-01-22 19:44:32
Subject: Re: Thoughts on the mirroring system etc
Previous:From: Robert BernierDate: 2005-01-22 16:01:31
Subject: Re: request: search engine for PostgreSQL site

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group