On Tue, Jul 22, 2008 at 1:40 PM, Buchan Milne <[EMAIL PROTECTED]>
wrote:

> Please stay on-list.
>
> On Tuesday 22 July 2008 10:41:18 Liutauras Adomaitis wrote:
> > On Tue, Jul 22, 2008 at 10:02 AM, Buchan Milne <
> [EMAIL PROTECTED]>
> >
> > wrote:
> > > On Monday 21 July 2008 14:48:23 Liutauras Adomaitis wrote:
> > > > On Mon, Jul 21, 2008 at 12:49 PM, Buchan Milne <
> > >
> > > [EMAIL PROTECTED]>
> > >
> > > > wrote:
> > > > > On Sunday 20 July 2008 23:34:03 Liutauras Adomaitis wrote:
> > >
> > > [...]
> > >
> > > > > > It shows, that it is adding MirrorMode TRUE. So why?
> > > > >
> > > > > The configuration directive may have been overloaded when
> > > > > multi-master was added (after mirrormode). AFAIK it allows the
> > > > > database in question
> > >
> > > to
> > >
> > > > > both have a syncrepl directive, yet take updates from a DN besides
> > > > > the updatedn (see the description on the slapd.conf man page).
> > > >
> > > > are you saying, that in multimaster configuration I have to have
> > > > updatedn directive to be able to do writes?
> > >
> > > No. Without mirrormode or multi-master, a slave would only accept
> updates
> > > from
> > > the updatedn. In multi-master, the master is also a slave, so it needs
> to
> > > accept updates from any DN, while being configured as a slave (having
> > > replication configuration).
> >
> > Sorry, but still don't get it. As you say node in multimaster
> configuration
> > is master and slave at the same time. As a slave it can accept writes
> only
> > having updatedn directive. Right?
> > I'm really sorry if I don't understand, but it seems that "No"
> contradicts
> > other sentences.
>
> No means: your interpretation that it is multimaster requires updatedn to
> be
> set is incorrect.
>
> > > > In thread "explain diff between multimaster and mirror mode" I found
> > > > out, that mirrormode is kind of high availability implementation for
> > > > openldap. In my case I want to have multimaster replication, which
> > > > could allow me
> > >
> > > to
> > >
> > > > do writes to different master servers at a time.
> > >
> > > You may want to think very carefully about why you want this, and not
> > > mirrormode, or a single master.
> >
> > Yes maybe it is not necessary. I have read some posts saying the same -
> > people do multimaster then they really don't need it at all. This is my
> > first acquaintance with syncrepl and ldap replication, so I don't really
> > know what is best for me. I tried master- slave, but it had some
> undisired
> > side effects,
>
> If you are that unspecific about the issues, we can't comment on your
> decision.
>

I was thinking to make a new thread, because it is a little bit different
question.


> The most probably it is my configuration and I'm missing something.
> The error is "shadow context; no update referral at ...", I have posted in
> my first letter. I receive this error on any master I try to do writes. If
> add mirrormode true to the end - I can do writes.

Exactly. Enabling "mirrormode" is a prerequisite for multimaster.
>
> The difference between mirrormode an multimaster (as far as I know) these
> days
> (post 2.4.6) is really your architecture (whether you allow writes to one
> master, or more), not the configuration (though more than two syncrepl
> statements does mean that it can't be mirrormode).
>
> > I have one central master, and other master are replicated from this one.
>
> This is not the definition of multimaster. As far as I know, the
> recommended
> architecture for multimaster is that all masters can see (replicate from)
> each
> other. Otherwise, they are locally writable slaves, with no guarantee of
> convergence.
>

Ok I see now. MultiMaster and MirrofMode configurations are the same, the
difference is just how I use them.
Having mirrormode true directive in configuration file just enables write
operation. The "load balancer" in MirrorMode for redirecting writes  if
first master fails is question for third party software.

If that is correct - then thanks a lot for explaining me that.
Liutauras

Reply via email to