[jira] [Commented] (SOLR-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849705#comment-16849705 ] Tim commented on SOLR-11724: So what's the process for this patch to make it into an update? > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch, SOLR-11724.patch, > SOLR-11724.patch > > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11724) Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target
[ https://issues.apache.org/jira/browse/SOLR-11724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765096#comment-16765096 ] Tim commented on SOLR-11724: This fix seems to be bugged in 7.5. https://issues.apache.org/jira/browse/SOLR-13141 > Cdcr Bootstrapping does not cause "index copying" to follower nodes on Target > - > > Key: SOLR-11724 > URL: https://issues.apache.org/jira/browse/SOLR-11724 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: CDCR >Reporter: Amrit Sarkar >Assignee: Varun Thacker >Priority: Major > Fix For: 7.3.1, 7.4, 8.0 > > Attachments: SOLR-11724.patch, SOLR-11724.patch > > > Please find the discussion on: > http://lucene.472066.n3.nabble.com/Issue-with-CDCR-bootstrapping-in-Solr-7-1-td4365258.html > If we index significant documents in to Source, stop indexing and then start > CDCR; bootstrapping only copies the index to leader node of shards of the > collection, and followers never receive the documents / index until and > unless atleast one document is inserted again on source; which propels to > target and target collection trigger index replication to followers. > This behavior needs to be addressed in proper manner, either at target > collection or while bootstrapping. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13141) replicationFactor param cause problems with CDCR
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765087#comment-16765087
]
Tim edited comment on SOLR-13141 at 2/11/19 3:50 PM:
-
Unfortunately I've run into the same issues as well. Have not been able to find
a work around.
[http://lucene.472066.n3.nabble.com/CDCR-Unable-to-locate-core-td4423181.html#a4423708]
In 7.3 a fix was put in that once cdcr (leader to leader replication) had
completed the source collection sends a core recovery command to the target
collection's follower replicas. However it seems to be sending this to the
wrong nodes (hence the unable to locate core error). The command being sent to
the node of the leader replica instead of the node of the follower replica.
was (Author: timsolr):
Unfortunately I've run into the same issues as well. Have not been able to find
a work around.
[http://lucene.472066.n3.nabble.com/CDCR-Unable-to-locate-core-td4423181.html#a4423708]
In 7.3 a fix was put in that once cdcr had completed the source collection
sends a core recovery command to the follower replicas. However it seems to be
sending this to the wrong nodes (hence the unable to locate core error). The
command being sent to the node of the leader replica instead of the node of the
follower replica.
> replicationFactor param cause problems with CDCR
>
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Priority: Critical
> Attachments: type 1 - replication wasnt working at all.txt, type 2 -
> only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13141) replicationFactor param cause problems with CDCR
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765087#comment-16765087
]
Tim commented on SOLR-13141:
Unfortunately I've run into the same issues as well. Have not been able to find
a work around.
[http://lucene.472066.n3.nabble.com/CDCR-Unable-to-locate-core-td4423181.html#a4423708]
In 7.3 a fix was put in that once cdcr had completed the source collection
sends a core recovery command to the follower replicas. However it seems to be
sending this to the wrong nodes (hence the unable to locate core error). The
command being sent to the node of the leader replica instead of the node of the
follower replica.
> replicationFactor param cause problems with CDCR
>
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Priority: Critical
> Attachments: type 1 - replication wasnt working at all.txt, type 2 -
> only few documents were being replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Commented: (SOLR-2251) use facet key as override for field name when looking for per field facet options
[
https://issues.apache.org/jira/browse/SOLR-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935308#action_12935308
]
Tim commented on SOLR-2251:
---
Yup, I wasn't sure about the original intended behavior but the enhancement
seemed to make sense to me. Thanks for considering it.
use facet key as override for field name when looking for per field facet
options
---
Key: SOLR-2251
URL: https://issues.apache.org/jira/browse/SOLR-2251
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.4.1
Reporter: Tim
Priority: Minor
The key parameter that is used for aliasing output is very helpful in
simplifying the readability of complex facets. However it doesn't seem that
this same alias can be used when configuring facets of individual fields.
The following example that does not use the key parameter works fine under
1.4.1:
rows=0q=*:*+NOT+customers.blocked:1facet=truef.customers_name.facet.mincount=2facet.field=customers_name
lst name=customers_name
int name=jone2/int
/lst
The example below also works and does use the key parameter, however note
that we're still using the original field name when referring to
f.customers_name.facet.mincount:
rows=0q=*:*+NOT+customers.blocked:1facet=truef.customers_name.facet.mincount=2facet.field={!key=alt_name}customers_name
lst name=customers_name
int name=jone2/int
/lst
The final example below does not work. It uses the alias established by the
key parameter to configure the mincount setting for the customers_name field.
rows=0q=*:*+NOT+customers.blocked:1facet=truef.alt_name.facet.mincount=2facet.field={!key=alt_name}customers_name
lst name=alt_name
int name=jone2/int
int name=tim1/int
int name=sami0/int
/lst
This is a trivial example. The behavior becomes much more important when
talking about facet queries.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] Created: (SOLR-2251) Facet key not used when setting mincount, etc on individual facets
Facet key not used when setting mincount, etc on individual facets
Key: SOLR-2251
URL: https://issues.apache.org/jira/browse/SOLR-2251
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 1.4.1
Reporter: Tim
Priority: Minor
The key parameter that is used for aliasing output is very helpful in
simplifying the readability of complex facets. However it doesn't seem that
this same alias can be used when configuring facets of individual fields. The
following example that does not use the key parameter works fine under 1.4.1:
rows=0q=*:*+NOT+customers.blocked:1facet=truef.customers_name.facet.mincount=2facet.field=customers_name
lst name=customers_name
int name=jone2/int
/lst
The example below also works and does use the key parameter, however note that
we're still using the original field name when referring to
f.customers_name.facet.mincount:
rows=0q=*:*+NOT+customers.blocked:1facet=truef.customers_name.facet.mincount=2facet.field={!key=alt_name}customers_name
lst name=customers_name
int name=jone2/int
/lst
The final example below does not work. It uses the alias established by the
key parameter to configure the mincount setting for the customers_name field.
rows=0q=*:*+NOT+customers.blocked:1facet=truef.alt_name.facet.mincount=2facet.field={!key=alt_name}customers_name
lst name=alt_name
int name=jone2/int
int name=tim1/int
int name=sami0/int
/lst
This is a trivial example. The behavior becomes much more important when
talking about facet queries.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
