Re: Can i elastic search as my primary store?

Depends on how valuable your data is. I wouldn't say Elasticsearch is quite there yet to be considered a reliable primary data store, even with 1.4. Lots of work to be done on hardening replication. On Sat, Oct 25, 2014 at 4:08 AM, Nikolas Everett wrote: > I'd wait for 1.4 before considering it

Re: partial index replication causes data loss?

d by garbage collection with large > data sets, and a server becoming unresponsive for too long. (perhaps the > cluster kicks out the unresponsive node, or a supervisor restarts the > application) > > On Thursday, October 23, 2014 12:59:00 PM UTC-7, Shikhar Bhushan wrote: >> &g

Re: partial index replication causes data loss?

Very interesting. The default 'write consistency level' with Elasticsearch is QUORUM, i.e. verify a quorum of replicas for a shard are available before processing a write for it. In this case you were just left with 1 replica, C, and a write happened. So you would think that it should not go throug

Re: bulk indexing - optimal refresh_interval

e if you are inserting a lot of data, you will have a >>> massive hit at the end when you need to index, as opposed to smaller ones >>> along the way. >>> >>> Regards, >>> Mark Walkom >>> >>> Infrastructure Engineer >>> Campa

bulk indexing - optimal refresh_interval

The 1.3.0 release notes state: >- Increase the refresh_interval > > > if >you are doing heavy bulk indexing, or you are happy with your search >results being refreshed less f

Re: Elastic Search and consistency

On Fri, Jun 13, 2014 at 12:11 PM, shikhar wrote: > I take this back, I understand the ES model better now. So although the > write-consistency-level check is only applied before the write is about > to be issued, with sync replication the client can only get an ack if it > suc

Re: Elastic Search and consistency

On Thu, Jun 12, 2014 at 8:52 PM, shikhar wrote: > ES currently does not seem to provide any guarantee that an acknowledged > write (from the caller's perspective) succeeded on a quorum of replicas. I take this back, I understand the ES model better now. So although the write-consis

Re: Elastic Search and consistency

On Thu, Jun 12, 2014 at 8:42 PM, joergpra...@gmail.com < joergpra...@gmail.com> wrote: > 1.1 Not sure what you mean "after the quorum check". Write consistency is > a model where ES makes sure there are enough recipients (nodes) before > writes are executed. consistency=quorum fails if you have to

Re: Elastic Search and consistency

g would tempt one to believe, but there doesn't seem to be evidence to support the guarantees that implies. Cheers, Shikhar On Sat, Apr 5, 2014 at 12:06 AM, Anand Somani wrote: > Hi, > > We are trying to use ES as a system of record, so I trying to understand > its consistency

Re: quorum write + sync replication: guarantees

On Thu, Jun 12, 2014 at 6:09 PM, shikhar wrote: > It seems like the only time we look at how many replicas the write > succeeded on is prior to issuing the write > <https://github.com/elasticsearch/elasticsearch/blob/20278f491ac3e62be30544a862344a9b8b1f647c/src/main/java/org/elastics

quorum write + sync replication: guarantees

write is issued. it succeeds on primary but not on a quorum of all the shards (primary shard & replicas). will this result in a failure response? If yes, I would love to see some corroboration! Cheers, Shikhar [1] related issue: definition of quorum in ES code is off. github issue <https

Re: ANN: new elasticsearch discovery plugin - eskka

a itself does not have any tests at the application-level which I intend to fix. I'd like to think the use of actors -- the main ones being Master<https://github.com/shikhar/eskka/blob/master/src/main/scala/eskka/Master.scala> , Follower<https://github.com/shikhar/eskka/blob/master/

Re: ANN: new elasticsearch discovery plugin - eskka

On Thu, May 8, 2014 at 1:02 PM, shikhar wrote: > Worth noting that besides being initial contact points for when the > cluster is starting up, with eskka they are also used for resolving > partitions. Given this requirement, you would ideally have 3 or more > specified. It is per

Re: ANN: new elasticsearch discovery plugin - eskka

s for when the cluster is starting up, with eskka they are also used for resolving partitions. Given this requirement, you would ideally have 3 or more specified. It is perfectly ok to have all of your nodes listed, if you know their addresses before startup. https://github.com/shikhar/eskka#configur

Re: ANN: new elasticsearch discovery plugin - eskka

Just released 0.1.1 <https://github.com/shikhar/eskka/releases/tag/v0.1.1> This version is working well in my manual testing. Automated testing is on the roadmap... On Mon, May 5, 2014 at 10:49 AM, shikhar wrote: > See README <https://github.com/shikhar/eskka/blob/release-0

ANN: new elasticsearch discovery plugin - eskka

See README <https://github.com/shikhar/eskka/blob/release-0.1/README.md> I'd love to have feedback on this first release! -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving