The paradigm is different. In SolrCloud when a client sends an indexing request to any node in the system, when the response comes back all the nodes (leaders, followers, etc) have _all_ received the update and processed it. So you don't have to care in the same way.
As far as different segments, versions, and all that this is entirely expected. Considering the above. Packet->leader. leader->follower. Each of them is independently indexing the documents, there is no replication. So, since the two servers started at different times, things like the autocommit interval can kick in at different times and the indexes diverge in terms of segment counts, version numbers, whatever. They'll return the same _documents_, but.... FWIW, Erick On Mon, Jun 30, 2014 at 7:55 AM, Giovanni Bricconi <giovanni.bricc...@banzai.it> wrote: > Hello > > I have one application that queries solr; when the index version changes > this application has to redo some tasks. > > Since I have more than one solr server, I would like to start these tasks > when all solr nodes are synchronized. > > With master/slave configuration the application simply watched > http://myhost:8080/solr/admin/cores?action=STATUS&core=0bis > on each solr node and checked that the commit time msec was equal. When the > time changes and becomes equal on all the nodes the replication is complete > and it is safe to restart the tasks. > > Now I would like to switch to a solrcloud configuration, splitting the core > 0bis in 3 shards, with 2 replicas for each shard. > > After refeeding the collection I tried the same approach calling > > http://myhost:8080/solr/admin/cores?action=STATUS&core=0bis_shard3_replica2 > > for each core of the collection, but with suprise I have found that on the > same stripe the version of the index, the number of segments and even the > commit time msec was different!! > > I was thinking that it was possible to check some parameter on each > stripe's core to check that everithing was up to date, but this does not > seem to be true. > > Is it possible somehow to capture the "commit done on every core of the > collection" event? > > Thank you > > Giovanni
