Re: Cleaning up a disabled replica

Mark Reynolds <mareynol@xxxxxxxxxx> · Tue, 2 Nov 2021 15:29:23 -0400



    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
            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
            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] <iain.morgan@xxxxxxxx>
          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 -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx

          To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

          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/389-users@xxxxxxxxxxxxxxxxxxxxxxx

          Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

        
      _______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

    
    -- 
Directory Server Development Team
  
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/389-users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure