tx-logging vs. redundancy for databases

Bryce Kampjes bryce at kampjes.demon.co.uk
Thu May 13 20:40:19 UTC 2004


Chris Muller writes:
 > I'm finally starting to think about building some fault tolerance into the
 > Magma server.  My understanding of the traditional approach is to perform
 > "transaction logging" to a log file that can, in the event of a power failure
 > in mid-commit, be used as input to a "recovery utility" to allow proper
 > restoration of that transaction and overwrite any potential corruption in the
 > main db file.

A good book on database implementation is:
Database System Implementation
Hector Garci-Monina, Jeffrey D. Ullman, Jennifer Widom
Prentice Hall
ISBN 0-13-040264-8

It includes solid descriptions of both undo and redo logging.

With redo logging (Oracle, and I think SQL-Server) you just need to
write to the log file. Most writes do not need to be serialised, only
the commits. The main database files must be written after the commit
but can be delayed.

Even the commit can be buffered so long as it is written before the
database file is updated. This could lead to commits being lost but
they would be either completely lost or completely there.

Hmm, that book is a good description of databases if you're just using
them. There is enough to implement from, which means enough to
understand why and how the database you're using works. It describes
databases as systems programming rather than a subdiscipline of logic.

 > But why slow down every commit with a write to a log file if that *only* buys
 > me a guarantee against corruption of the main db file in the event of a
 > power-failure?  Instead, what if I "log" the commit records directly to another
 > Magma database (on a secondary computer), thus keeping an idential mirror of
 > the main database.  In the event of a failure of the primary computer, clients
 > could just reconnect to the the mirrored database on the secondary computer.

The disk may be faster than the network. hdparm think's that my
commodity cheap IDE drive gets 47.76MB/sec reading which is faster
than my network cards.

Writing to the log will use sequentual disk acesses so peak write
speed should be nearly obtainable.

 > So I get redundancy and "backup" for essentially the same cost.
 > 
 > I'm scratching my head about other questions too, such as what should happen if
 > the secondary computer fails and there's no place to log anymore?
 > 
 > Looking for ideas, thanks..

Good luck with Magma, a decent OODB will/is a major asset to
Squeak. Magma is one of the things I really should make time to play
with.

Bryce



More information about the Squeak-dev mailing list