RollingStrategyConfig
editRollingStrategyConfig
editPerforms 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
asint64
) - 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 }