> > >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.
Oh, certainly, I wasn't implying anything else.
> > >> 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?
No, I'd go for keeping them all independent. E.g. 2 independent dynamic
and 4 independent static. KISS principle, again. And it makes it very
easy to add more static boxes if need be. Dynamic boxes are bit more
work, since they need to get db tables set up etc.
//Magnus
