help

[kamakshya nayak]

I have a cascading multi setup 389-ds.
I observed that on my supplier, hub and consumer are doing good in terms of
replication.
They are healthy.
What I observe is supplier and hub is doing good with replication and size
of changelog.db for one of the backend suffix is less.
But, consumer changelog.db disk space utilization is more around 34 Gb and
supplier and hub changelog.db disk space utilization  is 40 mb.
What could be the issue and why it's utilizing that high disk space for
changelog.db ?

And, why a consumer is holding changelog.db file.. where could be the issue.

Thank you.

help with replication changelog size

[Mark Reynolds]

Changed the subject of this email as this message was filtered into my 
junk folder...

On 7/15/24 1:05 PM, kamakshya nayak wrote:
> I have a cascading multi setup 389-ds.
> I observed that on my supplier, hub and consumer are doing good in 
> terms of replication.
> They are healthy.
> What I observe is supplier and hub is doing good with replication and 
> size of changelog.db for one of the backend suffix is less.
> But, consumer changelog.db disk space utilization is more around 34 Gb 
> and supplier and hub changelog.db disk space utilization  is 40 mb.
> What could be the issue and why it's utilizing that high disk space 
> for changelog.db ?

What version of 389-ds-base are you using?

At first glance it would appear you have changelog trimming configured 
on the supplier/hub but not on the consumer.  That could be the issue, 
or it could be changelog compaction.  On the other hand a consumer does 
not need a changelog so you could remove it's configuration.

Also I don't see a "changelog.db" file in my setup, so maybe you are on 
a very old version?

Mark
> And, why a consumer is holding changelog.db file.. where could be the 
> issue.
>
> Thank you.

help with replication changelog size

[Pierre Rogier]

Hi,

Some other possibilities to complete Mark's answer:
 replication misconfiguration on the consumer (replication role configured
as hub or as supplier instead of consumer)
 if it is about the changelog db (i.e the retro changelog databases) and in
this case it is the retro changelog trimming configuration that are
missing.

FYI: there is a known issue about replication_changelog.db is getting
wrongly created on consumer but the db file should not grow but stay nearly
empty

Regards
  Pierre

On Tue, Jul 16, 2024 at 7:32 PM Mark Reynolds  wrote:
> Changed the subject of this email as this message was filtered into my
> junk folder...
>
> On 7/15/24 1:05 PM, kamakshya nayak wrote:
> > I have a cascading multi setup 389-ds.
> > I observed that on my supplier, hub and consumer are doing good in
> > terms of replication.
> > They are healthy.
> > What I observe is supplier and hub is doing good with replication and
> > size of changelog.db for one of the backend suffix is less.
> > But, consumer changelog.db disk space utilization is more around 34 Gb
> > and supplier and hub changelog.db disk space utilization  is 40 mb.
> > What could be the issue and why it's utilizing that high disk space
> > for changelog.db ?
>
> What version of 389-ds-base are you using?
>
> At first glance it would appear you have changelog trimming configured
> on the supplier/hub but not on the consumer.  That could be the issue,
> or it could be changelog compaction.  On the other hand a consumer does
> not need a changelog so you could remove it's configuration.
>
> Also I don't see a "changelog.db" file in my setup, so maybe you are on
> a very old version?
>
> Mark
> > And, why a consumer is holding changelog.db file.. where could be the
> > issue.
> >
> > Thank you.
>
> --
> Identity Management Development Team
>
> --
> _______________________________________________
> 389-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]....
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue