directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny (Jira) <j...@apache.org>
Subject [jira] [Commented] (DIRSERVER-2316) Initial refresh in a refreshAndPersist replication doesn't provide full subtree in master-master configuration
Date Wed, 01 Jul 2020 12:11:00 GMT

    [ https://issues.apache.org/jira/browse/DIRSERVER-2316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149380#comment-17149380
] 

Emmanuel Lécharny commented on DIRSERVER-2316:
----------------------------------------------

Hi Kaamil,

sorry for answering late... Although I don't have an easy solution for your problem, it would
require some time to get it fixed.

I *strongly* suggest you switch to OpenLDAP which is proven to be solid when it comes to replication.

> Initial refresh in a refreshAndPersist replication doesn't provide full subtree in master-master
configuration
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: DIRSERVER-2316
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-2316
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: replication
>    Affects Versions: 2.0.0.AM26
>            Reporter: Kaamil Jasani
>            Priority: Major
>         Attachments: apacheds-syncrepl-issue.zip
>
>
> In our current setup, we have two instances of ApacheDS running (ads0 and apacheds-main).
They are configured in a master-master replication setup, both disabled by default. Each is
initialized with some users and groups.
> Once both instances are started, we enable the replication consumer on ads0 and restart
it. This causes a refresh and pulls the data from apacheds-main into ads0. We then disable
the consumer and restart it again. At this point, ads0 contains a full image of the data,
whereas apacheds-main only contains the data it initially had. If we now enable the replication
consumer on apacheds-main, we would expect all the data from ads0 to be replicated into apacheds-main
during the initial refresh. However, this is not the case and what we see is that apacheds-main
still only has the data it started out with. We know that the data exists in ads0 since we
can search for it and see it in Apache Directory Studio.
> What is puzzling is that if the same procedure is carried out in the opposite direction,
it works as intended. That is, if rather than replicating from apacheds-main to ads0 first
we do it the other way, in the end both ApacheDS instances end up with a full image. There
is no functional difference in the configuration of the two instances.
>  
> The real problem arises with this when we need to restart one of these instances. What
seems like the same problem seems to occur again fairly erratically. The symptoms also seem
kind of random, where sometimes the data will simply not be synced over, sometimes the data
is deleted from both instances, or sometimes the entire partition gets corrupted and is no
longer available for writing or reading. Running ApacheDS with {{repair}} instead of {{start}}
brings the partition back, but not all the data seems to be retrieved.
> I have attached an archive with the logs for both instances in both situations. It contains
5 files:
>  * {{ADS0FIRST-ads0.log}}: logs for ads0 when replicating to ads0 first
>  * {{ADS0FIRST-apacheds-main.log}}: logs for apacheds-main when replicating to ads0 first
>  * {{ADS0FIRST-ads0-direct-search.ldif}}: search result showing all the data existing
in ads0
>  * {{ADSMAINFIRST-ads0.log}}: logs for ads0 when replicating to apacheds-main first
>  * {{ADSMAINFIRST-apacheds-main.log}}: logs for apacheds-main when replicating to apacheds-main
first



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org


Mime
View raw message