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.

MySQLOpsRequest

What is MySQLOpsRequest

MySQLOpsRequest is a Kubernetes Custom Resource Definitions (CRD). It provides declarative configuration for MySQL administrative operations like database version upgrading, horizontal scaling, vertical scaling, etc. in a Kubernetes native way.

MySQLOpsRequest CRD Specifications

Like any official Kubernetes resource, a MySQLOpsRequest has TypeMeta, ObjectMeta, Spec and Status sections.

Here, some sample MySQLOpsRequest CRs for different administrative operations is given below,

Sample MySQLOpsRequest for upgrading database:

apiVersion: ops.kubedb.com/v1alpha1
kind: MySQLOpsRequest
metadata:
  name: my-ops-upgrade
  namespace: demo
spec:
  databaseRef:
    name: my-group
  type: UpdateVersion
  upgrade:
    targetVersion: 8.0.29
status:
  conditions:
  - lastTransitionTime: "2022-06-16T13:52:58Z"
    message: The controller has scaled/upgraded the MySQL successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Sample MySQLOpsRequest for horizontal scaling:

apiVersion: ops.kubedb.com/v1alpha1
kind: MySQLOpsRequest
metadata:
  name: myops
  namespace: demo
spec:
  databaseRef:
    name: my-group
  type: HorizontalScaling  
  horizontalScaling:
    member: 3
status:
  conditions:
  - lastTransitionTime: "2022-06-16T13:52:58Z"
    message: The controller has scaled/upgraded the MySQL successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Sample MySQLOpsRequest for vertical scaling:

apiVersion: ops.kubedb.com/v1alpha1
kind: MySQLOpsRequest
metadata:
  name: myops
  namespace: demo
spec:
  databaseRef:
    name: my-group
  type: VerticalScaling  
  verticalScaling:
    mysql:
      requests:
        memory: "1200Mi"
        cpu: "0.7"
      limits:
        memory: "1200Mi"
        cpu: "0.7"
status:
  conditions:
  - lastTransitionTime: "2022-06-11T09:59:05Z"
    message: The controller has scaled/upgraded the MySQL successfully
    observedGeneration: 3
    reason: OpsRequestSuccessful
    status: "True"
    type: Successful
  observedGeneration: 3
  phase: Successful

Here, we are going to describe the various sections of a MySQLOpsRequest cr.

MySQLOpsRequest Spec

A MySQLOpsRequest object has the following fields in the spec section.

spec.databaseRef

spec.databaseRef is a required field that point to the MySQL object where the administrative operations will be applied. This field consists of the following sub-field:

  • spec.databaseRef.name : specifies the name of the MySQL object.

spec.type

spec.type specifies the kind of operation that will be applied to the database. Currently, the following types of operations are allowed in MySQLOpsRequest.

  • Upgrade
  • HorizontalScaling
  • VerticalScaling
  • volumeExpansion
  • Restart
  • Reconfigure
  • ReconfigureTLS

You can perform only one type of operation on a single MySQLOpsRequest CR. For example, if you want to upgrade your database and scale up its replica then you have to create two separate MySQLOpsRequest. At first, you have to create a MySQLOpsRequest for upgrading. Once it is completed, then you can create another MySQLOpsRequest for scaling. You should not create two MySQLOpsRequest simultaneously.

spec.upgrade

If you want to upgrade your MySQL version, you have to specify the spec.upgrade section that specifies the desired version information. This field consists of the following sub-field:

  • spec.upgrade.targetVersion refers to a MySQLVersion CR that contains the MySQL version information where you want to upgrade.

You can only upgrade between MySQL versions. KubeDB does not support downgrade for MySQL.

spec.horizontalScaling

If you want to scale-up or scale-down your MySQL cluster, you have to specify spec.horizontalScaling section. This field consists of the following sub-field:

  • spec.horizontalScaling.member indicates the desired number of members for your MySQL cluster after scaling. For example, if your cluster currently has 4 members and you want to add additional 2 members then you have to specify 6 in spec.horizontalScaling.member field. Similarly, if you want to remove one member from the cluster, you have to specify 3 in spec.horizontalScaling.member field.

spec.verticalScaling

