Shawn thanks for detailed answer, it explains everything. I think that there is no problem. I will use 4.3. when it is available and if I see a situation something like that I will report.
2013/5/3 Shawn Heisey <s...@elyograg.org> > 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 > >
