Mnesia, more questions

Hakan Mattsson <>
Tue Aug 30 14:26:54 CEST 2005

On Mon, 29 Aug 2005, Ulf Wiger wrote:

UW> > I recently read an article on how to setup a secondary MySQL server
UW> > that gets updated from the primary one.
UW> > 
UW> > How would one do the same in Mnesia?
UW> > (NB: I don't want the secondary server to be part of schema,
UW> > running in distributed mode, etc)
UW> Perhaps one could make use of mnesia table events?
UW> See
UW> Another option would perhaps be to use rdbms, which has commit triggers,
UW> but that would require all accesses to go through rdbms. Table events
UW> will work no matter what.

Another way of replicating updates between Mnesia databases,
is to perform a Mnesia backup on the primary site and load
it into the secondary dito.

Depending on the requirements on your system it may suffice
to perform a backup at regular intervals and at least
transport it to the secondary site. On the secondary site
you could either load the backup directly or wait until the
primary site fails.

In order to minimize the backup size you could use
incremental backups. This would imply that you always would
have a checkpoint active on the primary site. Initially you
perform a full backup using that (preferably distributed)
checkpoint and when you want to perform an incremental
backup you create yet another checkpoint and use the two to
only backup the difference. Then you could deactivate the
oldest checkpoint. The drawback with checkpoints is that
they will imply slower updates and increased memory

You can implement a customized backup callback module that
writes to some remote media instead of writing it to a local

Mirroring Mnesia databases is tricky. If you are using
backups the secondary site would always be transaction
consistent, but a bit outdated now and then. If you would
use Mnesia events or triggers i rdbms, the secondary site
would be more up to date but the transactions would not be
serialized properly.

Yet another solution is to have a front-end which stores all
updates into a persistent queue, and a back-end which reads
operations from the queue and performs updates of the
primary Mnesia database. The persistent queue should also be
processed on the secondary site, but there you would be more
free to choose the timepoint for when the database updates
are performed. Using this method it would be much easier to
recover from a communication or site failure than with the
other two methods.


More information about the erlang-questions mailing list