[
https://issues.apache.org/jira/browse/SOLR-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16265542#comment-16265542
]
Erick Erickson commented on SOLR-11670:
---------------------------------------
Here's a way to generate dead nodes in 6x:
Set up a single solr instance, starting it like this:
bin/solr start -z localhost:2181 -p 8981 -s example/cloud/node1/solr
Create a collection (one shard and one replica will do).
Stop that instance and start another changing the port but keeping the same
SOLR_HOME:
bin/solr start -z localhost:2181 -p 8982 -s example/cloud/node1/solr
(note, the port has changed, but the -s points to where the old core.properties
file is located).
legacyCloud=true needs to be true for this case.
7x doesn't exhibit the behavior at all. I think the issue is that coreNodeName
gets defined in core.properties and is used to update an existing znode if
things like the base_url or node_name change.
> Implement a periodic house-keeping task
> ---------------------------------------
>
> Key: SOLR-11670
> URL: https://issues.apache.org/jira/browse/SOLR-11670
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
>
> Some high-impact cluster changes (such as split shard) leave the original
> data and original state that is no longer actively used. This makes sense due
> to safety reasons and to make it easier to roll-back the changes.
> However, this unused data will accumulate over time, especially when actions
> like split shard are invoked automatically by the autoscaling framework. We
> need a periodic task that would clean up this kind of data after a certain
> period.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
