Multi-Cluster Replication, FIPS Mode, and More with MariaDB Enterprise Kubernetes Operator 26.06

What is the MariaDB Enterprise Kubernetes Operator?

The MariaDB Enterprise Kubernetes Operator makes it easier to run and manage MariaDB databases in Kubernetes. It automates day-to-day work such as deployment, scaling, backups, recovery, security configuration, and upgrades, reducing the manual effort of running MariaDB databases on Kubernetes. For more information, see the MariaDB Enterprise Kubernetes Operator page.

What’s new in MariaDB Kubernetes Operator 26.06

There are two versions of the Kubernetes Operator, namely the enterprise version and the open source MariaDB Community Operator. This table specifies the breakdown of enhancements:

Feature	Availability	Edition	Description
Multi-cluster replication	Tech Preview	Community + Enterprise	Cross-site disaster recovery and blue-green upgrades, managed natively by the Operator
FIPS mode	GA	Enterprise	FIPS 140-3-compliant cryptography for MariaDB Server, MaxScale, and Operator connections
Automatic primary switchover	GA	Enterprise	Keeps the database available through Kubernetes node upgrades
Maintenance mode	GA	Community + Enterprise	Cordon, connection draining, and read-only controls for planned maintenance
Root password rotation	GA	Community + Enterprise	Safe secret-driven rotation that fits GitOps workflows
Minimal and standard Images	GA	Enterprise	A smaller-attack-surface option alongside the full-featured image

Multi-Cluster Replication 

As a Tech Preview, this feature is available to evaluate now, with production support planned for a future release.

Within a single Kubernetes cluster, the Operator already protects your database against node and pod failures. But if you lose the whole cluster, or the site hosting it, the database goes down with it. Recovering from that means keeping a second, independent copy of the database somewhere else, in sync and ready to take over. Setting that up outside the Operator is risky: the Operator doesn’t know about the remote replica’s configuration and can quietly break replication during reconciliation.

This release introduces native multi-cluster replication, which brings the cross-cluster relationship under the Operator’s management. It builds on top of existing replication and Galera topologies, adding an inter-cluster replication layer where one cluster acts as the primary and the others as replicas—each maintaining its own internal HA mechanism. The Operator manages the full topology lifecycle: provisioning clusters, bootstrapping replicas from physical backups, configuring replication connections, and performing cluster-level switchover.

Beyond multi-site database deployment, the same mechanism supports blue-green upgrades: set up replication between MariaDB clusters within a single Kubernetes cluster, upgrade the idle one in the background, and switch over when it’s ready instead of upgrading the live database in place.

Why it matters: For business-critical workloads, a multi-site topology is what protects against a whole-site failure — an outage whose cost grows with every hour of recovery. Making it native to the Operator makes cross-site replication robust and easier to operate, and de-risks recovery when it matters most. 

FIPS Mode (Enterprise only)

For deployments that must meet FIPS 140-3 requirements, including those working toward FedRAMP, the enterprise version adds a FIPS mode to the Operator.

There are no separate FIPS images to manage. The Operator, MariaDB Server, and MaxScale images are already based on Red Hat UBI and include FIPS-validated cryptographic modules, so the same images run in both standard and FIPS deployments. The runtime flag simply switches the Operator into FIPS-approved cryptography.

When FIPS mode is on:

