Re: commit: ldap/tests/scripts test050-syncrepl-multimaster

[Howard Chu <hyc@symas.com>]

Howard Chu wrote:
> With the recent hubbub on the -software list about it I decided to keep 
> quiet for a bit. Talking about it before it's done smacks of vaporware; 
> it needs to be tested more before we start talking about it more broadly.

And on that note... Here are some scenarios that need to be tested:

single DB with multiple consumers: this isn't what most people think of re: 
multimaster. The server is a pure slave, all of its data comes from other 
providers. Since it is not multimaster, local writes are disallowed, same as 
the old single DB / single consumer scenario.

pair of peer servers: this is 2-way multimaster, like mirrormode. Each server 
has a provider, and a consumer pointed at the other. Local writes are 
allowed. This is what test050 sets up, but the script doesn't actually test 
anything after the DBs are populated. I've been poking and prodding it 
manually. Will probably want to use slapd-tester here.

N-way multimaster: this could take two basic approaches - sparse connection, 
or full connections. Currently the code does not support the sparse approach. 
(We need to add support for multiple URLs in a single consumer.)

For the fully connected approach, each server has a separate consumer pointed 
at each other server. The provider would only propagate locally-generated 
changes; changes received via a consumer would just stop there because it's 
assumed that all of the servers are receiving the changes at the same time.

At the moment it doesn't work that way - any change is always propagated, so 
in Persist mode there's some excess traffic.

For the sparse approach, each server would have a single consumer configured 
with multiple URLs. This means there would only be one active consumer 
session at a time, and it would only switch away from the active URL if that 
server went down. The most obvious implementation would be to treat the list 
of URLs as a ring. Each server would find its own listenerURL in the list, 
and connect to the next server in the list first. (Again, I'm assuming that 
all of the servers are replicating their configs as well as their main data, 
thus a single consumer config would list the URLs of all of the participating 
servers.) Any change that arrived anywhere would have to be propagated 
onward. The advantage here is fewer open connections; a disadvantage is the 
long propagation delay for updates traversing the ring.

Of course you could do some combination of the two approaches - configure 
more than one consumer, but fewer than the total number of servers. In each 
consumer you would configure URLs for a subset of all the servers.

...
For any of the multimaster configurations, we should also set up a couple of 
regular consumers to verify that cascading still works.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  Chief Architect, OpenLDAP     http://www.openldap.org/project/