[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: n-way replication question

Dieter Kluenter wrote:

Pierangelo Masarati <ando@sys-net.it> writes:

Dieter Kluenter wrote:
"Dieter Kluenter" <dieter@dkluenter.de> writes:
Mavric Domen <d.mavric@iskratel.si> writes:


I'm facing a similar issue, but I've noticed that this only happens if
one of the master "consumer" servers is restarted. Up to that time it
seems the synchronization works perfectly. I had no chance to
investigate this in details, but it might help to discover a reason
for the problem.
initial contextCSN on localhost
contextCSN: 20081022151212.263032Z#000000#000#000000
initial contextCSN on remote peer
contextCSN: 20081022151212.263032Z#000000#000#000000
after a modification on localhost
entryCSN: 20081022151026.029523Z#000000#000#000000
on remote peer
contextCSN: 20081022151212.263032Z#000000#000#000000
I just wonder wether this is a new bug or is it silly me.
AFAIK, the SID in each contextCSN should be anything but "000" (it
should be the serverID of the server that received the write and
propagated the modification).

OK, than I presume that is a bug, unless I get other comments I will file an ITS.

What is your configuration on all servers? In detail, what's the value of the serverID statements, of the syncrepl statements and what's the URI you're running them with?


Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it