pitpalme+openldap@gmail.com wrote:
Hello,
hyc@symas.com wrote:
Paste the debug log somewhere we can see it then. Might as well use =
debug
level -1 while executing this sequence. And provide the debug output =
from both
servers.
I=92ve got 60MiB of log files (cumulated from both servers) from running = slapd with "-d Any=93.=20 Sadly this erroneous behavior did only happened after a couple of test = runs, so it=92s a lot of "everything works normal" in this files.
The logs are available here:
url:http://pitpalme.is-a-geek.net/ldap/
They're both equal regarding contents, just compressed differently for = faster download if 'xz' as compression tool is available.
The test DN that fails is "cn=3DMax = Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= de".
The log shows that the problem is because the two servers are not synchronized before you begin your test. If you search for "do_syncrep" in the ldap1 log, you'll see that it was unable to connect to its provider at the very beginning of the file. It doesn't successfully connect until much later, 97% of the way down in the log file, after the majority of your testing has already been running. That delay is based on your syncrepl retry setting.
When it finally connects it sends a somewhat out of date cookie to the peer server, and so it starts receiving results back. You get the "already exists" error because the entry you're trying to add has just been added by syncrepl itself.
Part of the problem is the out-of-date cookie; the consumer checks with syncprov to make sure it has an up-to-date cookie but obviously in your case the cookie continues to change since you're still making changes to the DB. You can avoid this issue by making sure both servers' consumers are connected before performing any write ops, and you can assist in that by using a faster initial retry time in your syncrepl config.
-
hyc＠symas.com