[MUD-Dev] World Persistence, flat files v/s DB v/s ??

J C Lawrence claw at under.engr.sgi.com
Wed Apr 1 12:48:07 New Zealand Daylight Time 1998

On Tue, 24 Mar 1998 23:33:44 PST8PDT 
Adam Wiggins<nightfall at user2.inficad.com> wrote:

> I never got around to trying that idea that came up here (I can't
> remember who thought of it - maybe it was me) a while back, about
> having a parallel process running which did nothing but take a
> snapshot of the DB every n units of time and then dump them to disk
> in a leisurely manner.  This process would not crash when your
> regular server would; instead it would just sit there holding its
> latest snapshot.  When the server resurrected itself it would
> request the DB snapshot back from the secondary process, and then
> continue as normal.  Your disk writes could be as infrequent as you
> like; I'd probably pass them to yet another process running at the
> lowest possible priority, maybe even sending the data in chunked out
> spurts of like 500k.  But really, it shouldn't matter - short of the
> janitor tripping over the power cord, the secondary process (which
> should, of course, never crash - a piece of code that small should
> be easy to make bullet-proof) will just retain an in-memory copy.
> In theory you could update it as often as every ten seconds.

This seems related to an idea I discussed on this list back about this 
time last year (I think), except that I didn't do the forking side.

Instead the server would periodically elect to do a backup of the DB.
It would then start a low priority thread which would iterate across
all objects in the DB, copying them to a new DB file.  During this
time the normal server would continue running as per normal with no
noticable impact on the game (per se).  In the case of an object being
modified by the game which had already been written to the backup DB,
the DB functions would automatically update the version in the back as 
well as the one in primary store.  

> Naturally the only downside to this is that you essentially need
> double the RAM, but I see this as a pretty small concession,
> considering the price of memory these days.


RAM is cheap when counted in Meg's.  It remains expensive when counted
in Gig's.  That said, I eagerly await the (improbable) day when my
machine has more RAM that it has disk (improbable due to swap/core

J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

More information about the MUD-Dev mailing list