It isn't bogus at all. :-)
Oh good. I'm replying to your points out of order here:
> So what I would suggest is that you separate concerns (1)
> and (2) above. Use tightly-space-bound, auto-managed BDB
> logs to enable ACID behavior from BDB -- but users can be
> oblivious to that.
Uh oh. Here it comes :-)
Yes, this would be a neat facility. I'm not sure how to mesh
this behavior in with BDB's logging facility. e.g. can we get
BDB to retain disk-level integrity, but avoid logs, and store
the app-level logs ourselves?
As I recall, yes (by virtue of the logging abstraction in BDB), but
that's not really what I'm suggesting you do:
I think you've slightly misunderstood the idea.
I'm suggesting redundant logging.
First, above the DB layer, journal the write transactions. This code
should work generically for BDB, RDBMSs, and everything else.
The "meshing" here is that you have to sync the journal before closing
a txn, and later add the outcome of that txn to the journal.
Meanwhile, because this journal exists, you can (at least as a default
option), prune log files early and aggressively, automatically, with
no real loss of robustness or recoverability.
I suspect that we cannot disable BDBs logging.
I am virtually certain you can not -- not if you want ACID. But you
can, if you have that separate (hopefully much more space efficient)
app-level journal, prune the logs automatically and often.
Otherwise, we wouldn't have the "new feature" of doing just
that coming down the pipe. Until that point, I'm not sure that
duplicating [the net result of] BDB's logging with an
app-level log will be helpful.
I don't want to repeat myself too many times -- I believe that what
I've suggested is a way to combine app-level journaling and BDB
logging in a manner that will help eliminate the "oops, logs filled my
disk" problem, without sacrificing robustness in any regard.
As a bonus, it will enable svn-specific recovery tools that are not
specific to any one DB implementation.
> (1) BDB's built-in recovery facilities for interrupted
> transactions --- just enabling ACID properties
Yup. This is satisfied if you copy the data files *first*,
*then* copy the log files. The backed-up copy will retain its
integrity.
(it may need to be db_recover'd, but I'm not sure; regardless, it is
guaranteed to be recoverable to *some* state)
Ok. We're on the same page -- but we're looking at different parts.
Forget backups for a second. The logs are needed to ensure ACID
properties in the event of an untimely server crash. That's what I
was talking about in (1).
You're talking about the order of snapping backups of the logs and db,
which is related but different.
Here's a heads up: The "I'm not sure" in what you wrote was probably
just an off the cuff remark -- but it raises a red flag for me.
Backing up in the (correct) order you suggest ensures that the logs
reflect a db state equal to or later than the db state itself. It is
therefore _absolutely critical_, when restoring from backups, that you
check for the case of a log which is ahead of the db, and recover
accordingly (the contrast between "I'm not sure" and "absolutely
critical" is why I raise the flag). If you do not recover in that
critical way, then you may wind up with an inaccurate log (which can
mess up subsequent manipulations and backups).
I'd bet dollars to donuts that you (collectively) already know that
and that "I'm not sure" was just off the cuff language -- but it
seemed like the Right Thing to tediously recite the point and enourage
someone to double check any relevent recovery code or instructions you
might have.
But overall -- we're on the same page and my understanding of the
implementation is apparently not foobared -- so on with the show:
> This requirement [to back up logs], because of the nature of
> BDB logs, leads to a situation where the log files can be
> several times larger than the database itself -- yet
> discarding them without backing them up introduces new
> risks.
Yup. The risk here is that something was changed that you
don't want to happen (such as a change to an unversioned
property), or that you want to pretend that the application
did not perform some action (a very difficult form of 'svn
obliterate').
Two points:
(1) there are additional risks, such as the appearence of bugs (gasp!)
in svn. Logs are useful for recovering from those too.
(2) the fundamental problem here is that BDB logs are about low-level
database transactions -- but all the recovery you'd ever want to
do is about higher-level svn txns. Journalling the svn
transactions (even when the journal "wastes space" -- as with
unversioned properties -- is almost certainly going to be (a) more
robust, (b) vastly more space efficient than logging the DB txns.
It's also a mechanism that is independent of the particular DB
technology used by the back end. So the discussion that appeared
here recently about BDB "leaking through" into admin awareness
goes away.
You can't really use this technique to work around application
bugs, however, since replaying the [BDB] logs will simply
replay the buggy database transactions.
On the contrary. First, by journaling client requests nearly
literally, you have a journal of data essentially untouched by the
server side. Thus, that data is protection against server-side bugs.
Second, with either type of log (svn txn journaling or BDB level),
you have the ability to recover at least _up to_ the event that
triggered the bug.
> Some observations: Log cycling sufficient for (1) could be
> fully automated and space consumption be reasonably bounded.
> Users should not need to interact with log files for purpose
> (1) at all. They should not even need to back them up.
The problem is that SVN cannot take it upon itself to define
this policy. We've already heard from users who are
preserving logs on purpose (i.e. they are fully aware of the
use of those logs).
You've also heard from users who get bitten by _not_ understanding
these logs -- or by understanding them yet not making backups that
frequently -- and what I've put before you is a way to resolve the
excessive space consumption problem those users have been complaining
about.
Nothing I've said requires that you _require_ auto-deletion of
BDB-logs -- I've only proposed a mechanism by which you can provide
(perhaps optionally) auto-deletion of BDB-logs to avoid what seems to
be a fairly common kind of problem report.
Discarding data, by default, does not seem like a winning
strategy.
App-level journaling preserves the data, but in a more space-efficient
form.
That said, I *do* think we can adjust the post-commit template
to provide an example for cleaning out the logs after each
commit.
_That_, absent journaling, would be "discarding data".
BDB logs are probably forward-only, but don't quote me on
that.
I really remember otherwise, but it has been many years since I read
about it. It hardly matters. What matters (for space) is the size of
the data needed to replay a txn at the app level vs. replaying it at
the BDB level and it might be interesting to experiment a bit to
compare these rather than relying on my intuition or its opposite that
the app level will be significantly smaller.
Probably you can do it as a thought experiment. Are the BDB logs
page based or key/value based? Are they symmetric of forward only?
How many pages (or k/v pairs) are touched by various svn txn
operations and how does that amount of data compare to the size of the
request that caused it?
> know that long ago, clients sent full-text and more recently
> they send deltas -- I'm not sure how "complete" that change
> is at this time --
Actually, the clients have "always" sent deltas. It's been a
long while, but the server->client delivery of deltas is
newer. (i.e. we were exactly the opposite of CVS!)
Ah. I had that backwards.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 5 07:47:53 2003