Thursday, February 29, 2024

[389-users] Re: Determining max CSN of running server

> On 1 Mar 2024, at 10:47, Marc Sauton <> wrote:
> there was an old RHEL-7.4 and RHEL-7.5 issue and fix in
> replication halt - pending list first CSN not committed, pending list increasing
> but you have a (somehow) more recent version, 389-ds-base- ( and one 389-ds-base- ) , so this should be fixed.
> the issue could have been related to sub operations.
> the logs provided do show a replica with a large and growing pending list, taking several seconds to parse (in double digits).
> and in this particular replication agreement, the consumer's max CSN is higher than the local supplier's one, so the remote replica/consumer is flagged as "ignored"
> then later in time some updates go through as the RUV in the R.A. have been updated by a better knowledgeable replica.
> but this seems to repeat (strange)
> I want to suggest deleting the changelog, and re-init that replica, but maybe Thierry or Pierre or William B. have a better suggestion.
> M.

I'd want to see the layout of the topology and identify which is the errorneous server before we suggest a possible method of re-initialisation.

Remember, a re-init of the server db is resetting it's changelog, so depending on the setup you may be able to reinit just the one failing server and proceed from there. The issue is if it has changes that other nodes don't have.


William Brown

Senior Software Engineer,
Identity and Access Management
SUSE Labs, Australia
389-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives:
Do not reply to spam, report it:

No comments:

Post a Comment