#47585 Replication Failures related to skipped entries due to cleaned rids
Closed: wontfix Opened by jraquino.

I have a new issue that is affecting most of my systems since the upgrade to 389-ds-base-1.2.11.15-22.el6_4.x86_64.

My systems appear to have stopped replicating new changes with one another and with replication debugging turned up, it appears that they know about the changes they have pending, but they choose not to send any of them.

There don't appear to be any errors and any other signs of issue except for the fact that changes are not propagating.


Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1027496

The problem is that changelog iteration encounters a replica id (rid) in a csn in the changelog that is not in the consumer or supplier ruv. This causes the following code to be hit:
{{{
clcache_skip_change():
/ Skip CSN whose RID is unknown to the local RUV snapshot /
if ( i >= buf->buf_num_cscbs ) {
buf->buf_state = CLC_STATE_NEW_RID;
break;
}
}}}
The buffer buf gets marked as CLC_STATE_NEW_RID, and this update is skipped. Changelog iteration proceeds in clcache_get_next_change(). When the db multiple buffer runs out, it goes to load the next buffer:
{{{
/
* We're done with the current buffer. Now load the next chunk.
/
if ( NULL == key && CLC_STATE_READY == buf->buf_state ) {
rc = clcache_load_buffer ( buf, NULL, DB_NEXT );
if ( 0 == rc && buf->buf_record_ptr ) {
DB_MULTIPLE_KEY_NEXT ( buf->buf_record_ptr, &buf->buf_data,
key, keylen, data, *datalen );
}
}
}}}
However, since the buffer is still in the CLC_STATE_NEW_RID state, it does not load the buffer, and returns from clcache_get_next_change() with rc = DB_NOTFOUND, which ends changelog iteration.

0001-Ticket-47585-Replication-Failures-related-to-skipped.patch
0001-Ticket-47585-Replication-Failures-related-to-skipped.patch

To ssh://git.fedorahosted.org/git/389/ds.git
8bfe5f5..c783d15 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit c783d159a3baa005f0a5f007d886961e2128bdcc
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Nov 6 14:22:31 2013 -0700
ecc210f..7eefa12 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit 7eefa121784774a2c1535404f0b95b78970b43c2
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Nov 6 14:22:31 2013 -0700
9a7cdb8..fc70e4a 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit fc70e4ac6accaa14d140e333829e98897f6ff164
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Nov 6 14:22:31 2013 -0700
3cf9c54..30bb98f 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 30bb98fb693ea1aac9774bdc43b923eacd72570a
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Nov 6 14:22:31 2013 -0700
c2658c1..cf08f12 master -> master
commit cf08f1274404e4796966011a98a6a0acbbfd6070
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Nov 6 14:22:31 2013 -0700

Metadata Update from @rmeggins:
- Issue set to the milestone: 1.2.11.25

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/922

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata