This guide illustrates, step by step, how to update to 25.8.0 from previous versions.

• Uninstall you current mariadb-enterprise-operator for preventing conflicts:

helm uninstall mariadb-enterprise-operator

Alternatively, you may only downscale and delete the webhook configurations:

kubectl scale deployment mariadb-enterprise-operator --replicas=0
kubectl scale deployment mariadb-enterprise-operator-webhook --replicas=0
kubectl delete validatingwebhookconfiguration mariadb-enterprise-operator-webhook
kubectl delete mutatingwebhookconfiguration mariadb-enterprise-operator-webhook

• Upgrade mariadb-enterprise-operator-crds to 25.8.0:

• The Galera data-plane must be updated to the 25.8.0 version.

If you want the operator to automatically update the data-plane (i.e. init and agent containers), you can set updateStrategy.autoUpdateDataPlane=true in your MariaDB resources:

Alternatively, you can also do this manually:

• Upgrade mariadb-enterprise-operator to 25.8.0:

• If you previously decided to downscale the operator, make sure you upscale it back:

• If you previously set updateStratety.autoUpdateDataPlane=true, you may consider reverting the changes once the upgrades have finished:

By leveraging the automation provided by MariaDB Enterprise Kubernetes Operator, you can declaratively manage large fleets of databases using CRs. This also covers day two operations, such as upgrades, which can be risky when rolling out updates to thousands of instances simultaneously.

To mitigate this, and to give you full control on the upgrade process, you are able to choose between multiple update strategies described in the following sections.

Update strategies

In order to provide you with flexibility for updating MariaDB reliably, this operator supports multiple update strategies:

• : Roll out replica Pods one by one, wait for each of them to become ready, and then proceed with the primary Pod.

• : Utilize the rolling update strategy from Kubernetes.

• : Updates are performed manually by deleting Pods.

• : Pause updates.

Configuration

The update strategy can be configured in the updateStrategy field of the MariaDB resource:

It defaults to ReplicasFirstPrimaryLast if not provided.

Trigger updates

Updates are not limited to updating the image field in the MariaDB resource, an update will be triggered whenever any field of the Pod template is changed. This translates into making changes to MariaDB fields that map directly or indirectly to the Pod template, for instance, the CPU and memory resources:

Once the update is triggered, the operator manages it differently based on the selected update strategy.

ReplicasFirstPrimaryLast

This role-aware update strategy consists in rolling out the replica Pods one by one first, waiting for each of them become ready (i.e. readiness probe passed), and then proceed with the primary Pod. This is the default update strategy, as it can potentially meet various reliability requirements and minimize the risks associated with updates:

• Write operations won't be affected until all the replica Pods have been rolled out. If something goes wrong in the update, such as an update to an incompatible MariaDB version, this is detected early when the replicas are being rolled out and the update operation will be paused at that point.

• Read operations impact is minimized by only rolling one replica Pod at a time.

• Waiting for every Pod to be synced minimizes the impact in the clustering protocols and the network.

RollingUpdate

This strategy leverages the rolling update strategy from the , which, unlike , does not take into account the role of the Pods(primary or replica). Instead, it rolls out the Pods one by one, from the highest to the lowest StatefulSet index.

You are able to pass extra parameters to this strategy via the rollingUpdate object:

OnDelete

This strategy aims to provide a method to update MariaDB resources manually by allowing the user to restart the Pods individually. This way, the user has full control over the update process and can decide which Pods are rolled out at any given time.

Whenever an , the MariaDB will be marked as pending to update:

From this point, you are able to delete the Pods to trigger the update, which will result the MariaDB marked as updating:

Once all the Pods have been rolled out, the MariaDB resource will be back to a ready state:

Never

The operator will not perform updates on the StatefulSet whenever this update strategy is configured. This could be useful in multiple scenarios:

• Progressive fleet upgrades: If you're managing large fleets of databases, you likely prefer to roll out updates progressively rather than simultaneously across all instances.

• Operator upgrades: When upgrading the operator, changes to the StatefulSet or the Pod template may occur from one version to another, which could trigger a rolling update of your MariaDB instances.

Data-plane updates

Highly available topologies rely on that run alongside MariaDB to enable the remote management of the database instances. These containers use the mariadb-enterprise-operator image, which can be automatically updated by the operator based on its image version:

By default, updateStrategy.autoUpdateDataPlane is false, which means that no automatic upgrades will be performed, but you can opt-in/opt-out from this feature at any point in time by updating this field. For instance, you may want to selectively enable updateStrategy.autoUpdateDataPlane in a subset of your MariaDB instances after the operator has been upgraded to a newer version, and then disable it once the upgrades are completed.

It is important to note that this feature is fully compatible with the strategy: no upgrades will happen when updateStrategy.autoUpdateDataPlane=true and updateStrategy.type=Never.

This guide illustrates, step by step, how to update to 25.10.2 from previous versions.

• The Galera data-plane must be updated to the 25.10.2 version. You must set updateStrategy.autoUpdateDataPlane=true in your MariaDB resources before updating the operator. Then, once updated, the operator will also be updating the data-plane based on its version:

apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
  name: mariadb-galera
spec:
  updateStrategy:
+   autoUpdateDataPlane: true

• Once set, you may proceed to update the operator. If you are using Helm:

Upgrade the mariadb-enterprise-operator-crds helm chart to 25.10.2:

Upgrade the mariadb-enterprise-operator helm chart to 25.10.2:

As part of the 25.10 LTS release, we have introduced support for LTS versions. Refer to the for sticking to LTS versions.

• If you are on OpenShift:

If you are on the stable channel using installPlanApproval=Automatic in your Subscription object, then the operator will be automatically updated. If you use installPlanApproval=Manual, you should have a new InstallPlan which needs to be approved to update the operator:

As part of the 25.10 LTS release, we have introduced new . Consider switching to the stable-v25.10 if you are willing to stay in the 25.10.x version:

• Consider reverting updateStrategy.autoUpdateDataPlane back to false in your MariaDB object to avoid unexpected updates: