Zisis:
It's not so much that the behavior has changed, and it's still
perfectly possible to use old-style solr.xml. Rather,
it's that there has been quite a lot of hardening how SolrCloud
creates things. I realize that the Collections API
is more of a black box and you have to take on faith that i
Erick Erickson wrote
> OK, I think this is the root of your problem:
>
> bq: Everything was setup using the - now deprecated - tags
>
> and
>
> inside solr.xml.
>
> There are a bunch of ways this could go wrong. I'm pretty sure you
> have something that would take quite a while to untangle
OK, I think this is the root of your problem:
bq: Everything was setup using the - now deprecated - tags
and inside solr.xml.
There are a bunch of ways this could go wrong. I'm pretty sure you
have something that would take quite a while to untangle, so unless
you have a _very_ good reason fo
>From the logs I've got one instance failing as described in my first comment
and the other two failing during PeerSync recovery when trying to
communicate with the server that was missing the segments_* files. The
exception follows
org.apache.solr.client.solrj.SolrServerException: IOException oc
Well, I don't know If I'm being helpful but here goes.
My clusterstate.json actually has no leader for the shard in question. I
have 2 nodes as "recovery_failed" and one as "down". No leaders there. I've
not used core admin or collections api to create anything. Everything was
setup using the - now
So after adding some docs to the index (and committing) with those two
nodes active,
do segment files magically appear?
My _guess_ is that there's something radially wrong with you set up
the collection. Did
you by any chance use the core admin API to create the cores? That can lead to
"interestin
