Cluster a의 일부 인덱스를 신규장비 cluster b로 이동시키는 방법

Elastic In Your Native Tongue 한국어 질문 및 토론
1

5대(10개 노드)로 구성된 cluster a에 A,B,C index를 새롭게 구성한 cluster b(5대 10개 노드)로 이동시킬 수 있는 전략은 어떤것이 있을까요?
include ip 옵션을 사용해서 index의 이동은 원하는 node에 배치 할 수 있을것 같은데
index 이동이 완료 된 후, cluster a에 포함된 5대를 cluster b로 재구성하는(따로 분리 해내는) 일이 쉽지 않네요
cluster b의 node들에 index이동이 끝나면, cluster b로 사용 할 5대를 shutdown 한 다음, discovery.zen.ping.unicast.hosts를 cluster b의 정보만으로 변경하여 재기동하면 cluster a의 이름으로 기동이 될것 같아서요..
dynamic하게 cluster 이름을 변경 할 수도 없고(물리적인 폴더명을 바꾸지 않는 한..)
정리하면,
제가 생각한 순서는 다음과 같습니다.
0. index allocation을 none으로 한다.

  1. cluster a에 include ip를 index별로 설정한다.(cluster b node들이 합류해도 이동되지 않도록)
  2. 신규 5대를 cluster a에 합류 시킨다.(신규 5대는 cluster a의 ip를 포함하여 discovery.zen.ping.unicast.hosts 이 되어있음)
  3. index allocation을 all로 설정 하고, index allocation include ip를 이용해 신규 5대의 node로 index를 이동시킨다.
  4. 신규 5대를 shutdown 한다.
  5. 신규 5대의 discovery.zen.ping.unicast.hosts 설정에서 cluster a의 설정을 제거한다.
  6. 신규 5대를 기동한다.(이때 cluster name이 cluster a로 된 문제가 있을듯)
    혹시 좋은 아이디어 있으시면 도움 부탁드립니다.
2

제가 아는 공식 문서가 있어서요.

참고 되셨으면 합니다.

Restoring to a different clusteredit
The information stored in a snapshot is not tied to a particular cluster or a cluster name. Therefore it’s possible to restore a snapshot made from one cluster into another cluster. All that is required is registering the repository containing the snapshot in the new cluster and starting the restore process. The new cluster doesn’t have to have the same size or topology. However, the version of the new cluster should be the same or newer (only 1 major version newer) than the cluster that was used to create the snapshot. For example, you can restore a 1.x snapshot to a 2.x cluster, but not a 1.x snapshot to a 5.x cluster.

If the new cluster has a smaller size additional considerations should be made. First of all it’s necessary to make sure that new cluster have enough capacity to store all indices in the snapshot. It’s possible to change indices settings during restore to reduce the number of replicas, which can help with restoring snapshots into smaller cluster. It’s also possible to select only subset of the indices using the indices parameter. Prior to version 1.5.0 elasticsearch didn’t check restored persistent settings making it possible to accidentally restore an incompatible discovery.zen.minimum_master_nodes setting, and as a result disable a smaller cluster until the required number of master eligible nodes is added. Starting with version 1.5.0 incompatible settings are ignored.

If indices in the original cluster were assigned to particular nodes using shard allocation filtering, the same rules will be enforced in the new cluster. Therefore if the new cluster doesn’t contain nodes with appropriate attributes that a restored index can be allocated on, such index will not be successfully restored unless these index allocation settings are changed during restore operation.