"Allow backup" extended operation

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I'd like to see an "Allow backup" extended operation, that is, an
operation which flushes all changes out to the databases and freezes
them so one can be sure to get a consistent and up-to-date backup.  I've
seen someone say it's "probably" safe to backup the database if no write
operations are in progress, or something like that, but that is a bit
weak.  I may not get to it this year, but I'd like to set the ball
rolling now anyway.  A suggested design follows.

Please comment.  In particular, possible simplifications are welcome:-)


When we send "allow backup ON" to slapd, it completes operations that
are in progress, blocks further operations or at least write operations,
closes the databases unless they were in readonly mode, and returns
success.  Then we can backup the databases.  Note that slapd does not
reject operations now, it just does not process them.  This is supposed
to take short enough time that there is no need to reject operations.
Finally we send "allow backup OFF" so slapd reopens the databases and
starts operation again, beginning with the blocked operations.

Operations that are in progress and take a long time are a problem,
since they'll cause all incoming operations to hang.  So "allow backup
ON" has a parameter with a timelimit to be in effect until "allow backup
OFF" is sent, this timelimit could thus be set to be a lot shorter than
the server's normal timelimit.  If it is longer than the timelimit
already in effect, it is ignored.  Timelimits will probably not affect
incoming operations, since these will not be read.


Details:

The request has the following parameters.
- Mode: true (allow backup) / false (resume normal operation)
- Timelimit (optional): for operations during backup. Default: none.
- DN-set (optional): list of DNs in for databases to back up.
                     Default: of all backends.

The response has no extra data besides the result code and optional
error message.

Upon receiving an "allow backup" request with Mode=true, slapd finds the
databases with the specified DNs, or lets the operation fail with
noSuchObject (even for DNs that would normally get referrals.)

Then it calls database->backup_mode(BACKUP_STARTING) for all affected
databases.  This has no effect on the databases, it just returns one of
Unimplemented, StopOperations, or Readonly.  If any database returned
Unimplemented, the operation is done and returns unwillingToPerform.

Otherwise, for databases that returned StopOperations, slapd completes
operations that are in progress against these databases, and blocks
further operations against them.  For databases that returned Readonly,
it completes write operations in progress and blocks further write
operations (and probably all read operations following them, since it'll
probably stop reading operations from the client after the first write
operation).

Next slapd calls database->backup_mode(BACKUP_PREPARE).  With read/write
back-<bdb/ldbm>, this flushes the cache and closes the databases.  With
readonly databases (which returned Readonly above), it probably does
nothing.  If all calls returned success, the operation returns success.

Otherwise, slapd calls database->backup_mode(BACKUP_DONE) which in
back-<bdb/ldbm>'s case reopens the database (or possibly it just does
nothing, if databases are reopened automatically).  Slapd then resumes
normal operation, and the operation returns failure (other).

If the operation returned success, we can now backup the database(s).
Then we send an "allow backup" request with Mode=false, which calls
database->backup_mode(BACKUP_DONE) and resumes operation as above, and
the operation returns success.

If at any time something goes seriously wrong so slapd can't resume
operation, it... either it just closes the connection, which might
happen in any case if slapd crashes, or maybe the operation returns
unavailable?

One thing which needs to be implemented is that the slapd.conf
'readonly' option must cause databases to be opened in read-only mode,
not in read/write mode as I think it does now.

-- 
Hallvard