No, it doesn't mean that at all. Consider the situation where you bring up a new replica and it's added to slice/shard X and that the index contains 60M documents so far. You don't want to re-index all those documents from the transaction log even if they are all _in_ the transaction log (which I don't believe they are anyway).
So SolrCloud will do an old-style replication of the existing index and then switch to the normal SolrCloud NRT updating process. Only after all the synching has been done will SolrCloud start sending queries to the new replica. This heuristic is applied whenever there are a lot of updates not yet reflected in a replica, which happens when a machine is offline for some period of time... As long as all your replicas haven't gone off-line, old-style replication isn't performed. Best Erick On Sat, Sep 8, 2012 at 11:37 PM, Zhang, Lisheng <lisheng.zh...@broadvision.com> wrote: > Hi Erick, > > You mentioned that "it'll automatically use old-style > replication to do the bulk synchronization" in solr > cloud, so it uses HTTP for replication as in 3.6, does > this mean the synchronization in solrCloud is not real > time (has to have some delays)? > > Thanks very much for helps, Lisheng > > -----Original Message----- > From: Erick Erickson [mailto:erickerick...@gmail.com] > Sent: Saturday, September 08, 2012 1:44 PM > To: solr-user@lucene.apache.org > Subject: Re: SolrCloud vs SolrReplication > > > See inline > > On Sat, Sep 8, 2012 at 1:09 AM, thaihai <thai...@live.de> wrote: >> Hi All, >> >> im little bit confussed about the new cloud functinalities. >> >> some questions: >> >> 1) its possible to use the old style solrreplication in solr4 (it means not >> using solrcloud. not starting with zk params) ? >> > > Yes. If you use SolrCloud (the Zookeeper options), you don't need to > set up replication. But if you don't use SolrCloud it's just like it was > in 3.x. > > >> 2) in our production-environment we use solr 3.6 with solrreplication. we >> have 1 index server und 2 front (slave) server. one webapp use the both >> front-server for searching. another application push index-requests to the >> index-server. the app have queueing. so we dont must have HA here. >> if we make index (schema) changes or need to scratch and reeindex the whole >> index we have do following szenario: >> 1 remove replication for both front-server >> 2 scratch index server >> 3 reeindex index server >> 4 remove front 1 server from web app (at this point webapp use only front2 >> for searches) >> 5 scratch front 1 >> 6 enable front 1 replication >> 7 test front 1 server with searches over lucene admin ui on front 1 >> 8 if all correct, enable front 1 for web app >> 9 done all with second slave at point 4 >> >> so, my problem is to do the same functionality with solr cloud ? >> >> supposed, i have a 2 shared with replicas cluster. how can i make a complete >> re-eindex with no affects for the web app during the index process ? and i >> will check the rebuild before i approve the new index to the web app. ??? >> >> any ideas or tips ? >> >> sorry for the bad english >> >> > > I'm not entirely sure about this, meaning I haven't done it personally. But > I think you can do this... > > Let's take the simple 2-shard case, each with a leader and replica. > Take one machine > out of each slice (or have two other machines you can use). Make your schema > changes and re-index to these non-user-facing machines. These are now a > complete > new index of two shards. > > Now point your user traffic to these new indexes (they are SolrCloud > machines). > Now simply scratch your old machines and bring them up in the same > cluster as the > two new machines, and SolrCloud will automatically > 1> assign them as replicas of your two shards appropriately > 2> synchronize the index (actually, it'll automatically use old-style > replication > to do the bulk synchronization, you don't have to configure anything). > 3> route searches to the new replicas as appropriate. > > You really have to forget most of what you know about Solr replication when > moving to the Solr Cloud world, it's all magic <G>... > > Best > Erick > >> >> -- >> View this message in context: >> http://lucene.472066.n3.nabble.com/SolrCloud-vs-SolrReplication-tp4006327.html >> Sent from the Solr - User mailing list archive at Nabble.com.
