MariaDB Enterprise Kubernetes Operator 26.06.1
MariaDB Enterprise Operator 26.06.1 is a maintenance release of MariaDB Enterprise Operator, released on 2026-07-30
Release date: 30 July 2026
MariaDB Enterprise Kubernetes Operator 26.06.1 is a maintenance release for the 26.06 series. It focuses on the reliability of replication topologies fronted by MaxScale: the operator no longer purges binary logs while configuring replicas, MaxScale gains an ephemeral runtime configuration mode that removes configuration conflicts when upgrading between MaxScale versions, and long-running backups no longer cause MariaDB Pods to be restarted. Refer to the sections below for details on each change.
If you're updating from a previous version, please follow the UPDATE GUIDE to ensure a safe transition.
Binary logs and GTID positions preserved during replica configuration
The operator no longer runs RESET MASTER; when a MaxScale resource is attached to the MariaDB resource through spec.maxScaleRef.
Previously, RESET MASTER; was executed as part of replica configuration, which happens whenever a replica Pod is restarted and whenever a primary is demoted to replica as part of a switchover. RESET MASTER; purges the binary logs and clears gtid_binlog_pos, which has two harmful side effects in a MaxScale-managed topology:
Because RESET MASTER; is no longer executed during replica configuration, binary logs and GTID positions on the replica are preserved. This is safe because MaxScale coordinates switchovers in this topology and performs its own GTID handling under controlled conditions. RESET MASTER; is not invoked by MaxScale or by the operator during primary configuration either.
Ephemeral MaxScale configuration
MariaDB Enterprise Kubernetes Operator 26.06.1 introduces a new config.ephemeral field on the MaxScale resource:
config.ephemeral
boolean
false
Indicates whether the MaxScale runtime configuration is ephemeral. When enabled, MaxScale does not persist or load runtime configuration changes from disk, avoiding potential conflicts with config sync. To keep a restarting MaxScale Pod self-sufficient, the operator renders config sync as well as the servers and monitor into the default configuration, so the Pod can bootstrap config sync and pull the runtime configuration (services, listeners, ...) from the cluster on its own. This only takes effect when MaxScale's high availability is enabled.
By default, MaxScale persists its runtime configuration under /var/lib/maxscale and loads it again on startup. When upgrading to a new MaxScale version, that persisted copy was written by the previous version and may contain parameters the new version no longer recognizes, causing the new Pods to fail to apply it on startup. Ephemeral configuration removes the conflict at its source: with no local copy of the configuration to load when the MaxScale Pods restart, the conflict cannot occur.
To make this safe during restarts and rolling upgrades, the static configuration rendered by the operator is self-bootstrapping: it includes the config sync settings plus minimal [server] and [monitor] sections. A restarting Pod bootstraps config sync on its own and pulls the rest of the runtime configuration (services, listeners, ...) from the cluster, without depending on the operator being available at that moment. The remaining parameters are patched by the operator through the MaxScale API.
As a result, changes to the servers and the monitor — for example, scaling MariaDB out or editing monitor settings — no longer trigger a rolling update of MaxScale. They are applied live through the MaxScale API.
Enabling config.ephemeral is the recommended way to upgrade MaxScale between major versions. Refer to the MaxScale documentation for more details.
No MariaDB Pod restarts during long-running backups
When taking long-running backups, the MariaDB liveness probe could fail because mariadb-backup stops the replica SQL thread, leading to the MariaDB Pod being restarted mid-backup.
The liveness probe now recognizes this case explicitly — Slave_SQL_Running: No together with Last_SQL_Errno == 0 — and treats it as an administrative stop rather than a failure, so MariaDB Pods are no longer restarted while a backup is running. Replication errors are still detected and reported as before.
The data-plane agent logs the detection:
This fix lives in the data-plane, so the data-plane must be updated along with the operator for it to take effect. See the update guide.
Platform and component versions
The current release has been tested with the following versions:
Kubernetes
1.36
OpenShift
4.18.6
MariaDB Enterprise Server
11.8.8-5
MaxScale
25.10.3
This page is: Copyright © 2026 MariaDB. All rights reserved.
Last updated
Was this helpful?