Hi there! :)
I have a question about replication process. After a slave downloaded the
new index files, then an automatic commit occures, which actualizes the
index on the slave. My problem is we have 4 slaves and 6 collections and we
have to wait all of the new collection until we release the new
It's certainly stable enough to start experimenting with, and I know
that it's under pretty active development now. I've seen a lot
of back-and-forth between Mark Miller and Jamie Johnson,
Jamie trying things and Mark responding.
It's part of the trunk, so be prepared for occasional re-indexing
be
Erick,
> You'll *really like* the SolrCloud stuff going into trunk when it's baked
> for a while
How stable is SolrCloud at the moment?
I can not wait to try it out.
Kind regards,
Em
Am 22.02.2012 14:45, schrieb Erick Erickson:
> You'll *really like* the SolrCloud stuff going into trunk whe
You'll *really like* the SolrCloud stuff going into trunk when it's baked
for a while
Best
Erick
On Wed, Feb 22, 2012 at 3:25 AM, eks dev wrote:
> Yes, I consciously let my slaves run away from the master in order to
> reduce update latency, but every now and then they sync up with master
>
Sounds much clearer to me than before. :)
Ad-hoc I have two ideas:
First: Let Replication run asynchronously.
If shard1 is pulling the new index from the master and therefore very
recent documents aren't available anymore, shard2 will find them in the
mean-time. As soon as shard1 is up-to-date (in
Yes, I consciously let my slaves run away from the master in order to
reduce update latency, but every now and then they sync up with master
that is doing heavy lifting.
The price you pay is that slaves do not see the same documents as the
master, but this is the case anyhow with replication, in m
Eks,
that sounds strange!
Am I getting you right?
You have a master which indexes batch-updates from time to time.
Furthermore you got some slaves, pulling data from that master to keep
them up-to-date with the newest batch-updates.
Additionally your slaves index own content in soft-commit mode t
And drinks on me to those who decoupled implicit commit from close...
this was tricky trap
On Tue, Feb 21, 2012 at 9:10 PM, eks dev wrote:
> Thanks Mark,
> Hmm, I would like to have this information asap, not to wait until the
> first search gets executed (depends on user) . Is solr going to crea
Thanks Mark,
Hmm, I would like to have this information asap, not to wait until the
first search gets executed (depends on user) . Is solr going to create
new searcher as a part of "replication transaction"...
Just to make it clear why I need it...
I have simple master, many slaves config where ma
Post commit calls are made before a new searcher is opened.
Might be easier to try to hook in with a new searcher listener?
On Feb 21, 2012, at 8:23 AM, eks dev wrote:
> Hi all,
> I am a bit confused with IndexSearcher refresh lifecycles...
> In a master slave setup, I override postCommit listen
Hi all,
I am a bit confused with IndexSearcher refresh lifecycles...
In a master slave setup, I override postCommit listener on slave
(solr trunk version) to read some user information stored in
userCommitData on master
--
@Override
public final void postCommit() {
// This returnes "stale"
11 matches
Mail list logo
