: Not really ... uptime is irrelevant because they aren't in production. I just : don't want to spend the time reloading 1TB of documents.
terminologiy confusion: you mean you don't wnat to *reindex* all of the documents ... in solr "reloading" a core means something specific & different from what you are talking about, and is what michael.boom was refering to. : I want to bring them all into a cloud collection. Assume I have 3 cores/shards : : core1 : core2 : core3 You can't convert arbitrary cores into shards of a new collection, because the document routing logic (which dictates what shard a doc lives in based on it's uniqueKey) won't make sense. you could theoretically implement a custom router class that knows about whatever rules you've used in the past to decide docs go in core1, core2, core3, etc... but that would probably be fairly complicated. : I want to be able to address all three as if they were shards of a collection, : something like. w/o reindexing, one thing you could do is create a single collection for each of your cores, and then create a collection alias over all three of these collections... https://cwiki.apache.org/confluence/display/solr/Collections+API#CollectionsAPI-CreateormodifyanAliasforaCollection : I want to be able to load to collection1. search collection1 etc. can you elaborate on what you mean by "load to collection1" ... being about to "search collection1" (where collection1 is an alias for core1_collection, core2_collection, core3_collection) would be easy ... but understanding what your goal is moving forward with "loading" is important. if you want to just be able to shove docs to a single "collection" in solr cloud and have them replace docs with the same uniqueKey then you're going to need to either: re-index using SolrCloud so the default document routing is done properly up front; implement a custom doc router that knows about whatever rules you used to decide what would be in core1, core2, core3. -Hoss http://www.lucidworks.com/
