At the top of every file, there will be apiVersion and kind. These values should be left as they are, and look like the following:

apiVersion: tungsten.continuent.com/v1alpha1
kind: MySQLCluster

The metadata section must also always be included with all values left as per the template, with the exception of app.kubernetes.io/instance and name. These values can be changed but must be set to the same value for each. An example of this section is as follows:

metadata:
  labels:
    app.kubernetes.io/name: mysqlcluster
    app.kubernetes.io/instance: sample
    app.kubernetes.io/part-of: tungsten-operator
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/created-by: tungsten-operator
  name: sample

Within this section, you specify the password configuration to associate with this cluster if you are setting custom passwords. The value for customPasswordSecret should be the same as the vlaue of name within the mysql-passwords.yaml, or the file you are using for the password secrets. An example of this section is as follows:

spec:
  configuration:
    customPasswordSecret: tungsten-passwords-sample-secret
    enablePodDisruptionBudget: true

Monitoring can be enabled by specifying true, or disabled by specifying false.

Setting this value to true will enable the various Prometheus exporters that will provide metrics that can be used with, for example, Graphana or other monitoring tools.

monitoring:
    enabled: false

The dataServices section allows you to confgure the desired topology and the cluster data service names. There are 3 different layouts for this section depending on the topology required, for example a standard cluster, a Composite Active/Passive cluster or a Composite Active/Active cluster. They all follow the same basic pattern.

The name is used for the corresponding dataservice. This must only be alphanumeric characters along with - or _ and is not case-sensitive. For Composite Active/Passive and Composite Active/Active topologies, each cluster must be given a different name.

topology is used to specify the topology of the cluster. The accepted values are as follows:

sources is used in composite clusters only. Within the top level composite cluster it defines the names of the clusters within. For a Composite Active/Passive custer it should also be defined within the passive cluster to define the source cluster.

sizes is used to specify the number of nodes within the cluster. This must be an odd number per cluster to conform to quorum.

Examples:

A standard 3-node cluster called alpha:

dataServices:
  - name: alpha
    topology: clustered
    size: 3

A Composite Active/Passive cluster with a composite cluster called global comprising of an active cluster of 3 nodes called east and a passive cluster of 3 nodes called west:

dataServices:
  - name: global
    topology: composite-active-passive
    sources:
    - east
    - west
  - name: east
    topology: clustered
    size: 3
  - name: west
    topology: clustered
    sources:
    - east
    size: 3

A Composite Active/Active cluster with a composite cluster called global comprising fo 2 x 3 node clusters called north and south:

dataServices:
  - name: global
    topology: composite-active-active
    sources:
    - north
    - south
  - name: north
    topology: clustered
    size: 3
  - name: south
    topology: clustered
    size: 3

The connector section allows you to define the number of connectors to launch using the replicas option. For Composite Active/Passive and Composite Active/Active topologies this will number is per cluster, so in the above examples where we define 2 clusters, setting replicas to 2 would result in a total of 4 connectors.

Additionally, within the containers block you can specify the number of CPU's and memory allocation per connector. The default values in the template are generally sufficient for the majority of workloads and shouldn't require changing.

An example of the connector block is as follows:

connector:
    replicas: 2
    podTemplate:
      spec:
        containers:
        - name: connector
          resources:
            requests:
              cpu: 1
              memory: 512Mi
            limits:
              memory: 512Mi

The podTemplate section allows for configuration of the MySQL, Tungsten Manager and Tungsten Replicator containers, allowing you to specify appropriate Memory and CPU properties. The name values shouldn't be changed. The MySQL limits should be adjusted based on your expected workload in line with your MySQL usage. The Tungsten Manager and Tungsten Replicator default values are generally sufficient for the majority of workloads and shouldn't require changing.

An example of this block is as follows:

podTemplate:
    spec:
      containers:
      - name: mysql
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi
      - name: manager
        resources:
          requests:
            cpu: 100m
            memory: 512Mi
          limits:
            memory: 512Mi
      - name: replicator
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            memory: 2Gi

The volumeClaimTemplates section allows you to adjust the storage allocated. The only values that should be changed here are the storage values, adjusting to suit the expected usage for the MySQL databases and THL files. For THL allocation you should calculate this storage based on roughly 1.5-2 times the size of the binary logs generated within the retention period set (Default 10 days)

An example of this block is as follows:

volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 40Gi
  - metadata:
      name: thl
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi
  - metadata:
      name: state
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Mi