MOCO creates and updates a StatefulSet and related resources for each MySQLCluster custom resource. This document describes how and when MOCO updates them.
- Reconciler versions
- The update policy of moco-agent container
- Clustering related resources
- Backup and restore related resources
MOCO's reconciliation routine should be consistent to avoid frequent updates.
That said, we may need to modify the reconciliation process in the future. To avoid updating the StatefulSet, MOCO has multiple versions of reconcilers.
For example, if a MySQLCluster is reconciled with version 1 of the reconciler, MOCO will keep using the version 1 reconciler to reconcile the MySQLCluster.
If the user edits MySQLCluster's
spec field, MOCO can reconcile the MySQLCluster with the latest reconciler, for example version 2, because the user shall be ready for mysqld restarts.
We shall try to avoid updating moco-agent as much as possible.
The figure below illustrates the overview of resources related to clustering MySQL instances.
MOCO tries not to update the StatefulSet frequently. It updates the StatefulSet only when the update is a must.
The StatefulSet will be updated when:
- Some fields under
specof MySQLCluster are modified.
my.cnffor mysqld is updated.
- the version of the reconciler used to reconcile the StatefulSet is obsoleted.
- the image of moco-agent given to the controller is updated.
- the image of mysqld_exporter given to the controller is updated.
- the image of fluent-bit given to the controller is changed.
- because the controller does not depend on fluent-bit.
The fluent-bit sidecar container is updated only when some fields under
spec of MySQLCluster are modified.
MOCO generates random passwords for users that MOCO uses to access MySQL.
The generated passwords are stored in two Secrets.
One is in the same namespace as
moco-controller, and the other is in the namespace of MySQLCluster.
MOCO creates a Certificate in the same namespace as
moco-controller to issue a TLS certificate for
After cert-manager issues a TLS certificate and creates a Secret for it, MOCO copies the Secret to the namespace of MySQLCluster. For details, read security.md.
MOCO creates three Services for each MySQLCluster, that is:
- A headless Service, required for every StatefulSet
- A Service for the primary mysqld instance
- A Service for replica mysql instances
The Services' labels, annotations, and
spec fields can be customized with MySQLCluster's
The following fields in Service
spec may not be customized, though.
MOCO creates and updates a ConfigMap for
The name of this ConfigMap is calculated from the contents of
my.cnf that may be changed by users.
MOCO deletes old ConfigMaps of
my.cnf after a new ConfigMap for
my.cnf is created.
If the cluster does not disable a sidecar container for slow query logs, MOCO creates a ConfigMap for the sidecar.
MOCO creates a PodDisruptionBudget for each MySQLCluster to prevent too few semi-sync replica servers.
spec.maxUnavailable value is calculated from MySQLCluster's
spec.replicas as follows:
`spec.maxUnavailable` = floor(`spec.replicas` / 2)
spec.replicas is 1, MOCO does not create a PDB.
MOCO creates a ServiceAccount for Pods of the StatefulSet. The ServiceAccount is not bound to any Roles/ClusterRoles.
See backup.md for the overview of the backup and restoration mechanism.
This is the only resource created when backup is enabled for MySQLCluster.
If the backup is disabled, the CronJob is deleted.
To restore data from a backup, MOCO creates a Job. MOCO deletes the Job after the Job finishes successfully.
If the Job fails, MOCO leaves the Job.