[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- To: Pierangelo Masarati <ando@sys-net.it>
- Subject: Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Mon, 21 Nov 2005 11:13:50 -0800
- Cc: Raphaël Ouazana-Sustowski <raphael.ouazana@linagora.com>, OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <1132594689.6044.6.camel@ando>
- References: <313423751.20051110113255@uaic.net> <51417.10.0.14.46.1131636197.squirrel@mail.ivytech.edu> <42138.192.168.1.254.1132334767.squirrel@tomate.linagora.lan> <48887.10.0.14.46.1132341797.squirrel@mail.ivytech.edu> <465451149.20051118224611@uaic.net> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <1466010362.20051119122217@uaic.net> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <43528.192.168.1.254.1132565037.squirrel@tomate.linagora.lan> <32823.10.0.14.46.1132587321.squirrel@mail.ivytech.edu> <53801.192.168.1.254.1132588966.squirrel@tomate.linagora.lan> <1132590414.3330.4.camel@ando> <33022.10.0.14.46.1132590508.squirrel@mail.ivytech.edu> <54934.192.168.1.254.1132591085.squirrel@tomate.linagora.lan> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando>
In theory, the slave could attach a post-readEntry control to
chaining operation wrapping the the modify request and use
the returned entry to "pre-sync" the value. Of course,
syncrepl would then need to ignore changes to that
entry that have an later CSN.
Note that use with a chaining operation is necessary here
for two reasons:
1) to avoid conflict with any client provided read
entry control, and
2) appropriate authorization (e.g., as slave not
client).
Of course, the devil is in the details.
I also note that if we were ever to support a floating master
system where adds must be done on the server holding
the parent, one could use such chaining combined with
a "get token" control so as to ensure authority for
the added entry was transferred atomically to the entry's
creation.
Kurt
At 09:38 AM 11/21/2005, Pierangelo Masarati wrote:
>[moved to -devel for discussion]
>
>On Mon, 2005-11-21 at 17:57 +0100, Pierangelo Masarati wrote:
>
>> Technically, this could be solved by extending the functionality of the
>> "chain" overlay so that, when configured to chain writes to the producer
>> when a referral to it is returned by the consumer, it directly writes to
>> the consumer after the producer returned success; at the same time (in
>> case of slurpd) the producer should not send the change to the consumer.
>> However, this is dangerous because there might be other intermediate
>> changes to that very same data that didn't make it to the consumer yet.
>> Those changes would then apply in an incorrect order.
>>
>> Maybe we could use something like this:
>> - the chain overlay attaches a control to the chained write that
>> contains the entryUUID and the entryCSN
>> - the producer processes the write; upon success, if the entryUUID and
>> the entryCSN were the same, it returns a control response value that
>> indicates the consumer can directly apply the write.
>
>Elaborating a bit more:
>
>- of course no response would be returned to the client until either the
>local change could be performed and it completed, or the local change
>could not; in that case, the consumer would be misaligned until
>replication takes place regularly.
>
>- add: the control would be empty; in case the modification can be
>directly performed, the control response would contain the newly
>generated entryUUID, entryCSN and createTimestamp; otherwise it would be
>empty;
>
>- modify/modrdn: the control would contain the entryUUID and the
>entryCSN; in case the modification can be directly performed, the
>control response would contain the newly generated entryCSN and
>modifyTimestamp; otherwise it would be empty;
>
>- delete: the control would contain the entryUUID and the entryCSN; in
>case the modification can be directly performed, the control response
>would contain the newly generated entryCSN; otherwise it would be empty;
>
>one issue to consider is the potential conflict with syncrepl:
>- the refreshAndPersist mode could be dealt with within the producer,
>which should not propagate the change to the consumer the chained
>request came from;
>- the refreshOnly mode could be dealt with at the consumer side.
>
>Or, this whole stuff could be annealed into syncrepl.
>
>p.
>
>
>
>
>Ing. Pierangelo Masarati
>Responsabile Open Solution
>
>SysNet s.n.c.
>Via Dossi, 8 - 27100 Pavia - ITALIA
>http://www.sys-net.it
>------------------------------------------
>Office: +39.02.23998309
>Mobile: +39.333.4963172
>Email: pierangelo.masarati@sys-net.it
>------------------------------------------