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

Amrit Sarkar edited comment on SOLR-11003 at 7/21/17 8:53 PM:
--------------------------------------------------------------

[~erickerickson],
{quote}
And if my opening question is incorrect and one can index to both collections 
simultaneously, how does it work when the same document is sent go both 
collectionA and collectionB independently?
{quote}

*We can index in both the collection, collectionA and collectionB at run-time.* 
Now when same doc gets indexed simultaneously, 

say, docX indexed into collectionA assigned versionA
and docX (same) indexed into collectionB assigned versionB

docX pushed from collectionA to collectionB and will get indexed into 
collectionB only and only if {{versionA > versionB}}
docX pushed from collectionB to collectionA and will get indexed into 
collectionA only and only if {{versionB > versionA}}

In either case, one will prevail and one will fail and we will have *one 
winner*. The above mentioned is strong recommendation if you are going to set 
bi-directional cdcr on collections; index at one cluster at a time due the same 
simultaneous indexing scenario.

If in any case, a very less probability, {{versionA = versionB}}, then 
optimistic concurrency comes into play and versions of the document docX in 
both collections will be different, a new version will assigned at the 
respective target collections then.


was (Author: sarkaramr...@gmail.com):
[~erickerickson],
{quote}
And if my opening question is incorrect and one can index to both collections 
simultaneously, how does it work when the same document is sent go both 
collectionA and collectionB independently?
{quote}

*We can index in both the collection, collectionA and collectionB at run-time.* 
Now when same doc gets indexed simultaneously, 

say, docX indexed into collectionA assigned versionA
and docX (same) indexed into collectionB assigned versionB

docX pushed from collectionA to collectionB and indexed only and only if 
{{versionA > versionB}}
docX pushed from collectionB to collectionA and indexed only and only if 
{{versionB > versionA}}

In either case, one will prevail and one will fail and we will have *one 
winner*. The above mentioned is strong recommendation if you are going to set 
bi-directional cdcr on collections; index at one cluster at a time due the same 
simultaneous indexing scenario.

If in any case, a very less probability, {{versionA = versionB}}, then 
optimistic concurrency comes into play and versions of the document docX in 
both collections will be different, a new version will assigned at the 
respective target collections then.

> Enabling bi-directional CDCR active-active clusters
> ---------------------------------------------------
>
>                 Key: SOLR-11003
>                 URL: https://issues.apache.org/jira/browse/SOLR-11003
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: CDCR
>            Reporter: Amrit Sarkar
>            Assignee: Varun Thacker
>         Attachments: sample-configs.zip, SOLR-11003.patch, SOLR-11003.patch, 
> SOLR-11003-tlogutils.patch
>
>
> The latest version of Solr CDCR across collections / clusters is in 
> active-passive format, where we can index into source collection and the 
> updates gets forwarded to the passive one and vice-versa is not supported.
> https://lucene.apache.org/solr/guide/6_6/cross-data-center-replication-cdcr.html
> https://issues.apache.org/jira/browse/SOLR-6273
> We are try to get a  design ready to index in both collections and the 
> updates gets reflected across the collections in real-time. 
> ClusterACollectionA => ClusterBCollectionB | ClusterBCollectionB => 
> ClusterACollectionA.
> The best use-case would be to we keep indexing in ClusterACollectionA which 
> forwards the updates to ClusterBCollectionB. If ClusterACollectionA gets 
> down, we point the indexer and searcher application to ClusterBCollectionB. 
> Once ClusterACollectionA is up, depending on updates count, they will be 
> bootstrapped or forwarded to ClusterACollectionA from ClusterBCollectionB and 
> keep indexing on the ClusterBCollectionB.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to