Bug 1898541

Summary:	Changelog cache can upload updates from a wrong starting point (CSN)
Product:	Red Hat Enterprise Linux 8	Reporter:	thierry bordaz <tbordaz>
Component:	389-ds-base	Assignee:	thierry bordaz <tbordaz>
Status:	CLOSED ERRATA	QA Contact:	RHDS QE <ds-qe-bugs>
Severity:	unspecified	Docs Contact:	Petr Hybl <phybl>
Priority:	unspecified
Version:	8.3	CC:	aadhikar, czinda, ldap-maint, lmiksik, mreynolds, msauton, phybl, rcain, sgouvern, tmihinto, toneata
Target Milestone:	rc	Keywords:	TestCannotAutomate, Triaged
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	sync-to-jira
Fixed In Version:	389-ds-1.4-8050020210514191740-d5c171fc	Doc Type:	Bug Fix
Doc Text:	.The replication session update speed is now enhanced Previously, when the changelog contained larger updates, the replication session started from the beginning of the changelog. This slowed the session down. The using of a small buffer to store the update from a changelog during the replication session caused this. With this update, the replication session checks that the buffer is large enough to store the update at the starting point. The replication session starts sending updates immediately.	Story Points:	---
Clone Of:
Clones:	1921861 1972626 (view as bug list)		Environment:
Last Closed:	2021-11-09 18:10:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1921861, 1972626, 1972738

Description thierry bordaz 2020-11-17 13:19:11 UTC

Description of problem:
Changelog cache is the mechanism that uploads a bulk of updates from the changelog.
The updates are consecutive (CSN order) updates from a given starting point.
The problem is that the bulk of updates can start from the beginning of the changelog even if the starting point CSN exists in the changelog.

The consequence is that the changelog cache will iterate through the all changelog to retrieve the next update to send. If the changelog is large it will delay the sent updates and create replication lag

The problem is not systematic.


Version-Release number of selected component (if applicable):


How reproducible:
No reproducer (ATM)

Actual results:
Replication lag on the consumer side, high cpu/IO on supplier side


Expected results:
No replication lag

Comment 4 thierry bordaz 2020-12-10 14:17:11 UTC

Upstream ticket https://github.com/389ds/389-ds-base/issues/4492

Comment 5 thierry bordaz 2020-12-14 10:10:19 UTC

Patch pushed upstream -> POST

Comment 23 Akshay Adhikari 2021-06-02 14:59:46 UTC

Build Tested: 389-ds-base-1.4.3.23-2.module+el8.5.0+11209+cb479c8d.x86_64.rpm

The fix is in the build. Marking as Verified: Tested, SanityOnly.

Comment 25 thierry bordaz 2021-06-17 13:00:42 UTC

*** Bug 1972626 has been marked as a duplicate of this bug. ***

Comment 30 errata-xmlrpc 2021-11-09 18:10:45 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (389-ds-base bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4203