On Tue, 12 Nov 2002 11:56:31 +0000 Nick Hill nick@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).