Good morning,
I confirmed the old RUVs are now removed from the HUB.
The replication-changelog.db file on the SUPPLIER is now down to a manageable size of 474M. The HUB however is still at 18G in size. I am focusing on one site, There are 8 others that are a part of this topology,
All of the HUBS are in the same state. Will these file eventually reduce in size? Can we expedite it?
Well with BDB you need to wait for database compaction to actually reduce the size of the file. By default it runs every 30 days, but you can adjust this schedule or trigger it via a task:
https://www.port389.org/docs/389ds/design/compact-schedule-design.html
# dsconf slapd-hub backend compact-db --only-changelog
It's possible you might run in a db lock issue so check the error log. IF you do run into then you can bump the db locks, restart the server, and try again:
# dsconf slapd-hub backend config set --locks 1000000 ; dsctl slapd-hub restart ; dsconf slapd-hub backend compact-db --only-changelog
If replication checks come back all green, can we just spike the file and let it recreate on restart?
If you remove the file then that replica (hub) needs to be reinitialized, but its agreements should be ok. So you would only need to reinit that single hub.
Mark
The SUPPLIERS are mixed. Some are still stuck at the larger size changelog and others like above are at ~474M.
Paul M. Whitney E-mail: paul.whitney@mac.com Sent from my browser.
On Oct 6, 2026, at 1:08 PM, Mark Reynolds <mareynol@redhat.com> wrote:
On 10/6/26 12:32 PM, Paul Whitney wrote:Hi Mark,
I ended up running it on the Supplier using the replica-ids on the hub, that got the list cleaned up. I did run it before I saw this email and did use the --force-cleaning option. Hopefully that doesnt break anything since IDs were not on the supplier, just the hub.Ok glad it got things cleaned up. Using the force option really means that if it hits a problem it just skips over that replica. Meaning it might NOT clean the rid and proceed to the others. So by "not" using the force option the task will not complete until all replicas are fully cleaned - just an FYI. So lets see how changelog trimming is affected...
On Oct 6, 2026, at 12:09 PM, Mark Reynolds <mareynol@redhat.com> wrote:
Run it again on a supplier and do not use the force option
On 10/6/26 10:31 AM, Paul Whitney wrote:Hi Mark,
So I ran the command this morning on the HUB. The error i am getting is:
Failed to clean rid (55224) task cannot be run on a consumer.Cannot modify task entry, no such object.
Basically, if the supplier isnt providing the change, it wont clear on the hub. Or at least that is how i am understanding it.
Paul M. Whitney E-mail: paul.whitney@mac.com Cell: 410.493.9448 Sent from my browser.
On Oct 5, 2026, at 3:02 PM, Mark Reynolds <mareynol@redhat.com> wrote:
Hi Paul,
Did you run the cleanallruv task on the groupRoot suffix? You need to run it individually on all the replicated suffixes(and sub-suffixes).
Otherwise, the cleanallruv task should have cleaned the hub, but perhaps the force option allowed it to be skipped for some reason. Instead try the command without the force option:
# dsconf slapd-hub repl-tasks cleanallruv --suffix dc=group,dc=root --replica-id <the ID>
Also check the error log on the hub and see if it complained about anything related to the cleanallruv task (grep -i cleanallruv /var/log/dirsrv/slapd_INSTANCE/errors)
Thanks,
Mark
On 10/5/26 2:48 PM, Paul Whitney wrote:Hi Mark,
This definitely helped. Discovered that there were obsolete RUVs in both my userRoot and groupRoot databases.
I cleaned up the suppliers and they now look clean. However, I am still seeing the old RUVs in the groupRoot database on the hub. Is there a way to clean those out without having to do a reinit?
Paul M. Whitney E-mail: paul.whitney@mac.com Sent from my browser.
On Oct 1, 2026, at 4:02 PM, Mark Reynolds <mareynol@redhat.com> wrote:
Hi Paul,
Another reason the the change log might not be trimmed is if there is a replication agreement that has not sent some of those changes yet. I think it can also happen if there is an obsolete replica in the RUV.
Check the ruv with this command (adjust the suffix of course):
# dsconf slapd-localhost replication get-ruv --suffix dc=example,dc=com
If you see a replica RUV element that is out of place you can remove it using the cleanallruv task
# dsconf slapd-localhost repl-tasks cleanallruv --suffix dc=example,dc=com --replica-id <the ID> --force-cleaning
You can also enable replication error logging and check for trimming events. Trimming is probably still happening, but perhaps it's not a lot of entries:
# dsconf slapd-localhost logging error set level replication
And when you're done you can do:
# dsconf slapd-localhost logging error set level default
HTH,
Mark
On 10/1/26 2:50 PM, Paul Whitney via 389-users wrote:Good afternoon,
We are running 389-DS version 2.8.0-10. We have a multi-supplier replication agreement in place and each supplier to hub and then to consumers. We have a changelog retention policy of 7 days (the default). Lately we are noticing very large replication-changelog.db files to the tune of about 17-22 GB. The 7-day retention policy doesnt seem to be truncating the size of these files as relication chages are aged off. I have tried setting the max size of the db to 10 GB, but that did not make a difference and then changed the trim-interval setting to every 5 minutes. Still no change in the db file size. Is there a better way to manage this cleanly?
Thank you,
Paul M. Whitney E-mail: paul.whitney@mac.com Sent from my browser.
-- Identity Management Development Team
-- Identity Management Development Team
-- Identity Management Development Team
-- Identity Management Development Team
-- Identity Management Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
