Skip to content

Deploy the MariaDB Operator and Mariadb Cluster

Create secret

Information about the secretes used

Manual secret generation is only required if you haven't run the create-secrets.sh script located in /opt/genestack/bin.

Example secret generation
kubectl --namespace openstack \
        create secret generic mariadb \
        --type Opaque \
        --from-literal=root-password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)" \
        --from-literal=password="$(< /dev/urandom tr -dc _A-Za-z0-9 | head -c${1:-32};echo;)"

Deploy the mariadb operator

cluster_name=`kubectl config view --minify -o jsonpath='{.clusters[0].name}'`
echo $cluster_name
If cluster_name was anything other than cluster.local you should pass that as a parameter to the installer

Run the mariadb-operator deployment Script bin/install-mariadb-operator.sh You can include cluster_name paramater. No paramaters deploys with cluster.local cluster name.

#!/bin/bash
# shellcheck disable=SC2124,SC2145,SC2294

# Default parameter value
CLUSTER_NAME=${1:-cluster.local}

# Directory to check for YAML files
CONFIG_DIR="/etc/genestack/helm-configs/mariadb-operator"

# 'cluster.local' is the default value in base helm values file
if [ "${CLUSTER_NAME}" != "cluster.local" ]; then
    CONFIG_FILE="$CONFIG_DIR/mariadb-operator-helm-overrides.yaml"

    mkdir -p $CONFIG_DIR
    touch "$CONFIG_FILE"

    # Check if the file is empty and add/modify content accordingly
    if [ ! -s "$CONFIG_FILE" ]; then
        echo "clusterName: $CLUSTER_NAME" > "$CONFIG_FILE"
    else
        # If the clusterName line exists, modify it, otherwise add it at the end
        if grep -q "^clusterName:" "$CONFIG_FILE"; then
            sed -i -e "s/^clusterName: .*/clusterName: ${CLUSTER_NAME}/" "$CONFIG_FILE"
        else
            echo "clusterName: $CLUSTER_NAME" >> "$CONFIG_FILE"
        fi
    fi
fi

# Helm command setup
HELM_CMD="helm upgrade --install mariadb-operator mariadb-operator --repo https://mariadb-operator.github.io/mariadb-operator \
    --namespace=mariadb-system \
    --create-namespace \
    --timeout 120m \
    --version 0.28.1 \
    --post-renderer /etc/genestack/kustomize/kustomize.sh \
    --post-renderer-args mariadb-operator/overlay \
    -f /opt/genestack/base-helm-configs/mariadb-operator/mariadb-operator-helm-overrides.yaml"

# Check if YAML files exist in the specified directory
if compgen -G "${CONFIG_DIR}/*.yaml" > /dev/null; then
    # Add all YAML files from the directory to the helm command
    for yaml_file in "${CONFIG_DIR}"/*.yaml; do
        HELM_CMD+=" -f ${yaml_file}"
    done
fi

HELM_CMD+="${@}"

# Run the helm command
echo "Executing Helm command:"
echo "${HELM_CMD}"
eval "${HELM_CMD}"

Info

The operator may take a minute to get ready, before deploying the Galera cluster, wait until the webhook is online.

kubectl --namespace mariadb-system get pods -w

Deploy the MariaDB Cluster

Note

MariaDB has a base configuration which is HA and production ready. If you're deploying on a small cluster the aio configuration may better suit the needs of the environment.

Replication in MariaDB involves synchronizing data between a primary database and one or more replicas, enabling continuous data availability even in the event of hardware failures or outages. By using MariaDB replication, OpenStack deployments can achieve improved fault tolerance and load balancing, ensuring that critical cloud services remain operational and performant at all times.

kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/overlay

In some OpenStack deployments, a single MariaDB server is used to manage the database needs of the cloud environment. While this setup is simpler and easier to manage than clustered solutions, it is typically suited for smaller environments or use cases where high availability and fault tolerance are not critical. A single MariaDB server provides a centralized database service for storing and managing the operational data of OpenStack components, ensuring consistent performance and straightforward management. However, it is important to recognize that this configuration presents a single point of failure, making it less resilient to outages or hardware failures compared to more robust, multi-node setups.

kubectl --namespace openstack apply -k /etc/genestack/kustomize/mariadb-cluster/aio

Verify readiness with the following command

kubectl --namespace openstack get mariadbs -w