Changes in MySQL Operator for Kubernetes 9.7.0-2.2.8 (2026-04-24)

Functionality Added or Changed

• MySQL Operator for Kubernetes can now be installed in different operator topologies. A default installation remains a global, non-standalone operator that watches all Kubernetes namespaces. A scoped installation can watch an explicit set of Kubernetes namespaces, enabling multiple MySQL Operator installations in the same Kubernetes cluster when their watched namespace sets do not overlap.

  The following changes were made:

  • A standalone operator mode was added. In this mode MySQL Operator for Kubernetes runs without Kopf peering objects and is limited to one replica. Standalone installations can be global or scoped, using the same namespace selection rules as non-standalone installations.

  • The Helm chart for MySQL Operator for Kubernetes now supports deployment.name, deployment.namespaces, deployment.standalone, and deployment.strategy. The chart also supports operator Deployment metadata, pod metadata, resource requests and limits, affinity, and node selector settings under the deployment value.

  • Operator topology is persisted on the operator Deployment by using the mysql.oracle.com/operator-topology annotation. The persisted topology is validated during startup and rejects conflicting operator installations, overlapping watched namespace sets, and unsupported topology changes.

  • Helm installations now validate operator topology before creating or upgrading the operator. A global operator overlaps all namespaces, scoped operators must use disjoint namespace sets, and topology values are immutable after installation.

  • Raw manifest installations now include explicit operator topology environment variables, including OPERATOR_NAMESPACES and OPERATOR_STANDALONE. The raw manifest default remains a global, non-standalone operator.

  • Scoped, non-standalone Helm installations create namespaced Kopf peering objects for the watched namespaces. Global, non-standalone installations use a cluster-scoped Kopf peering object. Standalone installations do not create peering objects.

  • MySQL Operator for Kubernetes startup now reconciles existing watched InnoDBCluster objects after operator restart and emits restart events for watched clusters

  (WL #17280)