Changes in NDB Operator 8.2.0-1.2.0 (2023-10-25, Innovation Release)

This is MySQL NDB Operator 8.2.0-1.2.0, an Innovation release of NDB Operator, a Kubernetes Operator for MySQL NDB Cluster.

For additional downloads and the source of MySQL NDB Operator visit https://dev.mysql.com/downloads/ndb-operator/ and https://github.com/mysql/mysql-ndb-operator.

For more information on MySQL NDB Operator see the online documentation at https://dev.mysql.com/doc/ndb-operator/en/.

For more information about MySQL NDB Cluster, see https://dev.mysql.com/doc/refman/8.2/en/mysql-cluster.html.

• Functionality Added or Changed

• Bugs Fixed

Functionality Added or Changed

• NDB Operator now supports NDB Cluster transparent data encryption (TDE). This work includes the following changes:

  • Added a new TDESecretName field to NdbClusterSpec, allowing the user to specify the name of a secret holding the required encryption key or password. If a value is provided for this field, NDB Operator enables TDE and uses the password stored in the secret as the file system password for all data nodes in the cluster. (If no such value is provided, TDE is not enabled.)

  • EncryptedFileSystem is now updated in the cluster config.ini file when TDE is enabled.

  • ndbmtdStatefulSet now sends --filesystem-password and --initial to the ndbd container when TDESecretName is set.

  • NDB Operator now compares the TDE state of the current cluster configuration with that of a new incoming NdbClusterSpec, to ensure that config.ini generation includes TDE configuration information and that approproiate rolling restarts are performed by any cluster nodes affected by a configuration change.

  (WL #15904)

Bugs Fixed

• This fix addresses the following issues:

  1. The check_version() shell script function, responsible for checking the MySQL Cluster version and whether it meets the minimum required, contained errors.

  2. The Java SDK included in the Docker file mysql-cluster-builder:ol8 was updated to version 17.

     NDB Operator 8.2.0 requires Java 17 or later.

  (Bug #35691446)

• NDB Operator did not detect initiation script failures, causing it to start the mysqld container even when there were errors in the init container.

• In a multi-node Kubernetes environment, an issue arose when the user opted to use an image secret to retrieve the NDB Operator image while deploying it, leading to a situation where one or more pods encounter failures due to image pull failures. This problem emerged because all NDB Cluster pods spawned by NDB Operator include an initialization container that necessitates the presence of the ndb-operator image.

  The root of the issue was that the necessary image pull secret was not included in the pod specifications. Consequently, when a pod was instantiated on any node other than the one where NDB Operator was deployed, it lacked the essential image pull secret, which meant that, since the required image could not be fetched from the repository, pod initialization could not take place.