Since v0.2.7
Solr Clouds are complex distributed systems, and thus require a more delicate and informed approach to rolling updates.
If the Managed
update strategy is specified in the Solr Cloud CRD, then the Solr Operator will take control over deleting SolrCloud pods when they need to be updated.
The operator will find all pods that have not been updated yet and choose the next set of pods to delete for an update, given the following workflow.
The logic goes as follows:
maxPodsUnavailable
option, because these pods have not even started the Solr process.ready
pods.maxPodsUnavailable
, then subtracting the number of updated pods that are unavailable as well as the number of not-yet-started, out-of-date pods that were updated in a previous step. This check makes sure that any pods taken down during this step do not violate the maxPodsUnavailable
constraint.The pods are sorted by the following criteria, in the given order. If any two pods on a criterion, then the next criteria (in the following order) is used to sort them.
In this context the pods sorted highest are the first chosen to be updated, the pods sorted lowest will be selected last.
Loop over the sorted pods, until the number of pods selected to be updated has reached the maximum. This maximum is calculated by taking the given, or default, maxPodsUnavailable
and subtracting the number of updated pods that are unavailable or have yet to be re-created.
maxPodsUnavailable
to a value you are comfortable with.live
, the pod is chosen to be updated.down
or recovery_failed
state, the pod is chosen to be updated.maxShardReplicasUnavailable
, then the pod can be updated. Once a pod with replicas has been chosen to be updated, the replicas hosted in that pod are then considered unavailable for the rest of the selection logic.maxShardReplicasUnavailable
calculation will take these replicas into account, as a starting point.maxShardReplicasUnavailable
calculation.