I am researching avenues to improve blue-green upgrade of my ES cluster. Presently, I copy data by taking a snapshot of the index, then restoring it in the new cluster, and I would like to move away from this approach. My hope was that replication mechanism could be used for it, and I could accomplish what I need with this sequence:
- The 3 nodes for my new cluster are started, and configured to join with the old 3-node cluster. Replication begins among the 6 nodes.
- Once all shards have been replicated, I can bring the 3 new nodes down, reconfigure them to form an independent cluster and start them up.
- The index from the old cluster is fully available on the new cluster at this point.
It did not work like this. It does not appear that discovery (I use zen unicast) depends on the configured IP addresses alone, in fact, what I expected to run as a cluster of 3 new nodes, promptly included the 3 old nodes, a total of 6, and after some time, the cluster changed to only include 3 new nodes. Is zen discovery augmented by some transient state on old master, or perhaps last known good cluster state gets stored in the index?
A less problematic issue is that I would like to assign unique names to my ES clusters. The index will not show if I change cluster name on the new nodes after replication is complete. In the local filesystem I have directories for each cluster name that the node was a part of, but moving index directory from one cluster directory to another does not help.
Had anyone attempted to implement replication copy of an index?
Thanks -Alex