[
https://issues.apache.org/jira/browse/SOLR-11003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222265#comment-16222265
]
Amrit Sarkar commented on SOLR-11003:
-------------------------------------
Varun,
thank you for the constructive feedback.
> We could however argue that this improvement could be implemented for the
> regular transaction log as well. So let's put this for another Jira
I understand what you are saying, we can certainly do this to make the
back-compat safe. This can be part of next iteration of CDCR optimisation.
> In CDCRBiDirectionalTest can we have one try block instead of two currently.
> In the finally we could do a null check before shutting down
I was following {{CdcrBootstrapTest}} format Shalin wrote, but yeah maybe two
try catch not required, changed as suggested.
> Methods like cdcrStart are the same in CdcrBootstrapTest. Can we put them in
> a util class and reuse?We also have
> BaseCdcrDistributedZkTest#invokeCdcrAction . Let's refactor the usage
> waitForClusterToSync is the same as CdcrBootsrapTest#waitForTargetToSync
Positively, moved to {{CdcrTestsUtil}}, we can surely make some code effective
refactoring when we write this.
> Even CdcrBootstrapTest#indexDocs can be factored into the util class and
> reused here?
We can, but then we have to specify the {{prefix}} for id for each collection,
we can leave the refactoring there I guess.
> Can we use the logger instead of System.out.println
Done.
> After we add docs to cluster 1, can we do a assert that the numFound is not 0
> . Just a sanity check to make sure we indexed docs atleast.
We have already added this check at every stage, doing {{*:*}} at source.
> Are we printing the queue responses just for debugging? can we change that to
> an assert?
We cannot assert on that, as queue responses will be different for different
clusters, we are just printing it for our reference.
> For /get?getVersions=X we need to do distrib=false . But since this is a one
> shard collection we don't need to I guess. You can add fingerprint=true and
> use the maxVersionEncountered key instead of calculating the max in code?
I have to see this, how to do this part. I copied _blindly_ from
{{CdcrBootstrapTest}}, and as {{fingerprint}} was not introduced when bootstrap
came in, its not there.
> After a DBQ/delete-by-id/atomic updates we do a 2s thread wait. Can we not
> rely on this and use waitForClusterToSync? In general we should not be doing
> any thread sleeps in the test
Yeah that was poor test writing, fixed this. Thanks for pointing it out.
Pending: introducing {{fingerprint}} to get the maxVersion.
> Enabling bi-directional CDCR on cluster for better failover
> -----------------------------------------------------------
>
> 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: SOLR-11003-tlogutils.patch, SOLR-11003.patch,
> SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch, SOLR-11003.patch,
> SOLR-11003.patch, SOLR-11003.patch, sample-configs.zip
>
>
> 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 (given the backlog
> of replicating updates to other data center). ClusterACollectionA =>
> ClusterBCollectionB | ClusterBCollectionB => ClusterACollectionA.
> The STRONG RECOMMENDED way to 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: [email protected]
For additional commands, e-mail: [email protected]
