[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: syncbackup

At 04:10 PM 10/27/2003, Howard Chu wrote:
>> This is a simple example and has many problems.
>It's an interesting idea. I've designed this setup already using an extended
>version of back-ldap as an overlay on another database backend. (I called
>this the "fanout" overlay as it fans out updates to a collection of servers.)

A variant of this is:
        clients -> arbitrators -> fanout proxies -> servers

can offer (with additional complexity) some additional availability

>Of course you must queue the updates to the other servers. And if one backup
>responds for one update, but a different backup handles the next update, then
>you have lost consistency if there are still updates in the queue.

There are, of course, of host of consistencies issues to be addressed.
If the fanouts were to use a two-phase commit to update the servers,
the inconsistencies could be limited to cases where the fanout server
could not commit the prepared transaction it already committed to
another server.

>>  These are the ohter extensions to construct syncbackup:
>>       * startSYNC extended operation
>I don't understand the purpose of this operation. A regular Sync request
>should suffice.

One thing Jong and I have been discussing is the need to implement a
"TURN" extended operation.  Presently, LDAP Sync is consumer initiated.
It would be nice to allow the provider to connect to the consumer,
issue the "TURN", and then have the consumer initiate the Sync.

A good project for anyone with a few extra cycles...

>>       * NOOP extended operation
>>          This is a LDAPv3 extended operation to check whether
>> the server
>>       works or not. If the server gets the operation, it returns just
>>       LDAP_SUCCESS.
>There is already a NOOP control, so I don't see the need for an exop.

Or, if you just want to see if the server is up and responding, issue a
simple search or compare operation.

>>       * contextCSN LDAP control
>>          This is a LDAPv3 LDAP control. When the master propagates the
>>       operation, it puts the appropriate contextCSN value to the
>>       operation. If the backup server gots the contextCSN control,
>>       it uses the value rather than using lutil_csnstr().
>I see that this is a good idea when performing synchronous replication of
>this type.

It would be nice to have a control which allowed a client to
provide NO-USER-MODIFICATION values to the servers.  This would
be particularly useful when inserting entries whose UUIDs, CSNs, etc.
were created externally.