RollingStrategyConfig

edit

Performs inline, rolling configuration changes that mutate existing containers. TIP: This is the fastest way to update a plan, but can fail for complex plan changes, such as topology changes. Also, this is less safe for configuration changes that leave a cluster in a non running state. NOTE: When you perform a major version upgrade, and 'group_by' is set to '*all*';, rolling is required.

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, in seconds, 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
}