RollingStrategyConfig

edit

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

Properties

edit
allow_inline_resize (boolean)
Whether we allow changing the capacity of instances (default false). This is currently implemented by stopping, re-creating then starting the affected instance on its associated allocator when performing the changes. NOTES: This requires a round-trip through the allocation infrastructure of the active constructor, as it has to reserve the target capacity without over-committing
group_by (string)
Specifies the grouping attribute to use when rolling several instances. Instances that share the same value for the provided attribute key are rolled together as a unit. Examples that make sense to use are '__all__' (roll all instances as a single unit), 'logical_zone_name' (roll instances by zone), '__name__' (roll one instance at a time, the default if not specified). Note that '__all__' is required when performing a major version upgrade
shard_init_wait_time (integer as int64)
The time to wait for shards that show no progress of initializing before rolling the next group (default: 10 minutes)
skip_synced_flush (boolean)
Whether to skip attempting to do a synced flush on the filesystem of the container (default: false), which is less safe but may be required if the container is unhealthy

Example

edit
{
   "allow_inline_resize" : true,
   "group_by" : "string",
   "shard_init_wait_time" : 0,
   "skip_synced_flush" : true
}