Jonathan Clarke wrote:

hyc@symas.com wrote:

...

Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such.

For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...).

Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results.

If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. There are valid reasons to point a syncrepl consumer at the same slapd (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a subtree of a main database, etc.). Using the exhaustive matching that serverID uses would preclude those cases from working.

As usual, when you're configuring a server, you have to pay attention to what you're doing and what effect you want to accomplish.