On 5/2/2013 2:19 PM, Furkan KAMACI wrote: > I see that at my admin page: > > Replication (Slave) Version Gen Size > Master: 1367307652512 82 778.04 MB > Slave: 1367307658862 82 781.05 MB > > and I started to figure about it so that's why I asked this question.
As we've been trying to tell you, the sizes can (and will) be different between replicas on SolrCloud. Also, if you're not running a recent release candidate of 4.3, then the version numbers on the replication screen are misleading. See SOLR-4661 for more details. Your example of version numbers like 100, 90, and 95 wouldn't actually happen, because the version number is based on the current time in milliseconds since 1970-01-01 00:00:00 UTC. If you index after killing the leader, the new leader's version number will be higher than the offline replica. If you can find actual proof of a problem with index updates related to killing the leader, then we can take the bug report and work on fixing it. Here's how you would go about finding proof. It would be easiest to have one shard, but if you want to make sure it's OK with multiple shards, you would have to kill all the leaders. * Start with a functional collection with two replicas. * Index a document with a recognizable ID like "A". * Make sure you can find document A. * Kill the leader replica, let's say it was replica1. * Make sure replica2 becomes leader. * Make sure you can find document A. * Index document B. * Start replica1, wait for it to turn green. * Make sure you can still find document B. * Kill the leader again, this time it's replica2. * Make sure you can still find document B. To my knowledge, nobody has reported a real problem with proof. I would imagine that more than one person has done testing like this to make sure that SolrCloud is reliable. Thanks, Shawn
