[389-users] Re: Replication Problem

FYI: The logs show  that ldapserver2 abruptly closed the connection after a successful bind

 It is a bit hard to say why without the ldapserver2 logs, 

My guess is that the replication manager dn is missing or wrong in ldapserver2 replica config (but the replication manager entry exists) 

 (so replication plugin rejected the total update (as any replication operation) because it is done by a seemingly wrong user)

Regards,

   Pierre

On Mon, Jan 31, 2022 at 9:20 AM Thierry Bordaz <tbordaz@redhat.com> wrote:

It would be better to have errors logs (with replication debug enabled) from both instances A and B

Also in the logs who is A and B (ldapserver1 and ldapserver2) ?

thanks

On 1/31/22 9:02 AM, Mansoor Raeesi wrote:

That is problem with CentOS paste which expires pastes within 24 hours!

you may check through this link:

https://pastebin.ubuntu.com/p/ktN5HsBrNf/


Thanks



On 1/31/22 11:24, Thierry Bordaz wrote:

Hi,

It returns 404 "page not found"

regards
thierry

On 1/30/22 7:58 AM, Mansoor Raeesi wrote:

Thanks for your kind reply, logging is enabled already and this is output of log:

https://paste.centos.org/view/a39010cd


On 1/26/22 12:14, Thierry Bordaz wrote:

Hi,

There are several possible cause why the replication agreement failed to complete the total update. I suggest you enable replication debug log on A and B (https://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), before retrying a total update. If it is the first time you are trying to init B, a common failure is that the RA fails to bind (credential are not properly set).

Because of the size of the DB, another option is to init B via an offline import. (on A export DB in ldif format with replication data, send the ldif file to B, import the ldif file on B). This likely speed up the initialization of B but you will still need to fix the RA A->B.

regards
thierry

On 1/26/22 6:41 AM, Mansoor Raeesi wrote:

Hi

I've recently started 2 different instances on different servers with 1.4.4.17 version of 389-ds. servers can see each other.

server A has a database around 28GB & both servers are started in Master mode. i've created an agreement on server A to be replicated with server B on port 389 when i initialize the agreement, after a while i'll receive this error in web console:

ERR - NSMMReplicationPlugin - repl5_tot_run - Total update failed for replica "agmt="cn=ServerA-to-ServerB" (ServerB:389)", error (-1)

Looking forward for your kind help.
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure

_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure

_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure

--

--

389 Directory Server Development Team