[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: To remove or not to remove logfiles? (issue #1615)

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-11-26 20:18:11 CET

On Wed, Nov 26, 2003 at 11:38:53AM -0600, kfogel@collab.net wrote:
> Berkeley DB 4.2 supports automatic logfile removal. In issue #1615,
> you can read all about how to make it happen. This is technically
> easy, a small matter of programming.
>
> The question is, which way should be the default -- keep the logfiles,
> or throw them out? (It will be configurable, of course; this is only
> about choosing a default.)
>

Some data:

Data-point 1: Oracle

Oracle has two modes of operations:

Archive Log Mode:

  This is in most ways very simmilar to the 4.1 behaviour.

No Archive Log Mode:

  This is in most ways very simmilar to new, optional behaviour.
  For Oracle, this is the default.

The scenarios where Archive Log Mode is typically preferred are for
  1.) hot-standby: a "slave" instance of Oracle reads the logs as soon as
    they are written by the "master" instance.
  2.) backup of very large databases: once a database gets Very Large, it
    becomes unwieldy to make full backups of it as frequently as desired.
    Instead, occasional full-backups are made, and the incremental archive
    logs are backed up between full-backups.

The principal drawback to Archive Log Mode is that the administrator
must write some sort of job to remove the archive logs once they
have been mirrored/backed-up. I have seen multi-million-dollar
Oracle installations freeze completely when the partition their
archive logs are being written to fills because this job fails for
some reason. For example, the backup server has some sort of
problem deleting the files. Kaboom.

Even Oracle, which is not known for its ease of administration, chooses
the "more maintainable" mode of operation for its default over the "more
fault-tolerant" one.

Data-point 2: SQL Server

I am less familiar with SQL Server, but it is my impression that it
only supports the "ring buffer" transaction log model.

Data-point 3: Postgres

Postgres "Write Ahead Logs" are periodically auto-truncated. There
is not (last I checked) an option to use them for replication.

Data-point 4: MySQL

A quick google search leads me to the assumption that MySQL functions
nearly the same way that Oracle does. It is not clear to me which
mode is the default, but given MySQL's reputation for low administrative
overhead, I'd guess that it's "auto-delete".

What I'm getting at here is that many applications that use write-ahead
logging either

  1.) don't support keeping the already-checkpointed logs around
      or
  2.) support it, but not as the default

--ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 26 20:18:48 2003

This is an archived mail posted to the Subversion Dev mailing list.