Re: Thoughts on the mirroring system etc

> -----Original Message-----
> From: Magnus Hagander [mailto:mha(at)sollentuna(dot)net]
> Sent: 20 January 2005 18:00
> To: Dave Page; pgsql-www(at)postgresql(dot)org
> Subject: RE: [pgsql-www] Thoughts on the mirroring system etc
>
> >As an example, I run www.uk.postgresql.org. On the 10th Jan, a date
> >picked pretty much at random, I logged 2448 http requests.
> Each hit on
> >the homepage results in about 30(!) httpd requests, so
> >represents as few
> >as 82 hits!
> >
> >Yesterday, release day, I only logged 2387 hits!!
>
> Which proves my point (and yours). Thanks :-)

Actually, looking at my terminology there - I meant requests, not hits.
Jan 10 was busier than the 19th. Which proves the point even more.

> >Yes - we are already planning to do this, and indeed some of the work
> >has been done. The mirror tracker checks whether or not a mirror will
> >respond to www.postgresql.org requests, and the backend
> database has a
> >flag to mark the 'primary' mirrors.
>
> Ok. All good. Though I beleive some of this is unnecessary - if you
> operate from the standpoint that *all* approved mirrors need to answer
> requests for www.postgresql.org.

Yeah, but it was written with slightly different aims in mind.

>
> >> Then do some "DNS magic" to do the load balancing:
> >
> ><snip DNS Magic>
> >
> >Yes, the current mirror tracker could easily be adapted to do this.
>
> Right. And IMHO, it should be moved off webmaster and have a separate
> system - it has different needs, and separation of critical
> services is
> good.

Absolutely.

> >> A similar solution for wwwmaster, of course.
> >>
> >
> >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.
>
> No, I beleive you can solve this. Let's assume we don't care
> if we can't
> add/remove news and events. AFAIK, then the database is almost only
> INSERTs right - answers to surveys, redirect logging etc?
> For this, create two tables, say "log1" and "log2". Where one of the
> servers each own one table, and only writes to that one. You
> set up two
> sets of slony replications, one in each direction. Then you create a
> view that is a UNION ALL of these, that's the one used when you read
> from the table.
> Simplified, but most of the time you can spot fairly easy ways to do
> this in the application.

Yeah, that'd work. Then we just have the news, events and docs etc. to
worry about.

So if we ran 2 wwwmasters, and say, four static primary servers, I guess
we would basically split them into 2 sets, so a pair of front ends and
one backend worked together?

Regards, Dave.