[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: High availability (was Re: Question about the config branch)
sparklezou wrote:
> In fact, Iwould like to implement HA using replicate.
>Today I found that there is an session discussed before about this topic.http://www.openldap.org/lists/openldap-devel/200310/msg00068.html And the idea descriped is something the same with mine.
> I want to implement as following:
>
>(1)
> Client Master Slave
> |------ modify(0) --> | |
> | | --- modify(1) ---> |
> | | |
> | | <--- SUCCESS ----- |
> | | |
> | <---- SUCCESS ----- | |
What do you propose the master do when
a) the slave is currently unavailable?
b) the slave doesn't respond in a reasonable amount of time?
c) the slave responds with an error?
Why should the client wait for the slave when
waiting won't necessarily ensure the slave is in
in sync?
And I note that simply forwarding modify request to the
slave will result in out-sync servers as CSNs, timestamps,
etc. will differ. To properly accomplish this approach,
you'd need a special forwarding operation (much like
we need a chaining operation when forwarding requests
from slaves to other servers).
>(2)
> Client Slave Master
> |------ modify(0) --> | (Chaining the modify request to Master) |
> | | --- modify(0) -------------------------------> |
> | | |
> | | |
> | |Master update the data,and try to update Slave |
> | | <--- modify (1)---------------------------- - |
> | | |
> | |------------SUCCESS(1)-----------------------> |
> | | |
> | |<------------SUCCESS(0)----------------------- |
> | | |
> | <---- SUCCESS(0)----- |
Not sure this approach has any value over the slave asking for
a copy of the entry post master-update (using a post-read
control attached to the chaining request) and sync'ing to this.
> |
>But current implemented in OpenLdap2.3 is:
>
>(3)
> Client Master Slave
> |------ modify(0) --> | |
> |<---- SUCCESS(0) ----- | |
> | | |
> |-Query the entry again->| |
> | | --- modify(1) ---> |
> | | |
> | | <--- SUCCESS(1)---- |
> | | |
This adheres to LDAP's "eventually consistent" distributed
data model.
>(4)
> Client Slave Master
> |------ modify(0) --> | (Chaining the modify request to Master) |
> | | --- modify(0) -------------------------------> |
> | | |
> | | |
> | |<------------SUCCESS(0)----------------------- |
> | | |
> | <---- SUCCESS(0)----- | | | | |
> |------------Query the entry on Master again----------------------------->|
> | | |
> | | |
> | | |
> | | <----------- modify(1) ------------------------|
> | | |
> | |---------------SUCCESS(1)---------------------->|
Not sure this is implemented, but I certainly suggested that
if prior to a search request the slave chained an update
request, the slave should also chain the update request.
This is because its reasonable (given LDAP's referral
model) for a client doing an update to assume the lack of
referral means its talking to the master.
> It's a NOT good solution to implement the HA, because the data is not keep sync always.
>
> I would like to join replicate develop team to do it.
>
> And I want to implement failover dynamicly. If the master is down, one of the slaves will be the master.
>
> So I want to add some more entrys in the configure branch to let the DS know how many DSs are in the same cluster. Master and Slaves know each other. And currently in OpneLdap, the Master don't know how many Slaves; the Slave only know where is Master, but don't know another Slavers.
>
> So I would like to join OpenLdap to implement these functions.
>
>Best regards,
>======= At 2005-12-16, 18:12:21 you wrote: =======
>
>
>>sparklezou@hotmail.com wrote:
>>
>>>Dear all,
>>>
>>> I read the source code of config branch. I'm puzzled that why the schema for config branch are defined in the source code, not in a .schema file? It a little dificult to extend the config schema. ^_^
>>>
>>Most elements of the config schema map directly to data structures in the slapd code. It would be pointless to alter the config schema without making corresponding code changes. It would be inappropriate to store the config schema in a regular file; that would imply that it can be changed freely which is incorrect.
>>
>>So, since you are asking about extending the config schema, that must mean you have written code to provide a new feature. It would be helpful for the purpose of this discussion if you describe what your new feature is, so we can focus on the proper hooks for integrating it.
>>
>>--
>> -- Howard Chu
>> Chief Architect, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc
>> OpenLDAP Core Team http://www.openldap.org/project/
>>
>>.
>>
>
>= = = = = = = = = = = = = = = = = = = =
>
>sparklezou
>sparklezou@hotmail.com
>2005-12-21
>
>
>
>