Wait. What were you doing originally? Just copying the entire SOLR_HOME over or something?
Because one of the things each core carries along is a "core.properties" file that identifies 1> the name of the core, something like collection_shard1_replica1 2> the name of the collection the core belongs to So if you just copy a directory containing the core.properties file from one place to another _and_ they're pointing to the same Zookeeper then the behavior is undefined. And if you _don't_ point to the same zookeeper, your copied collection isn't registered with ZK so that's a weird state as well. If your goal is to move things from one collection to another, here's a possibility (assuming the nodes can all "see" each other). 1> index to your source collection 2> create a new destination collection 3a> use the "fetchindex" command to move the relevant indexes from the source to the destination, see https://cwiki.apache.org/confluence/display/solr/Index+Replication#IndexReplication-HTTPAPICommandsfortheReplicationHandler 3b> instead of <3a>, manually copy the data directory from the source to each replica. 4> In either 3a> or 3b>, it's probably easier to create a leader-only (replicationFactor=1) destination collection then use the ADDREPLICA command to add replicas, that way they'll all sync automatically. Best, Erick On Thu, Nov 3, 2016 at 10:28 AM, Pablo Anzorena <anzorena.f...@gmail.com> wrote: > Thanks Shawn. > > Actually there is no load balancer or proxy in the middle, but even if > there was, how would you explain that I can index if a create a completely > new collection? > > I figured out how to fix it. What I'm doing is creating a new collection, > then unloading it (by unloading all the shards/replicas), then copy the > data directory from the collection in the other solrcloud, and finally > creating again the collection. It's not the best solution, but it works, > nevertheless I still would like to know what's causing the problem... > > It's worth to mention that I'm not using jetty, I'm using solr-undertow > https://github.com/kohesive/solr-undertow > > 2016-11-03 12:56 GMT-03:00 Shawn Heisey <apa...@elyograg.org>: > >> On 11/3/2016 9:10 AM, Pablo Anzorena wrote: >> > Thanks for the answer. >> > >> > I checked the log and it wasn't logging anything. >> > >> > The error i'm facing is way bizarre... I create a new fresh collection >> and >> > then index with no problem, but it keeps throwing this error if i copy >> the >> > collection from one solrcloud to the other and then index. >> > >> > Any clue on why is this happening? >> >> Solr's source code doesn't seem to even have a 405 error, so I bet >> what's happening is that you have Solr sitting behind a proxy or load >> balancer, and that server doesn't like the request you sent, so it >> rejects it and Solr never receives anything. >> >> Here's an excerpt of code from the SolrException class in the master >> branch: >> >> /** >> * This list of valid HTTP Status error codes that Solr may return in >> * the case of a "Server Side" error. >> * >> * @since solr 1.2 >> */ >> public enum ErrorCode { >> BAD_REQUEST( 400 ), >> UNAUTHORIZED( 401 ), >> FORBIDDEN( 403 ), >> NOT_FOUND( 404 ), >> CONFLICT( 409 ), >> UNSUPPORTED_MEDIA_TYPE( 415 ), >> SERVER_ERROR( 500 ), >> SERVICE_UNAVAILABLE( 503 ), >> INVALID_STATE( 510 ), >> UNKNOWN(0); >> public final int code; >> >> private ErrorCode( int c ) >> { >> code = c; >> } >> public static ErrorCode getErrorCode(int c){ >> for (ErrorCode err : values()) { >> if(err.code == c) return err; >> } >> return UNKNOWN; >> } >> }; >> >> Thanks, >> Shawn >> >>
