FOSS gamedev and creative worlds

I was recently talking with a friend on a server about failover and load-balancing, and an idea started to form in my head, using MySQL and replication, but we've had a few problems, that I'd like to discuss.

• Chunk race conditions-If there are multiple servers, chunk updates will get mangled as chunks are updated as a whole, leading to race conditions.
• Database engine- MySQL would need to become an option in Minetest
• ABM sharing- ABMs are not per-action, so they would potentially get run twice. So, subdivide ABMs across all of the online nodes. Things like on_generate and register_on_dignode are not as important since those will be localized to a specific server.
• Non-database files in woldpath-How would these files(used by mods) be shared? Will mods need to use the database?

Anyone have any suggestions/ideas for handling these? I'd like to see support for this in the engine.

It seems like overkill for such a simple game, I'd say. Still...

You'd probably want all the writable files to move to the database, so the issue of sharing them between servers just looks like the same database problem. Then the easiest thing would probably be to have game servers "check out" chunks as they needed them in order to do mapgen and ABM execution. For chunks that need to be active but that no server currently has a direct interest in, you could possibly setup a queue of jobs to run, and servers call pull from the queue when they have some extra processing cycles available.

The most difficult thing would probably be figuring out where to route client requests. I suggest looking at SecondLife/OpenSim for helping to figure out this sort of distributed architecture. They distribute things very much by spatial geometry, but even if you didn't want to do that the communication challenges are going to have many similar aspects.

I was thinking something as simple as round-robin DNS, where any of the nodes can receive client requests, and then if will figure it out on its own. About the chunk issue, that would work for scheduling things, but not for handling client requests that come in. The database would have to become node-based, causing spikes in size.