Thank you for the explanations ! Make sense now.
Have a great day,
On 6/29/24 10:59 AM, Ondřej Kuzník wrote:
On Fri, Jun 28, 2024 at 09:42:56AM +0000, Pierre Marty wrote:
Hi, When using a filter on a replicated branch, it seems that deletion updates are still propagated... The cluster in use is a 4 nodes master-master with the following settings: olcsyncrepl:
serverA : op=1 DEL dn="MyOwnClass=state,ou=initials,dc=root,dc=com" serverA : op=1 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7ff5a00157c0 serverB : op=0 syncprov_matchops: recording uuid for dn=MyOwnClass=state,ou=initials,dc=root,dc=com on opc=0x7f158c0015c8 serverB : syncrepl_del_nonpresent: rid=003 be_delete MyOwnClass=state,ou=initials,dc=root,dc=com (0) serverB : op=1 SRCH base="MyOwnClass=state,ou=initials,dc=root,dc=com" scope=2 dereIs it an expected behavior?
When updating the value or renaming the object, no replication is noticed.
Hi Pierre, this is during the initial refresh: your entry was changed since your last sync and now it's "not there" (it's not visible due to ACLs), the provider doesn't know if it ever was there, so it tells the consumer the DN+entryUUID is no longer around. This is the bare minimum that needs to be disclosed to achieve a consistent copy on the replica.
During persist, each modification is checked for:
- could they see it before?
- can they see it now?
As both are a "no", nothing is sent. This kind of information is not available during a refresh.
Regards,