[DGD] Incremental statedumps

[Felix A. Croes]

For many years, one of the items on my TODO list has been the optional
replacement of swapfile/dumpfile handling by a standard database.

While there isn't much point in saving objects in a relational database,
since objects at the lowest level are just binary data blobs, one
possible advantage of using a database is that it would be easier to
always keep the saved state consistent, and no more than a few seconds
behind a running mud's state.  A statedump would then be a snapshot
within the database.

I had a look at how feasible this is, given the load I envision DGDMP
handling and current hardware trends, and decided that it is impossible
and getting worse: the pressure on the database would be far too high.
However, this highlighted a weakness in DGD's state saving model:
each statedump is a separate file, and must be recreated from scratch.
A large, but idle mud will still be busy if it has to copy a huge
statedump all the time.  A very large, and very busy mud might even have
to reduce the frequency with which statedumps are created.

Hence incremental statedumps: these extend the last statedump, and save
only what has changed in the meanwhile, rather than the full state of
the mud.  Incremental statedumps are for DGDMP, only.

As implemented, increments only append to existing statedumps, and don't
modify already saved state; you can safely restore from a statedump
which is still being incrementally updated by a different running mud.

Restoring from an incremental statedump always restores the most recent
saved state, so it is wise not to use incremental statedumps exclusively,
but to create ordinary full statedumps every once in a while.  Also, a
number of essential housekeeping tasks are only performed when a full
statedump is created, or when the mud is rebooted.

A mud could have a full statedump every day, and an incremental statedump
every hour.  In this case, the swapfile recreation period, dump_interval,
should be set to a day or less.  Let's take a look at what happens to a
mud with a statedump every 10 hours, a swapfile recreation period of
4 hours, and an incremental statedump period of 1 hour:

    00:00	reboot
    01:00	swapfile 25% recreated, moved to incremental statedump
    02:00	dumpfile 50% recreated, increment appended
    03:00	dumpfile 75% recreated, increment appended
    04:00	dumpfile fully recreated, increment appended
    05:00	increment appended
    06:00	increment appended
    07:00	increment appended
    08:00	increment appended
    09:00	increment appended
    10:00	full statedump: last increment appended, new swapfile
		created

Note that when the swapfile/dumpfile is not yet fully recreated, any
incremental statedump will result in a partial dumpfile.  These can
be used to restore from, but only along with the previous statedump
file, which contains the missing objects.  The secondary dumpfile
must be supplied as an additional command line argument.  To simplify
reboot scripts, a secondary dumpfile may also be specified when the
primary dumpfile is not a partial one.

Regards,
Felix Croes