spec.verticalScaling is a required field specifying the information of MySQL resources like cpu, memory etc that will be scaled. This field consists of the following sub-fields:

  • spec.verticalScaling.mysql indicates the MySQL server resources. It has the below structure:
requests:
  memory: "200Mi"
  cpu: "0.1"
limits:
  memory: "300Mi"
  cpu: "0.2"

Here, when you specify the resource request for MySQL container, the scheduler uses this information to decide which node to place the container of the Pod on and when you specify a resource limit for MySQL container, the kubelet enforces those limits so that the running container is not allowed to use more of that resource than the limit you set. you can found more details from here

  • spec.verticalScaling.exporter indicates the exporter container resources. It has the same structure as spec.verticalScaling.mysql and you can scale the resource the same way as mysql container.

You can increase/decrease resources for both mysql container and exporter container on a single MySQLOpsRequest CR.

MySQLOpsRequest Status

.status describes the current state and progress of the MySQLOpsRequest operation. It has the following fields:

status.phase

status.phase indicates the overall phase of the operation for this MySQLOpsRequest. It can have the following three values:

PhaseMeaning
SuccessfulKubeDB has successfully performed the operation requested in the MySQLOpsRequest
FailedKubeDB has failed the operation requested in the MySQLOpsRequest
DeniedKubeDB has denied the operation requested in the MySQLOpsRequest

status.observedGeneration

status.observedGeneration shows the most recent generation observed by the MySQLOpsRequest controller.

status.conditions

status.conditions is an array that specifies the conditions of different steps of MySQLOpsRequest processing. Each condition entry has the following fields:

  • types specifies the type of the condition. MySQLOpsRequest has the following types of conditions:
TypeMeaning
ProgressingSpecifies that the operation is now progressing
SuccessfulSpecifies such a state that the operation on the database has been successful.
HaltDatabaseSpecifies such a state that the database is halted by the operator
ResumeDatabaseSpecifies such a state that the database is resumed by the operator
FailureSpecifies such a state that the operation on the database has been failed.
ScalingSpecifies such a state that the scaling operation on the database has stared
VerticalScalingSpecifies such a state that vertical scaling has performed successfully on database
HorizontalScalingSpecifies such a state that horizontal scaling has performed successfully on database
UpgradingSpecifies such a state that database upgrading operation has stared
UpgradeVersionSpecifies such a state that version upgrading on the database have performed successfully
  • The status field is a string, with possible values "True", "False", and "Unknown".
    • status will be "True" if the current transition is succeeded.
    • status will be "False" if the current transition is failed.
    • status will be "Unknown" if the current transition is denied.
  • The message field is a human-readable message indicating details about the condition.
  • The reason field is a unique, one-word, CamelCase reason for the condition’s last transition. It has the following possible values:
ReasonMeaning
OpsRequestProgressingStartedOperator has started the OpsRequest processing
OpsRequestFailedToProgressingOperator has failed to start the OpsRequest processing
SuccessfullyHaltedDatabaseDatabase is successfully halted by the operator
FailedToHaltDatabaseDatabase is failed to halt by the operator
SuccessfullyResumedDatabaseDatabase is successfully resumed to perform its usual operation
FailedToResumedDatabaseDatabase is failed to resume
DatabaseVersionUpgradingStartedOperator has started upgrading the database version
SuccessfullyUpgradedDatabaseVersionOperator has successfully upgraded the database version
FailedToUpgradeDatabaseVersionOperator has failed to upgrade the database version
HorizontalScalingStartedOperator has started the horizontal scaling
SuccessfullyPerformedHorizontalScalingOperator has successfully performed on horizontal scaling
FailedToPerformHorizontalScalingOperator has failed to perform on horizontal scaling
VerticalScalingStartedOperator has started the vertical scaling
SuccessfullyPerformedVerticalScalingOperator has successfully performed on vertical scaling
FailedToPerformVerticalScalingOperator has failed to perform on vertical scaling
OpsRequestProcessedSuccessfullyOperator has completed the operation successfully requested by the OpeRequest cr
  • The lastTransitionTime field provides a timestamp for when the operation last transitioned from one state to another.
  • The observedGeneration shows the most recent condition transition generation observed by the controller.