gateway.asciidoc 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475
  1. [[modules-gateway]]
  2. == Gateway
  3. The gateway module allows one to store the state of the cluster meta
  4. data across full cluster restarts. The cluster meta data mainly holds
  5. all the indices created with their respective (index level) settings and
  6. explicit type mappings.
  7. Each time the cluster meta data changes (for example, when an index is
  8. added or deleted), those changes will be persisted using the gateway.
  9. When the cluster first starts up, the state will be read from the
  10. gateway and applied.
  11. The gateway set on the node level will automatically control the index
  12. gateway that will be used. For example, if the `fs` gateway is used,
  13. then automatically, each index created on the node will also use its own
  14. respective index level `fs` gateway. In this case, if an index should
  15. not persist its state, it should be explicitly set to `none` (which is
  16. the only other value it can be set to).
  17. The default gateway used is the
  18. <<modules-gateway-local,local>> gateway.
  19. [float]
  20. [[recover-after]]
  21. === Recovery After Nodes / Time
  22. In many cases, the actual cluster meta data should only be recovered
  23. after specific nodes have started in the cluster, or a timeout has
  24. passed. This is handy when restarting the cluster, and each node local
  25. index storage still exists to be reused and not recovered from the
  26. gateway (which reduces the time it takes to recover from the gateway).
  27. The `gateway.recover_after_nodes` setting (which accepts a number)
  28. controls after how many data and master eligible nodes within the
  29. cluster recovery will start. The `gateway.recover_after_data_nodes` and
  30. `gateway.recover_after_master_nodes` setting work in a similar fashion,
  31. except they consider only the number of data nodes and only the number
  32. of master nodes respectively. The `gateway.recover_after_time` setting
  33. (which accepts a time value) sets the time to wait till recovery happens
  34. once all `gateway.recover_after...nodes` conditions are met.
  35. The `gateway.expected_nodes` allows to set how many data and master
  36. eligible nodes are expected to be in the cluster, and once met, the
  37. `recover_after_time` is ignored and recovery starts. The
  38. `gateway.expected_data_nodes` and `gateway.expected_master_nodes`
  39. settings are also supported. For example setting:
  40. [source,js]
  41. --------------------------------------------------
  42. gateway:
  43. recover_after_nodes: 1
  44. recover_after_time: 5m
  45. expected_nodes: 2
  46. --------------------------------------------------
  47. In an expected 2 nodes cluster will cause recovery to start 5 minutes
  48. after the first node is up, but once there are 2 nodes in the cluster,
  49. recovery will begin immediately (without waiting).
  50. Note, once the meta data has been recovered from the gateway (which
  51. indices to create, mappings and so on), then this setting is no longer
  52. effective until the next full restart of the cluster.
  53. Operations are blocked while the cluster meta data has not been
  54. recovered in order not to mix with the actual cluster meta data that
  55. will be recovered once the settings has been reached.
  56. include::gateway/local.asciidoc[]
  57. include::gateway/fs.asciidoc[]
  58. include::gateway/hadoop.asciidoc[]
  59. include::gateway/s3.asciidoc[]