1 | ##################### ElasticSearch Configuration Example ##################### |
---|
2 | |
---|
3 | # This file contains an overview of various configuration settings, |
---|
4 | # targeted at operations staff. Application developers should |
---|
5 | # consult the guide at <http://elasticsearch.org/guide>. |
---|
6 | # |
---|
7 | # The installation procedure is covered at |
---|
8 | # <http://elasticsearch.org/guide/reference/setup/installation.html>. |
---|
9 | # |
---|
10 | # ElasticSearch comes with reasonable defaults for most settings, |
---|
11 | # so you can try it out without bothering with configuration. |
---|
12 | # |
---|
13 | # Most of the time, these defaults are just fine for running a production |
---|
14 | # cluster. If you're fine-tuning your cluster, or wondering about the |
---|
15 | # effect of certain configuration option, please _do ask_ on the |
---|
16 | # mailing list or IRC channel [http://elasticsearch.org/community]. |
---|
17 | |
---|
18 | # Any element in the configuration can be replaced with environment variables |
---|
19 | # by placing them in ${...} notation. For example: |
---|
20 | # |
---|
21 | # node.rack: ${RACK_ENV_VAR} |
---|
22 | |
---|
23 | # See <http://elasticsearch.org/guide/reference/setup/configuration.html> |
---|
24 | # for information on supported formats and syntax for the configuration file. |
---|
25 | |
---|
26 | |
---|
27 | ################################### Cluster ################################### |
---|
28 | |
---|
29 | # Cluster name identifies your cluster for auto-discovery. If you're running |
---|
30 | # multiple clusters on the same network, make sure you're using unique names. |
---|
31 | # |
---|
32 | cluster.name: rft |
---|
33 | |
---|
34 | |
---|
35 | #################################### Node ##################################### |
---|
36 | |
---|
37 | # Node names are generated dynamically on startup, so you're relieved |
---|
38 | # from configuring them manually. You can tie this node to a specific name: |
---|
39 | # |
---|
40 | # node.name: "Franz Kafka" |
---|
41 | |
---|
42 | # Every node can be configured to allow or deny being eligible as the master, |
---|
43 | # and to allow or deny to store the data. |
---|
44 | # |
---|
45 | # Allow this node to be eligible as a master node (enabled by default): |
---|
46 | # |
---|
47 | # node.master: true |
---|
48 | # |
---|
49 | # Allow this node to store data (enabled by default): |
---|
50 | # |
---|
51 | # node.data: true |
---|
52 | |
---|
53 | # You can exploit these settings to design advanced cluster topologies. |
---|
54 | # |
---|
55 | # 1. You want this node to never become a master node, only to hold data. |
---|
56 | # This will be the "workhorse" of your cluster. |
---|
57 | # |
---|
58 | # node.master: false |
---|
59 | # node.data: true |
---|
60 | # |
---|
61 | # 2. You want this node to only serve as a master: to not store any data and |
---|
62 | # to have free resources. This will be the "coordinator" of your cluster. |
---|
63 | # |
---|
64 | # node.master: true |
---|
65 | # node.data: false |
---|
66 | # |
---|
67 | # 3. You want this node to be neither master nor data node, but |
---|
68 | # to act as a "search load balancer" (fetching data from nodes, |
---|
69 | # aggregating results, etc.) |
---|
70 | # |
---|
71 | # node.master: false |
---|
72 | # node.data: false |
---|
73 | |
---|
74 | # Use the Cluster Health API [http://localhost:9200/_cluster/health], the |
---|
75 | # Node Info API [http://localhost:9200/_cluster/nodes] or GUI tools |
---|
76 | # such as <http://github.com/lukas-vlcek/bigdesk> and |
---|
77 | # <http://mobz.github.com/elasticsearch-head> to inspect the cluster state. |
---|
78 | |
---|
79 | # A node can have generic attributes associated with it, which can later be used |
---|
80 | # for customized shard allocation filtering, or allocation awareness. An attribute |
---|
81 | # is a simple key value pair, similar to node.key: value, here is an example: |
---|
82 | # |
---|
83 | # node.rack: rack314 |
---|
84 | |
---|
85 | # By default, multiple nodes are allowed to start from the same installation location |
---|
86 | # to disable it, set the following: |
---|
87 | # node.max_local_storage_nodes: 1 |
---|
88 | |
---|
89 | |
---|
90 | #################################### Index #################################### |
---|
91 | |
---|
92 | # You can set a number of options (such as shard/replica options, mapping |
---|
93 | # or analyzer definitions, translog settings, ...) for indices globally, |
---|
94 | # in this file. |
---|
95 | # |
---|
96 | # Note, that it makes more sense to configure index settings specifically for |
---|
97 | # a certain index, either when creating it or by using the index templates API. |
---|
98 | # |
---|
99 | # See <http://elasticsearch.org/guide/reference/index-modules/> and |
---|
100 | # <http://elasticsearch.org/guide/reference/api/admin-indices-create-index.html> |
---|
101 | # for more information. |
---|
102 | |
---|
103 | # Set the number of shards (splits) of an index (5 by default): |
---|
104 | # |
---|
105 | # index.number_of_shards: 5 |
---|
106 | |
---|
107 | # Set the number of replicas (additional copies) of an index (1 by default): |
---|
108 | # |
---|
109 | # index.number_of_replicas: 1 |
---|
110 | |
---|
111 | # Note, that for development on a local machine, with small indices, it usually |
---|
112 | # makes sense to "disable" the distributed features: |
---|
113 | # |
---|
114 | # index.number_of_shards: 1 |
---|
115 | # index.number_of_replicas: 0 |
---|
116 | |
---|
117 | # These settings directly affect the performance of index and search operations |
---|
118 | # in your cluster. Assuming you have enough machines to hold shards and |
---|
119 | # replicas, the rule of thumb is: |
---|
120 | # |
---|
121 | # 1. Having more *shards* enhances the _indexing_ performance and allows to |
---|
122 | # _distribute_ a big index across machines. |
---|
123 | # 2. Having more *replicas* enhances the _search_ performance and improves the |
---|
124 | # cluster _availability_. |
---|
125 | # |
---|
126 | # The "number_of_shards" is a one-time setting for an index. |
---|
127 | # |
---|
128 | # The "number_of_replicas" can be increased or decreased anytime, |
---|
129 | # by using the Index Update Settings API. |
---|
130 | # |
---|
131 | # ElasticSearch takes care about load balancing, relocating, gathering the |
---|
132 | # results from nodes, etc. Experiment with different settings to fine-tune |
---|
133 | # your setup. |
---|
134 | |
---|
135 | # Use the Index Status API (<http://localhost:9200/A/_status>) to inspect |
---|
136 | # the index status. |
---|
137 | |
---|
138 | |
---|
139 | #################################### Paths #################################### |
---|
140 | |
---|
141 | # Path to directory containing configuration (this file and logging.yml): |
---|
142 | # |
---|
143 | # path.conf: /path/to/conf |
---|
144 | |
---|
145 | # Path to directory where to store index data allocated for this node. |
---|
146 | # |
---|
147 | # path.data: /path/to/data |
---|
148 | # |
---|
149 | # Can optionally include more than one location, causing data to be striped across |
---|
150 | # the locations (Ã la RAID 0) on a file level, favouring locations with most free |
---|
151 | # space on creation. For example: |
---|
152 | # |
---|
153 | # path.data: /path/to/data1,/path/to/data2 |
---|
154 | |
---|
155 | # Path to temporary files: |
---|
156 | # |
---|
157 | # path.work: /path/to/work |
---|
158 | |
---|
159 | # Path to log files: |
---|
160 | # |
---|
161 | # path.logs: /path/to/logs |
---|
162 | |
---|
163 | # Path to where plugins are installed: |
---|
164 | # |
---|
165 | # path.plugins: /path/to/plugins |
---|
166 | |
---|
167 | |
---|
168 | #################################### Plugin ################################### |
---|
169 | |
---|
170 | # If a plugin listed here is not installed for current node, the node will not start. |
---|
171 | # |
---|
172 | # plugin.mandatory: mapper-attachments,lang-groovy |
---|
173 | |
---|
174 | |
---|
175 | ################################### Memory #################################### |
---|
176 | |
---|
177 | # ElasticSearch performs poorly when JVM starts swapping: you should ensure that |
---|
178 | # it _never_ swaps. |
---|
179 | # |
---|
180 | # Set this property to true to lock the memory: |
---|
181 | # |
---|
182 | # bootstrap.mlockall: true |
---|
183 | |
---|
184 | # Make sure that the ES_MIN_MEM and ES_MAX_MEM environment variables are set |
---|
185 | # to the same value, and that the machine has enough memory to allocate |
---|
186 | # for ElasticSearch, leaving enough memory for the operating system itself. |
---|
187 | # |
---|
188 | # You should also make sure that the ElasticSearch process is allowed to lock |
---|
189 | # the memory, eg. by using `ulimit -l unlimited`. |
---|
190 | |
---|
191 | |
---|
192 | ############################## Network And HTTP ############################### |
---|
193 | |
---|
194 | # ElasticSearch, by default, binds itself to the 0.0.0.0 address, and listens |
---|
195 | # on port [9200-9300] for HTTP traffic and on port [9300-9400] for node-to-node |
---|
196 | # communication. (the range means that if the port is busy, it will automatically |
---|
197 | # try the next port). |
---|
198 | |
---|
199 | # Set the bind address specifically (IPv4 or IPv6): |
---|
200 | # |
---|
201 | network.bind_host: localhost |
---|
202 | |
---|
203 | # Set the address other nodes will use to communicate with this node. If not |
---|
204 | # set, it is automatically derived. It must point to an actual IP address. |
---|
205 | # |
---|
206 | # network.publish_host: 192.168.0.1 |
---|
207 | |
---|
208 | # Set both 'bind_host' and 'publish_host': |
---|
209 | # |
---|
210 | network.host: localhost |
---|
211 | |
---|
212 | # Set a custom port for the node to node communication (9300 by default): |
---|
213 | # |
---|
214 | # transport.tcp.port: 9300 |
---|
215 | |
---|
216 | # Enable compression for all communication between nodes (disabled by default): |
---|
217 | # |
---|
218 | # transport.tcp.compress: true |
---|
219 | |
---|
220 | # Set a custom port to listen for HTTP traffic: |
---|
221 | # |
---|
222 | # http.port: 9200 |
---|
223 | |
---|
224 | # Set a custom allowed content length: |
---|
225 | # |
---|
226 | # http.max_content_length: 100mb |
---|
227 | |
---|
228 | # Disable HTTP completely: |
---|
229 | # |
---|
230 | # http.enabled: false |
---|
231 | |
---|
232 | |
---|
233 | ################################### Gateway ################################### |
---|
234 | |
---|
235 | # The gateway allows for persisting the cluster state between full cluster |
---|
236 | # restarts. Every change to the state (such as adding an index) will be stored |
---|
237 | # in the gateway, and when the cluster starts up for the first time, |
---|
238 | # it will read its state from the gateway. |
---|
239 | |
---|
240 | # There are several types of gateway implementations. For more information, |
---|
241 | # see <http://elasticsearch.org/guide/reference/modules/gateway>. |
---|
242 | |
---|
243 | # The default gateway type is the "local" gateway (recommended): |
---|
244 | # |
---|
245 | # gateway.type: local |
---|
246 | |
---|
247 | # Settings below control how and when to start the initial recovery process on |
---|
248 | # a full cluster restart (to reuse as much local data as possible when using shared |
---|
249 | # gateway). |
---|
250 | |
---|
251 | # Allow recovery process after N nodes in a cluster are up: |
---|
252 | # |
---|
253 | # gateway.recover_after_nodes: 1 |
---|
254 | |
---|
255 | # Set the timeout to initiate the recovery process, once the N nodes |
---|
256 | # from previous setting are up (accepts time value): |
---|
257 | # |
---|
258 | # gateway.recover_after_time: 5m |
---|
259 | |
---|
260 | # Set how many nodes are expected in this cluster. Once these N nodes |
---|
261 | # are up (and recover_after_nodes is met), begin recovery process immediately |
---|
262 | # (without waiting for recover_after_time to expire): |
---|
263 | # |
---|
264 | # gateway.expected_nodes: 2 |
---|
265 | |
---|
266 | |
---|
267 | ############################# Recovery Throttling ############################# |
---|
268 | |
---|
269 | # These settings allow to control the process of shards allocation between |
---|
270 | # nodes during initial recovery, replica allocation, rebalancing, |
---|
271 | # or when adding and removing nodes. |
---|
272 | |
---|
273 | # Set the number of concurrent recoveries happening on a node: |
---|
274 | # |
---|
275 | # 1. During the initial recovery |
---|
276 | # |
---|
277 | # cluster.routing.allocation.node_initial_primaries_recoveries: 4 |
---|
278 | # |
---|
279 | # 2. During adding/removing nodes, rebalancing, etc |
---|
280 | # |
---|
281 | # cluster.routing.allocation.node_concurrent_recoveries: 2 |
---|
282 | |
---|
283 | # Set to throttle throughput when recovering (eg. 100mb, by default unlimited): |
---|
284 | # |
---|
285 | # indices.recovery.max_size_per_sec: 0 |
---|
286 | |
---|
287 | # Set to limit the number of open concurrent streams when |
---|
288 | # recovering a shard from a peer: |
---|
289 | # |
---|
290 | # indices.recovery.concurrent_streams: 5 |
---|
291 | |
---|
292 | |
---|
293 | ################################## Discovery ################################## |
---|
294 | |
---|
295 | # Discovery infrastructure ensures nodes can be found within a cluster |
---|
296 | # and master node is elected. Multicast discovery is the default. |
---|
297 | |
---|
298 | # Set to ensure a node sees N other master eligible nodes to be considered |
---|
299 | # operational within the cluster. Set this option to a higher value (2-4) |
---|
300 | # for large clusters (>3 nodes): |
---|
301 | # |
---|
302 | # discovery.zen.minimum_master_nodes: 1 |
---|
303 | |
---|
304 | # Set the time to wait for ping responses from other nodes when discovering. |
---|
305 | # Set this option to a higher value on a slow or congested network |
---|
306 | # to minimize discovery failures: |
---|
307 | # |
---|
308 | # discovery.zen.ping.timeout: 3s |
---|
309 | |
---|
310 | # See <http://elasticsearch.org/guide/reference/modules/discovery/zen.html> |
---|
311 | # for more information. |
---|
312 | |
---|
313 | # Unicast discovery allows to explicitly control which nodes will be used |
---|
314 | # to discover the cluster. It can be used when multicast is not present, |
---|
315 | # or to restrict the cluster communication-wise. |
---|
316 | # |
---|
317 | # 1. Disable multicast discovery (enabled by default): |
---|
318 | # |
---|
319 | # discovery.zen.ping.multicast.enabled: false |
---|
320 | # |
---|
321 | # 2. Configure an initial list of master nodes in the cluster |
---|
322 | # to perform discovery when new nodes (master or data) are started: |
---|
323 | # |
---|
324 | # discovery.zen.ping.unicast.hosts: ["host1", "host2:port", "host3[portX-portY]"] |
---|
325 | |
---|
326 | # EC2 discovery allows to use AWS EC2 API in order to perform discovery. |
---|
327 | # |
---|
328 | # You have to install the cloud-aws plugin for enabling the EC2 discovery. |
---|
329 | # |
---|
330 | # See <http://elasticsearch.org/guide/reference/modules/discovery/ec2.html> |
---|
331 | # for more information. |
---|
332 | # |
---|
333 | # See <http://elasticsearch.org/tutorials/2011/08/22/elasticsearch-on-ec2.html> |
---|
334 | # for a step-by-step tutorial. |
---|
335 | |
---|
336 | |
---|
337 | ################################## Slow Log ################################## |
---|
338 | |
---|
339 | # Shard level query and fetch threshold logging. |
---|
340 | |
---|
341 | #index.search.slowlog.level: TRACE |
---|
342 | #index.search.slowlog.threshold.query.warn: 10s |
---|
343 | #index.search.slowlog.threshold.query.info: 5s |
---|
344 | #index.search.slowlog.threshold.query.debug: 2s |
---|
345 | #index.search.slowlog.threshold.query.trace: 500ms |
---|
346 | |
---|
347 | #index.search.slowlog.threshold.fetch.warn: 1s |
---|
348 | #index.search.slowlog.threshold.fetch.info: 800ms |
---|
349 | #index.search.slowlog.threshold.fetch.debug: 500ms |
---|
350 | #index.search.slowlog.threshold.fetch.trace: 200ms |
---|
351 | |
---|
352 | ################################## GC Logging ################################ |
---|
353 | |
---|
354 | #monitor.jvm.gc.ParNew.warn: 1000ms |
---|
355 | #monitor.jvm.gc.ParNew.info: 700ms |
---|
356 | #monitor.jvm.gc.ParNew.debug: 400ms |
---|
357 | |
---|
358 | #monitor.jvm.gc.ConcurrentMarkSweep.warn: 10s |
---|
359 | #monitor.jvm.gc.ConcurrentMarkSweep.info: 5s |
---|
360 | #monitor.jvm.gc.ConcurrentMarkSweep.debug: 2s |
---|