On 6/17/21 2:11 PM, Marco Favero wrote:
Ah, I don't have RA rh5-->dr-rh1.
So, I could setup a RA from all multimaster to dr-rh1 to avoid this kind of
problems.
I'm not sure to understand. Really, I have a real time RA from rh5 to rh1, and
from rh1 to rh5. So, if I initialize rh1 from rh5,
Ah, I don't have RA rh5-->dr-rh1.
So, I could setup a RA from all multimaster to dr-rh1 to avoid this kind of
problems.
I'm not sure to understand. Really, I have a real time RA from rh5 to rh1, and
from rh1 to rh5. So, if I initialize rh1 from rh5, rh1 should still replicates
to dr-rh1,
On 6/17/21 12:58 PM, Marco Favero wrote:
On 6/17/21 10:55 AM, Marco Favero wrote:
Hi Marco,
good to know you fixed the issue. If I read you correctly you fixed it
via setting nsDS5ReplicaHost=FQDN of the consumer host in the
replication agreement supplier->consumer. What is surprising is that
Hi Thierry,
thank you for these hints. I resolved by setting the "full_machine_name" to
the fqdn of the host.
But I still have another issue very similar to
https://access.redhat.com/solutions/2690611
Because I realized to have a RHDS 11.4 I try to ask to that support too.
Thank you
Warm
On 6/7/21 9:39 AM, Marco Favero wrote:
Gasp, I suspect the problem seems to be here. In the agreements I see
dn: cn=it 2--\3E1,cn=replica,cn=c\3Dit,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: it 2-->1
cn: it 2--\>1
nsDS5ReplicaRoot: c=it
description:
Gasp, I suspect the problem seems to be here. In the agreements I see
dn: cn=it 2--\3E1,cn=replica,cn=c\3Dit,cn=mapping tree,cn=config
objectClass: top
objectClass: nsds5replicationagreement
cn: it 2-->1
cn: it 2--\>1
nsDS5ReplicaRoot: c=it
description: it 2-->1
nsDS5ReplicaHost: srv1.example.com
Even if I fix as described the above issue, if I restart a replica, then the
suppliers stop to send the update and they claim with
"The remote replica has a different database generation ID than the local
database. You may have to reinitialize the remote replica, or the local
replica."
So,
> does srv2 run 1.4.3.22 ?
Yes, it is a fresh installation.
> you could try to delete the BDB region files, first stop the LDAP service,
> then delete the files
> /var/lib/dirsrv/slapd-xx/db/"__db.00*
uhm... I keep these file in a RAM fs. srv2 and srv3 are fresh installations and
received his
does srv2 run 1.4.3.22 ?
you could try to delete the BDB region files, first stop the LDAP service,
then delete the files
/var/lib/dirsrv/slapd-xx/db/"__db.00*
or try a more recent 1.4.4.15 or 1.4.4.16
Thanks,
M.
On Tue, Jun 1, 2021 at 5:30 AM Marco Favero wrote:
> Hello,
>
> I'm dealing
