You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have M1 <--> M2 with full replication and M1 --> C with fractional and no M2 --> C.
Scenario where C is in DMZ and only one supplier updates it.
Let the RUV being
C is very late regarding all the updates generated on '2' because most of them are skipped.
On a replication session M1->C1, anchorcsn will be csn_2_1 and all the updates csn_2_1..csn_2_1000 will be evaluated (including likely all the updates csn_1_1..csn_1_1000).
At the end M1 has nothing to send to C because all is skipped, so it updates its keepAlive_1
So it will start again from csn_2_1. This, indefinitely until an update on M2 will be propagated to C.
The RC of the issue is that the keepAlive update should have be done on M2.
There is a quite similar issue when a supplier is rarely updated. It is less severe as it resolves by itself
Then M2 is updated generating csn_2_2. M2 will update M1 starting with csn_2_1, so it will evaluate csn_1_1 to csn_1_1000 (skipping them as M1 already knows them), finally it will send csn_2_2.
I think both situations could be addressed if we implement a periodic update of the KeepAlive entry. By default periodicity would be infinite (no update). This would require a new replica config attribute.
Package Version and Platform
All
Steps to reproduce
see desciption
Actual results
Backlog of updates being high, it slows down replication.
Expected results
Reduce the backlog of updates to evaluate
The text was updated successfully, but these errors were encountered:
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49549
Issue Description
Here are two scenario:
We have M1 <--> M2 with full replication and M1 --> C with fractional and no M2 --> C.
Scenario where C is in DMZ and only one supplier updates it.
Let the RUV being
C is very late regarding all the updates generated on '2' because most of them are skipped.
On a replication session M1->C1, anchorcsn will be csn_2_1 and all the updates csn_2_1..csn_2_1000 will be evaluated (including likely all the updates csn_1_1..csn_1_1000).
At the end M1 has nothing to send to C because all is skipped, so it updates its keepAlive_1
The next session will start with
So it will start again from csn_2_1. This, indefinitely until an update on M2 will be propagated to C.
The RC of the issue is that the keepAlive update should have be done on M2.
There is a quite similar issue when a supplier is rarely updated. It is less severe as it resolves by itself
Initial is
Then M2 is updated generating csn_2_2. M2 will update M1 starting with csn_2_1, so it will evaluate csn_1_1 to csn_1_1000 (skipping them as M1 already knows them), finally it will send csn_2_2.
I think both situations could be addressed if we implement a periodic update of the KeepAlive entry. By default periodicity would be infinite (no update). This would require a new replica config attribute.
Package Version and Platform
All
Steps to reproduce
see desciption
Actual results
Backlog of updates being high, it slows down replication.
Expected results
Reduce the backlog of updates to evaluate
The text was updated successfully, but these errors were encountered: