|
@@ -23,39 +23,43 @@ documented individually.
|
|
|
[float]
|
|
|
=== Development vs. production mode
|
|
|
|
|
|
-By default, Elasticsearch binds to `localhost` for <<modules-http,HTTP>>
|
|
|
-and <<modules-transport,transport (internal)>> communication. This is
|
|
|
-fine for downloading and playing with Elasticsearch, and everyday
|
|
|
-development but it's useless for production systems. To form a cluster,
|
|
|
-Elasticsearch instances must be reachable via transport communication so
|
|
|
-they must bind transport to an external interface. Thus, we consider an
|
|
|
-Elasticsearch instance to be in development mode if it does not bind
|
|
|
-transport to an external interface (the default), and is otherwise in
|
|
|
-production mode if it does bind transport to an external interface.
|
|
|
-
|
|
|
-Note that HTTP can be configured independently of transport via
|
|
|
-<<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>;
|
|
|
-this can be useful for configuring a single instance to be reachable via
|
|
|
-HTTP for testing purposes without triggering production mode.
|
|
|
-
|
|
|
-We recognize that some users need to bind transport to an external
|
|
|
-interface for testing their usage of the transport client. For this
|
|
|
-situation, we provide the discovery type `single-node` (configure it by
|
|
|
-setting `discovery.type` to `single-node`); in this situation, a node
|
|
|
-will elect itself master and will not form a cluster with any other
|
|
|
-node.
|
|
|
-
|
|
|
-If you are running a single node in production, it is possible to evade
|
|
|
-the bootstrap checks (either by not binding transport to an external
|
|
|
-interface, or by binding transport to an external interface and setting
|
|
|
-the discovery type to `single-node`). For this situation, you can force
|
|
|
-execution of the bootstrap checks by setting the system property
|
|
|
-`es.enforce.bootstrap.checks` to `true` (set this in <<jvm-options>>, or
|
|
|
-by adding `-Des.enforce.bootstrap.checks=true` to the environment
|
|
|
-variable `ES_JAVA_OPTS`). We strongly encourage you to do this if you
|
|
|
-are in this specific situation. This system property can be used to
|
|
|
-force execution of the bootstrap checks independent of the node
|
|
|
-configuration.
|
|
|
+By default, Elasticsearch binds to `localhost` for <<modules-http,HTTP>> and
|
|
|
+<<modules-transport,transport (internal)>> communication. This is fine for
|
|
|
+downloading and playing with Elasticsearch, and everyday development but it's
|
|
|
+useless for production systems. To join a cluster, an Elasticsearch node must be
|
|
|
+reachable via transport communication. To join a cluster over an external
|
|
|
+network interface, a node must bind transport to an external interface and not
|
|
|
+be using <<single-node-discovery,single-node discovery>>. Thus, we consider an
|
|
|
+Elasticsearch node to be in development mode if it can not form a cluster with
|
|
|
+another machine over an external network interface, and is otherwise in
|
|
|
+production mode if it can join a cluster over an external interface.
|
|
|
+
|
|
|
+Note that HTTP and transport can be configured independently via
|
|
|
+<<modules-http,`http.host`>> and <<modules-transport,`transport.host`>>; this
|
|
|
+can be useful for configuring a single node to be reachable via HTTP for testing
|
|
|
+purposes without triggering production mode.
|
|
|
+
|
|
|
+[[single-node-discovery]]
|
|
|
+[float]
|
|
|
+=== Single-node discovery
|
|
|
+We recognize that some users need to bind transport to an external interface for
|
|
|
+testing their usage of the transport client. For this situation, we provide the
|
|
|
+discovery type `single-node` (configure it by setting `discovery.type` to
|
|
|
+`single-node`); in this situation, a node will elect itself master and will not
|
|
|
+join a cluster with any other node.
|
|
|
+
|
|
|
+
|
|
|
+[float]
|
|
|
+=== Forcing the bootstrap checks
|
|
|
+If you are running a single node in production, it is possible to evade the
|
|
|
+bootstrap checks (either by not binding transport to an external interface, or
|
|
|
+by binding transport to an external interface and setting the discovery type to
|
|
|
+`single-node`). For this situation, you can force execution of the bootstrap
|
|
|
+checks by setting the system property `es.enforce.bootstrap.checks` to `true`
|
|
|
+(set this in <<jvm-options>>, or by adding `-Des.enforce.bootstrap.checks=true`
|
|
|
+to the environment variable `ES_JAVA_OPTS`). We strongly encourage you to do
|
|
|
+this if you are in this specific situation. This system property can be used to
|
|
|
+force execution of the bootstrap checks independent of the node configuration.
|
|
|
|
|
|
=== Heap size check
|
|
|
|