389 1.3 vs 1.4, CentOS 7
by Morgan Jones
Hello!
Is it advisable to run 389 1.3 in production?
If not is there a suggested way to install 1.4 in CentOS 7? On first blush to install 389 from source it’s looking like I’m going to need to install libicu from source, the version that ships is an older version:
> checking for ICU... no
> configure: error: Package requirements (icu-i18n >= 60.2) were not met:
>
> Requested 'icu-i18n >= 60.2' but version of icu-i18n is 50.2
thank you,
-morgan
2 years, 5 months
- 3
- 3
Cleaning up a disabled replica
by Morgan, Iain (ARC-TN)[InuTeq, LLC]
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
2 years, 5 months
- 4
- 3
Re: Cleaning up a disabled replica
by Morgan, Iain (ARC-TN)[InuTeq, LLC]
Hi,
Thanks for the response. We are using the Redhat-provided RPM's of 389-ds 1.3.10.2 on RHEL 7.9.
--
Iain
On 11/1/21, 18:16, "Simon Pichugin" <spichugi(a)redhat.com> 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 <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupplier...> 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 <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsupplier...> 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.
Sincerely,
Simon
On Mon, Nov 1, 2021 at 3:57 PM Morgan, Iain (ARC-TN)[InuTeq, LLC] <iain.morgan(a)nasa.gov> 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
2 years, 5 months
- 2
- 1