On 11/1/21 8:41 PM, Simon Pichugin wrote:
Hi Iain,
what 389 DS version do you have?

You can safely remove the changelog on the test servers where replication is disabled. As it no longer holds a true record of all modifications while replication is disabled.
So a changelog can be effectively deleted by deleting the log file.

If your 389 DS version 1.4.0-1.4.3, you can use the next commands:
First, please, verify whether replication is disabled for all suffixes:

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com <http://supplier.example.com> replication list

Should display "There are no replicated suffixes".

And with this command you can delete the changelog:

    # dsconf -D "cn=Directory Manager" ldap://supplier.example.com <http://supplier.example.com> replication delete-changelog

On 1.4.4+ versions, you shouldn't have nsslapd-changelogdir so it should be okay there.

So please, tell us the 389 DS version, so we can confirm if it's a correct solution.

In addition to this, regardless of what version you are using, the replication changelog is only "enabled" if a suffix is configured for replication.  You can only turn it off by disabling replication and removing all the agreements.  Now... I just want to confirm that you are not seeing issues with the "retro changelog plugin".  This is the "cn=changelog" backend.  That can be disabled regardless of the replication state of the backend.

HTH,

Mark


Sincerely,
Simon

On Mon, Nov 1, 2021 at 3:57 PM Morgan, Iain (ARC-TN)[InuTeq, LLC] <[email protected]> wrote:

    Hi,

    I've got a bit of an unusual situation. I have two test servers
    that were configured as a multi-master replication pair. One of
    the servers needed to be used for some separate testing, which
    required disabling the replication. In the meantime, the second
    server has been heavily used for regression tests.

    Despite the replication agreements having been disabled for months
    now, the changelog on the second server continues to grow. It has
    reached the point where the size has become troublesome, but I am
    having trouble alleviating the situation.

    I initially tried compacting the changelog, but that made no
    difference. I later noticed using dbscan -f" that entries aren't
    being timed out from the changelog. Essentially, it looks like
    entries are being added to the changelog as we do our periodic
    regression tests; but since no replication session started, the
    changelog does not get cleaned up.

    I tried enabling the replication agreement while the first server
    was down, in the hopes that the cleanup would be triggered. But,
    that did not work. Is there a way to force the cleanup?
    Alternatively, since we don't care about the changes, can the
    changelog safely be deleted?

    Note, I'd prefer to not delete the replication agreement itself,
    but I would appreciate a way to either prevent entries from being
    added into the changelog for now or a way to ensure that the
    entries do not accumulate over time.

    Thanks,

-- Iain Morgan


    _______________________________________________
    389-users mailing list -- [email protected]
    To unsubscribe send an email to
    [email protected]
    Fedora Code of Conduct:
    https://docs.fedoraproject.org/en-US/project/code-of-conduct/
    List Guidelines:
    https://fedoraproject.org/wiki/Mailing_list_guidelines
    List Archives:
    
https://lists.fedoraproject.org/archives/list/[email protected]
    Do not reply to spam on the list, report it:
    https://pagure.io/fedora-infrastructure


_______________________________________________
389-users mailing list [email protected]
To unsubscribe send an email [email protected]
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
List 
Archives:https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report 
it:https://pagure.io/fedora-infrastructure

--
Directory Server Development Team
_______________________________________________
389-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to