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

Re: syncrepl

Still talking to myself...

Howard Chu wrote:
So continuing the discussion of what to do with syncrepl and multiple contexts...

1) the provider must be told about all of the sources of changes living within its context. possible sources are
a) local changes
b) changes received via syncrepl
2) every source of changes must have a unique sid.
a) if it's a syncprov, then it's configured explicitly there
b) if it's a syncrepl consumer pulling from elsewhere, it uses the remote server's sid.

The olcServerID config attribute has been added for configuring these IDs. It is a global config keyword, not associated with a particular provider. A single serverID can be configured, for simple static setups. Or you can configure a list of serverIDs and corresponding URLs, to allow a single configuration to be replicated across a pool of servers.

When a consumer is configured for multimaster (mirrormode; looks like we'll have to make "multimaster" a synonym) the serverID will also be sent explicitly in the sync cookie. By default (single master) it is not sent on its own. When the serverID is sent, the provider will use it to additionally filter updates. I.e., changes with an entryCSN whose SID matches the consumer's SID are assumed to have originated at the consumer and won't be sent back again. This avoids one wasted network transaction. (The consumer would just ignore the update anyway.)

3) the provider must aggregate all of the cookies for each of these change sources and send them to consumers pulling from it.

The consumer now checks to see if it's a subordinate DB; if so it will perform its contextCSN updates through the parent DB. If a syncprov overlay is present it will get a chance to see the contextCSN update.

This behavior can be checked using test033, by enabling glue and syncprov on the superior DB and leaving syncprov commented out on the other DBs.

There's a desire to be able to configure multiple change sources for the same context though. E.g., mirrormode is defined to only work with two servers mirroring each other, it would be nice to be able to extend this to additional failover servers.

I had in mind to extend the slap_bindconf structure to accomodate a list of URLs. If the first connection failed, each would be immediately tried in turn, before returning a failure to the caller. But for the moment I'm leaving that alone.

I've modified the consumer to allow multiple syncrepl configurations on the same backend. Corresponding changes are still needed in the provider. The contextCSN attribute is now multi-valued, allowing a CSN per SID to be tracked. Modifies to the contextCSN must be done with specific Delete/Add instead of Replace.

Both the consumer and provider have been updated accordingly.

There's no restriction on how this gets used - a consumer can talk to multiple providers that master disjoint subtrees of the context, or they can overlap partially or fully. As long as each provider has a unique SID their multiple contextCSNs will be tracked properly.

We still need more tests for the various scenarios...

From half-multi-master we can go all the way to multi- if we add collision detection and conflict resolution. There's a pretty simple way to handle collision detection - we just need to pass the entry's old entryCSN along with the rest of the modification info. On the consumer we check and see if the oldEntryCSN matches the consumer entry's current entryCSN. If they match, there is no collision. If they don't match, we need to resolve the conflict.

Aside from allowing us to log that a conflict occurred, keeping the oldCSN around doesn't seem to buy us much. Since the conflict resolution is still determined solely by the current entryCSN, I'm dropping this idea. All we need to check is if the incoming mod's entryCSN is <= the current entryCSN and drop the change if so.

The oldCSN would still be needed to support multimaster with delta-syncrepl. That would also allow us to do change-level conflict resolution with delta-syncrepl instead of just entry-level as the current code does. But at this point I'm not interested in adding that support.

It shouldn't be a major problem, we still use the op counter if the resolution is too low and multiple updates occur in the same timeslice.

The op counter is also important because it's possible for the system clock to run backwards in certain situations...

Not all of these changes are checked in yet, but they'll be coming in soon.

The code is in place; we just need some more test configurations...

So - no one can say OpenLDAP doesn't have multimaster replication any more.
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/