I don't think this will work in the long run with Solr4 (not sure you're using this or not). Solr4 will assign updates to a shard based on a hash of the <uniqueKey>. So let's say you have docs on your original three shards: shard 1 has docs 1, 4, 7 shard 2 has docs 2, 5, 8 shard 3 has docs 3, 6, 9
Now you merge shards 2 and 3, and you have shard 1 - 1, 4, 7 shard 2 - 2, 3, 5, 6, 8, 9 Now if you update docs 1 or 2, everything's fine. But, if you re-index doc 3, it'll be assigned shard 1. Now you have two live documents on different shards with the same ID. You'll get both back for searches, one will be stale, etc. This is a Bad Thing. And even if you're on 3.x and assigning docs to shards yourself, you now have pretty unbalanced shards, shard2 is twice as big as shard1. NOTE: The actual doc->shard assignment is NOT a simple round-robin, this is just for illustration.... Unless re-indexing is _really_ expensive, I'd just count on re-indexing when changing the number of shards. At least until "shard splitting" is in place for Solr4. And I'm not sure shard splitting will also handle shard merging, I'd check before assuming so... Best Erick On Fri, Jan 11, 2013 at 8:47 AM, mizayah <miza...@gmail.com> wrote: > Seams I'm to lazy. > I found this http://wiki.apache.org/solr/MergingSolrIndexes, and it works > rly. > > > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/SolrCloud-removing-shard-how-to-not-loose-data-tp4032138p4032508.html > Sent from the Solr - User mailing list archive at Nabble.com. >
