On Tue, 12 Nov 2002 11:56:31 +0000
Nick Hill <nick(a)nickhill.co.uk> wrote:
A scalable solution is to give nearly all
responsibility for all wiki
functionality to mirror servers. Updates are posted directly to the main
Wiki server which in turn posts the database updates to registered first
tier mirrors which, in turn, can post database updates to second tier
mirrors registered with them and so on.
With such a scheme, IP blocking and anti-vandalism features would still be
implemented in much the same way as they are now, on the main server, where
the master database is held. The master server would handle html form puts.
This way, all mirrors can be kept
in sync in near real time with a minimum of CPU, memory and network load.
The main server then need do nothing other than maintain database
consistency, accept and post updates.
The update system can be achieved by either:
1) the main server creating SQL files to be emailed to mirror servers,
signed with a key pair, sequentially numbered to ensure they are
automatically processed in order this way, the server can run
asynchronously with the mirrors which is better for reliability of the
server. The server will not need to wait for connection responses from the
mirror and updates will be cached in the mail system should the mirror
be unavailable. The server will only need to create one email per update.
The mail system infrastructure will take care of sending the data to each
mirror. In fact, a system such as pipermail used on this list would solve the
problem wonderfully. Mirror admins simply subscribe to the list to get all
updates sent to their machine and can manually download updates they are
missing from the list!)
Or
2) by the master server opening a connection directly to the SQL daemon on
each remote machine In which case the server will need to track what
the mirrors have and have not received updates and need to wait for
time-out on non-operational mirrors)(this system may open exploits on
the server via the sql interface).