Thank you very much, Mark! I will try this.

On Nov 5, 2019, at 6:42 PM, Mark Reynolds <mreynolds@redhat.com> wrote:


On 11/5/19 6:29 PM, Oleg Cohen wrote:
Greetings,

I am running 389-DS cluster v1.4.0.13 on CentOS 7. I have two nodes at the moment with a replication agreement set on both. 

I have initialized replica on NODE2 from NODE1. A replication agreement started from NODE2 to NODE1 and is now running non-stop for a number of hours. The number of changes sent is large. Is there any way I can figure out what is happening and get to the bottom of it? Not sure this behavior is normal.

I would appreciate any suggestions on how to resolve/remediate this situation.

There are a few options you have with the logs

[1] Access log - You can see the DNs of the entries that are being updated, and the client IP where the update originated

[2] Enable the audit log, and you can see the exact update operations.  The audit log will impact performance, so only leave it enabled for the duration of your test.   https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/configuring_logs

[3] Enable Replication Error Logging - (nsslapd-errorlog-level: 8192) - this will log a lot of information to the servers error log.  The logging is very verbose and hard to parse unless you are familiar with the code/internals.

So I think the best option is [2] enable the audit log.  The server is probably not generating all these updates, some client is, so I don't think replication logging would be very insightful, but you are welcome to try it of course.

HTH,
Mark


Thank you!
Oleg


_______________________________________________
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
-- 

389 Directory Server Development Team