reroute.asciidoc 2.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
  1. [[cluster-reroute]]
  2. == Cluster Reroute
  3. The reroute command allows to explicitly execute a cluster reroute
  4. allocation command including specific commands. For example, a shard can
  5. be moved from one node to another explicitly, an allocation can be
  6. canceled, or an unassigned shard can be explicitly allocated on a
  7. specific node.
  8. Here is a short example of how a simple reroute API call:
  9. [source,js]
  10. --------------------------------------------------
  11. curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
  12. "commands" : [ {
  13. "move" :
  14. {
  15. "index" : "test", "shard" : 0,
  16. "from_node" : "node1", "to_node" : "node2"
  17. }
  18. },
  19. {
  20. "allocate" : {
  21. "index" : "test", "shard" : 1, "node" : "node3"
  22. }
  23. }
  24. ]
  25. }'
  26. --------------------------------------------------
  27. An important aspect to remember is the fact that once when an allocation
  28. occurs, the cluster will aim at re-balancing its state back to an even
  29. state. For example, if the allocation includes moving a shard from
  30. `node1` to `node2`, in an `even` state, then another shard will be moved
  31. from `node2` to `node1` to even things out.
  32. The cluster can be set to disable allocations, which means that only the
  33. explicitly allocations will be performed. Obviously, only once all
  34. commands has been applied, the cluster will aim to be re-balance its
  35. state.
  36. Another option is to run the commands in `dry_run` (as a URI flag, or in
  37. the request body). This will cause the commands to apply to the current
  38. cluster state, and return the resulting cluster after the commands (and
  39. re-balancing) has been applied.
  40. If the `explain` parameter is specified, a detailed explanation of why the
  41. commands could or could not be executed is returned.
  42. The commands supported are:
  43. `move`::
  44. Move a started shard from one node to another node. Accepts
  45. `index` and `shard` for index name and shard number, `from_node` for the
  46. node to move the shard `from`, and `to_node` for the node to move the
  47. shard to.
  48. `cancel`::
  49. Cancel allocation of a shard (or recovery). Accepts `index`
  50. and `shard` for index name and shard number, and `node` for the node to
  51. cancel the shard allocation on. It also accepts `allow_primary` flag to
  52. explicitly specify that it is allowed to cancel allocation for a primary
  53. shard. This can be used to force resynchronization of existing replicas
  54. from the primary shard by cancelling them and allowing them to be
  55. reinitialized through the standard reallocation process.
  56. `allocate`::
  57. Allocate an unassigned shard to a node. Accepts the
  58. `index` and `shard` for index name and shard number, and `node` to
  59. allocate the shard to. It also accepts `allow_primary` flag to
  60. explicitly specify that it is allowed to explicitly allocate a primary
  61. shard (might result in data loss).