There are changes with 1.0.0 - http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-cluster.html cluster.routing.allocation.disable_allocation has been deprecated for cluster.routing.allocation.enable
Regards, Mark Walkom Infrastructure Engineer Campaign Monitor email: [email protected] web: www.campaignmonitor.com On 14 February 2014 03:54, Tony Su <[email protected]> wrote: > Hi Mo, > I've been experimenting with those settings on 1.0. > The "disable shard allocation" setting doesn't seem to do anything for me. > Shards still re-allocate. Which might explain why I didn't see a > pre-configured setting in elasticsearch.yml so I created my own setting. > > But, I did find the "gateway" settings effective. > After some experimentation, I decided to back off from setting > "gateway.recover_after_nodes" from 5 to 4 on my 5 node cluster. Although > requiring all nodes to be functional worked the first few times, if one > node didn't join I didn't want my cluster to just sit there waiting for the > node to eventually join or for me to intervene with manual action since > there is no visual indication of the progress cluster nodes joining and if > there is an issue it can't resolve on its own(except indirectly by using > es-hq and that is only <if> you happen to be pointing to a node that is > successfully joined). Since it seems that shard re-allocation cannot be > avoided entirely, I felt the time saved by allowing the cluster to start > without all its nodes out-weighed trying to maximize all primary copies of > the shards should be available. > > Tony > > > On Wednesday, February 12, 2014 2:27:21 PM UTC-8, Mo wrote: > >> >> >> On Wed, Feb 12, 2014 at 1:58 PM, [email protected] >> <[email protected]>wrote: >> >>> I use replica shard level 1, and always use latest ES version. I never >>> had data loss, and that is also due to the fact I have access to dedicated >>> real servers in our DC just a few meters away, and there are no servers at >>> cloud server farms with unknown and unstable network environment. >>> >>> >> Do you have special settings for "disable shard allocation" and "gateway" >> modules? Would you be able to share those settings? There are numerous >> number of settings and I am trying to understand which ones make most sense? >> >> How are you taking backups of data today? I believe new incremental >> backup feature is slated in 1.0. >> >> Are there other best practices you can share would be helpful. >> >>> I do always update when the ES releases notes tell the update is >>> recommended. This must be taken serious! Lucene had some nasty wipe all >>> bugs for example, and no software is free from bugs. >>> >>> Updates within minor versions can take place in minutes by taking the >>> whole cluster down and start again - but this means downtime, if that >>> cluster is the only cluster. I tuned the nodes to recover fast. For my >>> requirements, downtime of 15 min is acceptable. >>> >>> For production, you always need a staging environment. Test your updates >>> before applying to production systems, with the same data and the same >>> configuration. >>> >>> Do not let ES take care of your data alone. Make backups so you can fall >>> back to a configuration that is known to work. Or make sure you can reindex >>> instantly from the data source. >>> >>> I have also a round robin technique that works without downtime. Any >>> operator can pull a power cable from a single server in the DC but ES will >>> keep on running. So I can update or service the hardware (e.g. adding RAM). >>> >>> For updating OS and updating JVM the situation is a bit more challenging >>> because a rolling update is not possible, but I can set up two clusters for >>> this. >>> >>> Jörg >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "elasticsearch" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/elasticsearch/CAKdsXoEQLWzi9yYQUhb8s2jOpswWA >>> UDHH0DxZz9e19mfBfL9aw%40mail.gmail.com. >>> >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/e5a631c1-f776-48e7-b7f3-631ab02b7cf4%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAEM624bg30MvKHUuyY%3DR4vpiwyDgED%3DDuhjdmj16_fCc5FkWtA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
