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
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.
On 1/26/22 6:41 AM, Mansoor Raeesi wrote:
> I've recently started 2 different instances on different servers with
> 184.108.40.206 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 -- email@example.com
> To unsubscribe send an email to firstname.lastname@example.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> Do not reply to spam on the list, report it:
389-users mailing list -- email@example.com
To unsubscribe send an email to firstname.lastname@example.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://email@example.com
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure