You do that with schema changes and I’ll watch your site crash.
wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/
On Nov 1, 2014, at 8:31 PM, Will Martin wrote:
> Well yes. But since there hasn't been any devops approaches yet, we really
> aren't talking about Conti
Well yes. But since there hasn't been any devops approaches yet, we really
aren't talking about Continuous Delivery. Continually delivering builds into
production is old hat and Jack nailed the canonical manners in which it has
been done. It really depends on whether an org is investing in the full
bq: but it should be more or less a constant factor no matter how many
Solr nodes you are using, right?
Not really. You've stated that you're not driving Solr very hard in
your tests. Therefore you're waiting on I/O. Therefore your tests just
aren't going to scale linearly with the number of shard
On 11/1/2014 11:45 AM, Shawn Heisey wrote:
> Is this a bug, or have I done something wrong in my config? Should I be
> putting this on the log4j mailing list instead of here? My best guess
> about how this is happening is that an entire logfile is getting deleted
> during rotation.
I did find th
There appear to be large blocks of time missing in my solr logfiles
created with slf4j->log4j and rotated using the log4j config:
End of solr.log.1: INFO - 2014-10-31 12:52:25.073;
Start of solr.log: INFO - 2014-11-01 02:27:27.404;
End of solr.log.2: INFO - 2014-10-29 06:30:32.661;
Start of so
Nice pictures, but that preso does not even begin to answer the question.
With master/slave replication, I do schema migration in two ways, depending on
whether a field is added or removed.
Adding a field:
1. Update the schema on the slaves. A defined field with no data is not a
problem.
2. Up
On 11/1/2014 9:52 AM, Ian Rose wrote:
> Just to make sure I am thinking about this right: batching will certainly
> make a big difference in performance, but it should be more or less a
> constant factor no matter how many Solr nodes you are using, right? Right
> now in my load tests, I'm not actu
Erick,
Just to make sure I am thinking about this right: batching will certainly
make a big difference in performance, but it should be more or less a
constant factor no matter how many Solr nodes you are using, right? Right
now in my load tests, I'm not actually that concerned about the absolute
http://www.thoughtworks.com/insights/blog/enabling-continuous-delivery-enterprises-testing
-Original Message-
From: Jack Krupansky [mailto:j...@basetechnology.com]
Sent: Saturday, November 01, 2014 9:46 AM
To: solr-user@lucene.apache.org
Subject: Re: How to update SOLR schema from contin
In all honesty, incrementally updating resources of a production server is a
rather frightening proposition. Parallel testing is always a better way to
go - bring up any changes in a parallel system for testing and then do an
atomic "swap" - redirection of requests from the old server to the new
On 30 Oct 2014 14:49, "Shawn Heisey" wrote:
> In order to see a gain in performance from multiple shards per server,
> the server must have a lot of CPUs and the query rate must be fairly
> low. If the query rate is high, then all the CPUs will be busy just
> handling simultaneous queries, so pu
On 30 Oct 2014 23:46, "Erick Erickson" wrote:
>
> This configuration deals with all
> the replication, NRT processing, self-repair when nodes go up and
> down and all that, but since there's no second trip to get the docs
> from shards your query performance won't be affected.
More or less.. Vagu
Hello Greg,
Consul and Zookeeper are quite similar in their offering with respect
to what SolrCloud needs. Service discovery, watches on distributed
cluster state, updates of configuration could all be handled through
Consul. Plus, Consul does offer built-in capabilities for
multi-datacenter sc
ok, thanks for the answer.
best regards,
Elisabeth
2014-10-31 22:04 GMT+01:00 Jack Krupansky :
> No, but it is a reasonable request, as a global default, a
> collection-specific default, a request-specific default, and on an
> individual fuzzy term.
>
> -- Jack Krupansky
>
> -Original Messag
14 matches
Mail list logo
