> For the complete documentation index, see [llms.txt](https://mariadb.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mariadb.com/docs/release-notes/enterprise-operator/26.06/26.06.4.md).

# MariaDB Enterprise Kubernetes Operator 26.06.4

MariaDB Enterprise Operator 26.06.4 is a maintenance release of MariaDB Enterprise Operator, released on 2026-10-06

**Release date**: 6 October 2026

MariaDB Enterprise Kubernetes Operator 26.06.4 is a maintenance release for the 26.06 series. It hardens semi-synchronous replication in replication topologies managed by MaxScale, during failovers, switchovers and rolling updates, fixes how MaxScale servers are kept in sync with the `MariaDB` and `MaxScale` resources, and addresses CVEs in the operator and exporter images.

If you are updating from a previous version, **please follow the** [**UPDATE GUIDE**](https://mariadb.com/docs/tools/mariadb-enterprise-operator/updates/update-26.06.4) to ensure a safe transition.

### Changelog

* **K8SDKR-324**: The operator no longer sends `protocol` when patching existing MaxScale servers. Changing `spec.servers` of a `MaxScale` resource, for example after scaling out the `MariaDB`, failed with `The parameter 'protocol' cannot be modified at runtime.` in a loop, so the `MaxScale` never became ready and the `MariaDB` rolling update never started.
* **K8SDKR-322**: Multiple fixes in the replication reconciliation of `MariaDB` resources managed by MaxScale:
  * The current primary is now resolved from the MaxScale API instead of the `MaxScale` status, which lags behind a switchover or failover. The operator no longer reconfigures the primary just promoted by MaxScale as a replica of the old one.
  * [`rpl_semi_sync_master_enabled`](https://mariadb.com/docs/server/ha-and-performance/standard-replication/semisynchronous-replication#rpl_semi_sync_master_enabled) is now enabled in the current primary as soon as at least one replica is connected to it, before the other Pods are configured. A Pod that is unreachable, such as an old primary left `Pending` after a failover, no longer leaves the new primary accepting writes without semi-synchronous replication.
* **K8SDKR-327**: During a rolling update, semi-synchronous replication is now enabled in the current primary before each Pod is deleted. The primary promoted by the MaxScale switchover no longer accepts writes without semi-synchronous replication while the old primary is being rolled, including in clusters with a single replica.
* **K8SDKR-328**: MaxScale servers are now re-patched when an attribute that does not come from `spec.servers` changes: `MASTER_CONNECT_RETRY`, derived from [`replication.replica.connectionRetrySeconds`](https://mariadb.com/docs/tools/mariadb-enterprise-operator/topologies/high-availability/replication#configuration) in the `MariaDB`, and the TLS settings derived from `spec.tls` in the `MaxScale`.
* **K8SDKR-325**: Fixed CVEs in the operator and exporter images. They are now built with Go `1.27.1` and `golang.org/x/crypto` `v0.57.0`, on a refreshed UBI 9.8 base image. The MariaDB and MaxScale Prometheus exporters have been updated to `1.2.1` with the same changes.
* **K8SDKR-323**: The K8SDKR-322 fixes also apply when the primary loses the connection to its replicas in a replication topology managed by MaxScale. The operator acts on the primary reported by the MaxScale API, and enables semi-synchronous replication in it as soon as one replica reconnects.

### Platform and component versions

The current release has been tested with the following versions:

| Platform/Component        | Version  |
| ------------------------- | -------- |
| Kubernetes                | 1.36     |
| OpenShift                 | 4.20     |
| MariaDB Enterprise Server | 11.8.8-5 |
| MaxScale                  | 25.10.4  |

<sub>*This page is: Copyright © 2026 MariaDB. All rights reserved.*</sub>

{% @marketo/form formid="4316" formId="4316" %}