[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: syncbackup
- To: Howard Chu <hyc@symas.com>
- Subject: RE: syncbackup
- From: Masato Taruishi <taru@valinux.co.jp>
- Date: Thu, 20 Nov 2003 12:30:28 +0900
- Cc: "'OpenLDAP Development'" <openldap-devel@OpenLDAP.org>
- In-reply-to: <003001c39ce7$e5d1b490$8601a8c0@CELLO>
- References: <003001c39ce7$e5d1b490$8601a8c0@CELLO>
Hi
Have you already implemented this fanout backend?
> > First of all, I would like to say sorry about my English as you know,
> > but I'd like your opinions and/or suggestions about my recent activity
> > to OpenLDAP which we call syncbackup, that is, to provide
> > high-availability of master server ( An experimental
> > implementation is
> > almost done ) keeping the database consistency.
> >
> > In order to achieve this kind of HA, syncbackup propagates LDAP
> > operations for modifications such as ldap_modify, ldap_add,
> > ldap_delete and ldap_rename, to other LDAP servers before commiting
> > the changes locally.
> >
> > Master Backup
> > Client -- modify(0) --> | |
> > | | --- modify(0) ---> |
> > | | |
> > | | <--- SUCCESS ----- |
> > | |
> > | <---- SUCCESS ----- |
> >
> > Only if the master slapd server gets the sucuess results from other
> > backup servers as well as local commits, it returns the success to the
> > client. So, if the master returns success, at least two
> > servers have the
> > changes.
> >
> > If the master server hangs up, another backup server can
> > become another
> > master server because all changes to the original master server have
> > been propagated to the new master server.
> >
> > 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.)