[
https://issues.apache.org/jira/browse/SOLR-8389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16184000#comment-16184000
]
Amrit Sarkar edited comment on SOLR-8389 at 10/9/17 11:22 AM:
--------------------------------------------------------------
Proposed design:
As state.json for collections gets modified / overwritten every time there is a
state change of the nodes, it is somehow risky to put the cdcr configurations
in the same place, as it can unnecessary bootstrap and other inconsistencies.
On an offline discussion with [~shalinmangar], we plan to:
1. have seperate config json for cdcr at root level dir in zookeeper:
{{/cdcr.json}}
2. they should be collection specific in following format:
{code}
{
"collection1": {
"replica": {
"zkHost":"target-zk-host:target-zk-port/chroot-to-solr",
"source":"collection1",
"target":"collection1"
},
"replicator": {
"threadPoolSize":"8",
"schedule":"1000",
"batchSize":"128"
},
"updateLogSynchronizer": {
"schedule":"1000"
}
}
}
{code}
3. the cdcr config should be passed with *CREATE* collection command as the
collection must use {{CdcrUpdateLog}} and not the conventional one,
{{UpdateLog}}.
4. expose collections api like {{SETCDCR}} to modify CDCR configuration. It
will require collection reload, hence will be implicit. {{REMOVECDCR}} api
should not be exposed, as it will be of no use since the collection is already
created with {{CdcrUpdateLog}}.
The back-combat will be established, with cdcr json config overriding
solrconfig ones.
If no objection with the design, will move forward with development.
was (Author: [email protected]):
Proposed design:
As state.json for collections gets modified / overwritten every time there is a
state change of the nodes, it is somehow risky to put the cdcr configurations
in the same place, as it can unnecessary bootstrap and other inconsistencies.
On an offline discussion with [~shalinmangar], we plan to:
1. have seperate config json for cdcr at root level dir in zookeeper:
{{/cdcr.json}}
2. they should be collection specific in following format:
{code}
{
"collection1": {
"replica": {
"zkHost":"target-zk-host:target-zk-port/chroot-to-solr",
"source":"collection1",
"target":"collection1"
},
"replicator": {
"threadPoolSize":"8",
"schedule":"1000",
"batchSize":"128"
},
"updateLogSynchronizer": {
"schedule":"1000"
}
}
}
{code}
3. the cdcr config should be passed with *CREATE* collection command as the
collection must use {{CdcrUpdateLog}} and not the conventional one,
{{UpdateLog}}.
4. expose collections api like "SETCDCR" to modify CDCR configuration. It will
require collection reload, hence will be implicit. Removing CDCR api should not
be exposed, as it will be of no use since the collection is already created
with {{CdcrUpdateLog}}.
The back-combat will be established, with cdcr json config overriding
solrconfig ones.
If no objection with the design, will move forward with development.
> Convert CDCR peer cluster and other configurations into collection properties
> modifiable via APIs
> -------------------------------------------------------------------------------------------------
>
> Key: SOLR-8389
> URL: https://issues.apache.org/jira/browse/SOLR-8389
> Project: Solr
> Issue Type: Improvement
> Components: CDCR, SolrCloud
> Reporter: Shalin Shekhar Mangar
>
> CDCR configuration is kept inside solrconfig.xml which makes it difficult to
> add or change peer cluster configuration.
> I propose to move all CDCR config to collection level properties in cluster
> state so that they can be modified using the existing modify collection API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
