2016-04-08 06:18:02 -04:00
|
|
|
[[breaking_50_fs]]
|
|
|
|
|
=== Filesystem related changes
|
|
|
|
|
|
|
|
|
|
Only a subset of index files were open with `mmap` on Elasticsearch 2.x. As of
|
|
|
|
|
Elasticsearch 5.0, all index files will be open with `mmap` on 64-bit systems.
|
|
|
|
|
While this may increase the amount of virtual memory used by Elasticsearch,
|
|
|
|
|
there is nothing to worry about since this is only address space consumption
|
|
|
|
|
and the actual memory usage of Elasticsearch will stay similar to what it was
|
|
|
|
|
in 2.x. See http://blog.thetaphi.de/2012/07/use-lucenes-mmapdirectory-on-64bit.html
|
|
|
|
|
for more information.
|
2016-05-23 18:19:56 -04:00
|
|
|
|
|
|
|
|
=== Path to data on disk
|
|
|
|
|
|
|
|
|
|
In prior versions of Elasticsearch, the `path.data` directory included a folder
|
|
|
|
|
for the cluster name, so that data was in a folder such as
|
|
|
|
|
`$DATA_DIR/$CLUSTER_NAME/nodes/$nodeOrdinal`. In 5.0 the cluster name as a
|
|
|
|
|
directory is deprecated. Data will now be stored in
|
|
|
|
|
`$DATA_DIR/nodes/$nodeOrdinal` if there is no existing data. Upon startup,
|
|
|
|
|
Elasticsearch will check to see if the cluster folder exists and has data, and
|
|
|
|
|
will read from it if necessary. In Elasticsearch 6.0 this backwards-compatible
|
|
|
|
|
behavior will be removed.
|
|
|
|
|
|
|
|
|
|
If you are using a multi-cluster setup with both instances of Elasticsearch
|
|
|
|
|
pointing to the same data path, you will need to add the cluster name to the
|
|
|
|
|
data path so that different clusters do not overwrite data.
|
