[
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
The problem with version replication in delete by query was that the CDCR
updates weren't distributed from leader to replicas. The reason is that
doDeleteByQuery() is structured differently than processAdd() and
processDelete() in DistributedUpdateProcessor. We refactored doDeleteByQuery()
by extracting a portion of its code into a helper method versionDeleteByQuery()
which is then overriden in the CdcrUpdateProcessor. This way doDeleteByQuery()
is structurally similar to the other two cases and we are able to keep the CDCR
logic completely separated. All the test pass now, see the new patch.
> 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,
> 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]
