Ideas wanted for TXN and Concurrent store recovery handling

[Matthias Andree]

"Tom Anderson" <tanderso at oac-design.com> writes:

> I'd think it'd be efficient to run concurrent child processes in a
> moderately large mail server receiving several emails per second.

I wonder if that makes the data base access faster. Anyways, that is the
future.

> Anything over like 10 users I'd imagine.  If emails arrive faster than
> bogofilter can process them sequentially, then they'd just pile up.

Postfix and qmail will inherently limit the amount of local delivery
processes running, I'd presume Exim and Courier will do that was well,
but concurrency is not our big problem except that we cannot run
recovery while any other process is running.

>> Any running bogofilter process would claim a shared lock and then try to
>> upgrade to an exclusive lock once. Only one process can hold the
>> exclusive lock, and that process would then be in charge of running
>> recovery.
>
> I thought your initial problem was when this process having the exclusive
> lock hung for some reason.

I need to explain this a bit. Berkeley DB has internal locks that are
stored in one of the __db.NNN files, and these are the problem. My
current idea is an fcntl() lock that is gone after a reboot.

> How do other programs such as system loggers to it?  They fork multiple
> children, don't they?

syslogd is single-threaded.

> Maybe they haven't solved it either?
> http://sources.redhat.com/ml/libc-alpha/2003-09/msg00059.html

Hmmm... pthreads. I haven't decided whether a daemon process would run
threads (LWP on Solaris) or use fork().

>> The remaining question is how does the process know if regular
>> or catastrophic recovery is needed?  Neither does harm, but the latter
>> can take a whole age or two...
>
> What condition differentiates two and necessitates the latter?

The documentation isn't entirely clear, castastrophic is required "[i]f
the database or log files have been destroyed or corrupted, or normal
recovery fails" (BerkeleyDB.4.1/docs/ref/transapp/recovery.html)

I might just run regular recovery, and ask the user to do catastrophic
recovery manually (db_recover utility or bogoutil) if regular recovery
fails. For catastrophic recovery, the user will have to replace archived
log files from his backup (if he has one) anyways.

So the all too common situation of a power outage in the middle of a
write process, with enabled write cache in the drive, might necessitate
catastrophic recovery. But not a crash while reading the data base.

-- 
Matthias Andree

Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)