You are looking at the documentation of a prior release. To read the documentation of the latest release, please
visit here.
New to KubeDB? Please start here.
This guide will give an overview on how KubeDB Enterprise operator reconfigures MySQL
.
KubeDB
concepts:The following diagram shows how KubeDB Enterprise operator reconfigures MySQL
database components. Open the image in a new tab to see the enlarged version.
The Reconfiguring MySQL process consists of the following steps:
At first, a user creates a MySQL
Custom Resource (CR).
KubeDB
Community operator watches the MySQL
CR.
When the operator finds a MySQL
CR, it creates required number of StatefulSets
and related necessary stuff like secrets, services, etc.
Then, in order to reconfigure the MySQL
standalone or cluster the user creates a MySQLOpsRequest
CR with desired information.
KubeDB
Enterprise operator watches the MySQLOpsRequest
CR.
When it finds a MySQLOpsRequest
CR, it halts the MySQL
object which is referred from the MySQLOpsRequest
. So, the KubeDB
Community operator doesn’t perform any operations on the MySQL
object during the reconfiguring process.
Then the KubeDB
Enterprise operator will replace the existing configuration with the new configuration provided or merge the new configuration with the existing configuration according to the MySQLOpsRequest
CR.
Then the KubeDB
Enterprise operator will restart the related StatefulSet Pods so that they restart with the new configuration defined in the MySQLOpsRequest
CR.
After the successful reconfiguring of the MySQL
, the KubeDB
Enterprise operator resumes the MySQL
object so that the KubeDB
Community operator resumes its usual operations.
In the next docs, we are going to show a step by step guide on reconfiguring MySQL database components using MySQLOpsRequest
CRD.