The behavior described by Christopher seems like a bug to me. Since
we do commercial versions of Sequoia it's kind of embarrassing when a
customer's backups suddenly become invalid early on in testing.
Fortunately as Nick points out it does not happen very often in
production settings because there is almost always some load on the
system.
I have thought about cleaning up the recovery log storage a bit but
have not gotten around to it. Another thing that should be fixed is
to have better keys. For example, we have had problems with sorting
of checkpoints that would be avoided completely by using synthetic
keys. However, these changes need to be made pretty carefully.
Cheers, Robert
On Dec 5, 2007, at 2:13 AM, Nick Smith wrote:
On Tue, 2007-12-04 at 21:09, Christopher Ekberg wrote:
(Embedded Sequoia.)
I have a periodic process that creates a backup, compares the number
of backups to a maximum, and deletes any more than the maximum. It
then tries to truncate the recovery log to the point of the oldest
backup we have. This way, I can always install a new server by
restoring the backup and I don't need to keep unneeded statements
around.
To truncate the recovery log, I'm calling deleteLogUpToCheckpoint
(checkpointNameOfOldestBackup). That function calls
deleteLogEntriesBeforeCheckpoint, which figures out the log id
associated with the backup, and deletes statements and checkpoints
between -1 and that. The problem is, if no statements have come in
since my last backup, the checkpoints for my other dumps will get
deleted, since they'd have the same log id.
I have near-identical processing but I take care that there has been
some inserts into the recovery log since by the last backup / log
purge. If no statements have been logged there is little point in
doing another backup.
Am I doing something wrong? Calling the wrong function? I don't see
another good alternative. If this is a sequoia bug, you might change
the behavior of deleteLogEntriesAndCheckpointBetween to not delete
checkpoints that are still referenced by the dump table.
What you are probably seeing is that more checkpoints than you are
expecting are disappearing when you truncate the log. This is
because checkpoints that share the same log identifier are considered
to be *aliases* and are all removed when one checkpoint is removed.
For me, this is more of an application level problem. Don't delete
checkpoints that are in use by a dump that you still need.
It might be that the customer wants 'hourly backups' (or whatever
period) of the virtual database, but this is more a case of
convincing the customer that it's not always appropriate.
Thanks,
Chris
Regards,
Nick
p.s. Have you had problems
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
