[ 
https://issues.apache.org/jira/browse/SOLR-6462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jakub Kotowski updated SOLR-6462:
---------------------------------
    Attachment: cdcr_version_replication.patch

To achieve not changing the version of received updates, I created the 
CdcrUpdateProcessor (extends DistributedUpdateProcessor) which checks if there 
is a "cdcr.update" parameter in the request and in such a case preserves the 
_version_.

We decided to subclass the DistributedUpdateProcessor in order to minimize the 
number of changes to it and to keep the CDCR-related logic as separate as 
possible. We set the PEER_SYNC flag on the update in order to avoid executing 
leader logic which creates new versions. It's done in such a way that the 
leader will still distribute the command to replicas.

Processing add and delete by id commands works, including the forwarding logic 
(sending updates to a non-leader). There is still a problem with delete by 
query. The test in the patch tests all the highlighted possible problems and 
fails the very last delete by query test in about 50% cases. I'll continue 
investigating the problem.

In the process, I also discovered a possible bug in optimistic concurrency - it 
seems it does not work with forwarding logic because _version_ is normally not 
preserved when forwarding delete by id and add updates. I'll open an issue 
about it.

> forward updates asynchronously to peer clusters/leaders
> -------------------------------------------------------
>
>                 Key: SOLR-6462
>                 URL: https://issues.apache.org/jira/browse/SOLR-6462
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Yonik Seeley
>         Attachments: cdcr_version_replication.patch
>
>
> http://heliosearch.org/solr-cross-data-center-replication/#UpdateFlow
> - An update will be received by the shard leader and versioned
> - Update will be sent from the leader to it’s replicas
> - Concurrently, update will be sent (synchronously or asynchronously) to the 
> shard leader in other clusters
> - Shard leader in the other cluster will receive already versioned update 
> (and not re-version it), and forward the update to it’s replicas



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to