Am 05.12.2011 14:28, schrieb Per Steffensen:
Hi
Reading http://wiki.apache.org/solr/SolrReplication I notice the
"pollInterval" (guess it should have been "pullInterval") on the slaves.
That indicate to me that indexed information is not really "pushed" from
master to slave(s) on events defined by "replicateAfter" (e.g. commit),
but that it only will be made available for pulling by the slaves at
those events. So even though I run with a master with
"replicateAfter=commit", I am not sure that I will be able to query a
document that I have just indexed from one of the slaves immediately
after having done the indexing on the master - I will have to wait
"pollInterval" (+ time for replication). Can anyone confirm that this is
a correct interpretation, or explain how to understand "pollInterval" if
it is not?
This is totally correct.
I want to acheive this always-in-sync property between master and slaves
(primary and replica if you like). What is the easiest way? Will I just
have to make sure myself that indexing goes on directly on all "replica"
of a shard, and then drop using the replication explained on
http://wiki.apache.org/solr/SolrReplication?
When committing, Solr will need some time (at least some microseconds,
may be much more) to zpdate your changes into its index. In the
meantime, the existing index readers will still work on the old,
uncommitted index state. Therefore you'll surely fail when you rely on a
committed index state immediately after your commit command, even
without any replication on a single machine.
Why do you need such a feature? I don't think that there's a way to make
Solr behave like this.
-Kuli
