Describes various options that affect how we will perform a plan change. Only one of these can be specified at a time. The default is to let the system decide on the best method (currently it will always be 'grow_and_shrink' unless manually specified)
- A simple strategy that creates new instances with the new plan, migrates data across from the old instances, and then shuts down the old instances - it is safer than 'rolling' and ensures single node availability during a plan change, but can be a lot slower on larger clusters
- Allows for performing many configuration changes in-line in a rolling manner, mutating existing containers.It is the fastest way of updating a plan, but may fail for more complex plan changes (eg topology changes) and is less safe for eg configuration changes that can leave a cluster in a non-running state. Note that rolling (with 'group_by' set to '__all__') is required when performing a major version upgrade
- A simple strategy that creates new instances with the new plan one by one, migrates data from one node that needs to be removed and proceeds to the next node to add/remove. It allows minimizing the amount of spare capacity needed.