• The Operator’s own connections, to the Kubernetes API server, MariaDB Server, and MaxScale, use FIPS-compliant encryption through the Go Cryptographic Module v1.0.0 (NIST CMVP certificate #5247).
• For MariaDB Server and MaxScale, the Operator automatically activates Red Hat’s FIPS-validated OpenSSL provider (NIST CMVP certificate #4857) inside containers, with no additional configuration required.

Why it Matters: For federal agencies, defense contractors, and the regulated industries that serve them, FIPS 140-3 is a baseline requirement — proof that sensitive data is protected with validated cryptographic modules. The Operator’s FIPS mode is built on those validated modules, so you can run MariaDB on Kubernetes in these environments and satisfy the cryptography requirements behind frameworks like FedRAMP.

Automatic Primary Switchover (Enterprise only)

When you upgrade a Kubernetes cluster, you usually can’t control the order in which nodes are updated. Before a node is updated, Kubernetes drains it — evicting its pods so they can be rescheduled elsewhere. If the node holding your MariaDB primary is drained, its pod is evicted along with everything else on it. When the primary becomes unavailable, MaxScale initiates a failover to another replica. While this happens relatively quickly, there’s still a short interruption with the risk of losing in-flight transactions.

To avoid database interruption on Kubernetes node drain, someone has to notice the primary is there and trigger a switchover while the old primary is still running, so the handover is orderly and no writes are lost. On a large fleet, doing this by hand for every upgrade isn’t practical, and on managed Kubernetes services (e.g., EKS, GKE, AKS), it isn’t an option at all.

The MariaDB Enterprise Kubernetes Operator now handles this automatically. When the node hosting the primary is drained, the Operator triggers a MaxScale switchover to a healthy replica during the pod’s graceful shutdown. If the switchover can’t complete in time, MaxScale falls back to a failover. This lets node and cluster upgrades run without anyone tracking down primaries or sequencing node drains by hand.

Why it matters: Kubernetes version updates are routine maintenance, and on managed services you sometimes don’t even have control over when they happen. Handling the primary switchover automatically keeps that routine maintenance from becoming database downtime, however large the fleet.

Maintenance Mode

Sometimes you need to take a database out of service in a controlled way. It could be before promoting a replica, while debugging an issue, or for any task that requires isolating the cluster from application traffic. Doing that cleanly means stopping new connections, letting existing ones finish, and preventing writes, rather than pulling the database out from under your applications.

This release adds a maintenance mode with three controls, which can be enabled individually or together:

• Cordon — stops new connections from reaching the database
• Connection Draining — ends long-running connections gracefully after a grace period you set
• Read-only — blocks writes while still allowing reads

Also, it’s the underlying mechanism behind multi-cluster switchover, holding writes on the primary while a replica catches up.

Why it matters: Planned database maintenance shouldn’t look like an outage to an application. Maintenance mode lets you quiet the database gracefully — stop new work, let in-flight work finish, and hold writes — so migrations, debugging, and switchovers happen in a controlled way.

Root Password Rotation

Rotating privileged credentials like the root password is a common security and compliance requirement, but on a running cluster managed by the Operator it’s more than a one-line change and requires knowing how to do it safely.

With this release, you rotate the root password simply by updating its Kubernetes Secret. The Operator applies the new password inside MariaDB and propagates it to every component that uses it. To keep the change safe, the Operator waits until the cluster is in a stable, healthy state, so in-progress backups or scaling operations are never interrupted. Because it’s driven through the Secret, it fits naturally with GitOps workflows and external secret managers.

Why it matters: Rotating privileged credentials is a baseline security control — making it a Secret-driven operation lets teams safely rotate it on the schedule their policies require.

Minimal and Standard Images (Enterprise only)

This new version introduces two flavors of hardened container images for MariaDB Enterprise Server and MaxScale:

• Standard images include the full set of features and components.
• Minimal images contain only the essential packages needed to run MariaDB Server or MaxScale, reducing both image size and attack surface.

Which one to use depends on your operational needs: standard images are the safer default when you’re unsure which optional components you rely on; minimal images suit environments where you’ve already confirmed the reduced package set covers everything you use, and where a smaller attack surface is a priority (for example, regulated workloads).

Why it matters: Offering both minimal and standard hardened images lets you match your container footprint to your risk profile—shrinking the attack surface and image size for security-sensitive deployments without forcing teams who depend on optional components to give up functionality. 

Availability and Compliance

Release 26.06 pushes the MariaDB Enterprise Kubernetes Operator further into business-critical and regulated territory: multi-cluster replication and automatic switchover keep the database available through site failures and routine node upgrades, while FIPS mode, safe credential rotation, and minimal images address the security and compliance requirements those environments carry.

Ready to evaluate the MariaDB Enterprise Kubernetes Operator 26.06?

See the Multi-Cluster Replication Tech Preview documentation, or get started with an Enterprise Platform Plus subscription.

FAQ