[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re:Re: High availability (was Re: Question about the configbranch)
Hi Kurt,
Your Questions;
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?
My answer:
As I described before, the master don't know how many slave would get
copy from this DS. And the slave only know where is the master, don't know
another slaves which get copy from the master. The master and the slaves
are consider as a cluster.
So if we add all of the information into the config branch to let the
master and slaves see each other, your question is easy to solve.
a) If the slave is currently unavailable, the master knows it,because
there is no connection from this slave. And in the master set this slave
status to asynchronous. When the slave is available, the master knows it,
and push the updates to this slave to make it synchronous.
b) Set the slave status to asynchronous. And do the same wiht (a).
c) Set at least 1(or more) slave should response success. If the slave
response error, set the slave status to asynchronous. And do the same wiht
(a).
What about your ideas?
Question:
(d)Why should the client wait for the slave when waiting won't
necessarily ensure the slave is in sync?
It is to ensure all of the DS in the cluster keeping synchronous. If
the master fail, one of the slaves could take over the master.
Yes, using chaining to forword the request.
The (3) (4) I discribed before are implemented in OpenLdap. But the
current implementation will cause asynchronous between master and slavers.
And it could not used to implement the HA.
What about your idea?
Best Regards,
Sparklezou
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