HRZ Konten hrzkonten@uni-bonn.de writes:

...

...

Is there an easy way to force a new replication on the second node?

...

I will really appreciate your help...

Just delete the database on the second node and setup a new node.

Well, that is rather a worst case scenario, but if this is the only was to get them synced...

This situation is a little bit strange, then it says if the contextCSN is equal then the systems are synced. In my case I had equal contextCSN and diefferent number of entries and no error message in the logs. How could I be sure that my both nodes are synced? Is there any other way to check that? Then if I don't know that they are out of synchow could I start the rebuild of the second node...

To check the database content just slapcat both directories and do a diff. My multimaster tests of early 2.4 versions(2.4.11 + 2.4.12) had similar effects. While a node was down, heavy modifications, that is modify, delete and add operations, where made. But only the added objects where synchronised but not the modified and deleted objects. In order to get the systems synchronised I had to take the node down, delete the database files and restart the system. This experience, design analysis and requirement analysis led to the claim not to use n-way synchronisation. In most cases it is only bad directory design that leads to a request for multimaster systems. One-way synchronisation in combination with chaining is has the same effects as multimaster but is much more reliable.

-Dieter