In this guide, we will be migrating from the MariaDB Community Operator to the MariaDB Enterprise Kubernetes Operator without downtime. This guide assumes:
0.37.1 version of the MariaDB Community Operator is installed in the cluster.
MariaDB community resources will be migrated to its counterpart MariaDB enterprise resource. In this case, we will be using 11.4.4 version, which is supported in both community and enterprise versions. Check the supported MariaDB Enterprise images and migrate to a counterpart community version first if needed.
MaxScale resources cannot be migrated in a similar way, they need to be recreated. To avoid downtime, temporarily point your applications to MariaDB directly during the migration.
1. Install the Enterprise CRDs as described in the .
2. Get the and grant execute permissions:
3. Migrate MariaDB resources using the migration script. Make sure you set <mariadb-name> with the name of the MariaDB resource to be migrated and <operator-version> with the version of the Enterprise operator you will be installing:
4. Update the apiVersion of the rest of CRs to enterprise.mariadb.com/v1alpha1.
5. Uninstall the Community operator:
6. If your MariaDB Community had Galera enabled, delete the <mariadb-name> Role, as it will be specyfing the Community CRDs:
7. Install the Enterprise operator as described in the . This will trigger a rolling upgrade, make sure it finishes successfully before proceeding with the next step.
8. Delete the finalizers and uninstall the Community CRDs:
9. Run mariadb-upgrade in all Pods. Make sure you set <mariadb-name> with the name of the MariaDB resource:
10. Restart the Enterprise operator:
curl -sLO https://operator.mariadb.com/scripts/migrate_enterprise.sh
chmod +x migrate_enterprise.shRESOURCE="<mariadb-name>" \
OLD_API_GROUP="k8s.mariadb.com" \
NEW_API_GROUP="enterprise.mariadb.com" \
NEW_MARIADB_IMAGE="docker.mariadb.com/enterprise-server:11.4.4-2" \
NEW_MARIADB_OPERATOR_IMAGE="docker.mariadb.com/mariadb-enterprise-operator:<operator-version>" \
./migrate_enterprise.shhelm uninstall mariadb-operatorkubectl delete role <mariadb-name>for crd in $(kubectl get crds -o json | jq -r '.items[] | select(.spec.group=="k8s.mariadb.com") | .metadata.name'); do
kubectl get "$crd" -A -o json | jq -r '.items[] | "\(.metadata.namespace)/\(.metadata.name)"' | while read cr; do
ns=$(echo "$cr" | cut -d'/' -f1)
name=$(echo "$cr" | cut -d'/' -f2)
echo "Removing finalizers from $crd: $name in $ns..."
kubectl patch "$crd" "$name" -n "$ns" --type merge -p '{"metadata":{"finalizers":[]}}'
done
done
helm uninstall mariadb-operator-crdsfor pod in $(kubectl get pods -l app.kubernetes.io/instance=<mariadb-name> -o jsonpath='{.items[*].metadata.name}'); do
kubectl exec "$pod" -- sh -c 'mariadb-upgrade -u root -p${MARIADB_ROOT_PASSWORD} -f'
donekubectl rollout restart deployment mariadb-enterprise-operatorLearn about migrations with MariaDB Enterprise Kubernetes Operator. This section covers strategies and procedures for smoothly migrating your MariaDB databases within Kubernetes environments.
In this guide, we will be migrating existing MariaDB Galera and MaxScale instances to TLS without downtime.
1. Ensure that MariaDB has TLS enabled and not enforced. Set the following options if needed:
By setting these options, the operator will issue and configure certificates for MariaDB, but TLS will not be enforced in the connections i.e. both TLS and non-TLS connections will be accepted. TLS enforcement will be optionally configured at the end of the migration process.
This will trigger a rolling upgrade, make sure it finishes successfully before proceeding with the next step. Refer to the updates documentation for further information about update strategies.
2. If you are currently using MaxScale, it is important to note that, unlike MariaDB, it does not support TLS and non-TLS connections simultaneously (see ). For this reason, you must temporarily point your applications to MariaDB during the migration process. You can achieve this by configuring your application to use the . At the end of the MariaDB migration process, the MaxScale instance will need to be recreated in order to use TLS, and then you will be able to point your application back to MaxScale. Ensure that all applications are pointing to MariaDB before moving on to the next step.
3. MariaDB is now accepting TLS connections. The next step is by pointing them to MariaDB securely. Ensure that all applications are connecting to MariaDB via TLS before proceeding to the next step.
4. If you are currently using MaxScale, and you are planning to connect via TLS through it, you should now delete your MaxScale instance. If needed, keep a copy of the MaxScale manifest, as we will need to recreate it with TLS enabled in further steps:
It is very important that you wait until your old MaxScale instance is fully terminated to make sure that the old configuration is cleaned up by the operator.
5. For enhanced security, it is recommended to enforce TLS in all MariaDB connections by setting the following options. This will trigger a rolling upgrade, make sure it finishes successfully before proceeding with the next step:
6. For improved security, you can optionally configure TLS for Galera SSTs by following the steps below:
Get the and grant execute permissions:
Run the migration script. Make sure you set <mariadb-name> with the name of the MariaDB resource:
Set the following option to enable TLS for Galera SSTs:
This will trigger a rolling upgrade, make sure it finishes successfully before proceeding with the next step
7. As mentioned in step 4, recreate your MaxScale instance with tls.enabled=true if needed:
8. MaxScale is now accepting TLS connections. Next, you need to by pointing them back to MaxScale securely. You have done this previously for MariaDB, you just need to update your application configuration to use the and its CA bundle.
In this guide, we will be migrating an external MariaDB into a new MariaDB instance running in Kubernetes and managed by MariaDB Enterprise Kubernetes Operator. We will be using for achieving this migration.
1. Take a logical backup of your external MariaDB using one of the commands below:
If you are currently using or migrating to a Galera instance, use the following command instead:
2. Ensure that your backup file matches the following format: backup.2024-08-26T12:24:34Z.sql
apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-galera
spec:
tls:
+ enabled: true
+ required: false
+ galeraSSTEnabled: false
+ galeraServerSSLMode: PROVIDER
+ galeraClientSSLMode: DISABLED3. Upload the backup file to one of the supported storage types. We recommend using S3.
4. Create your MariaDB resource declaring that you want to bootstrap from the previous backup and providing a root password Secret that matches the backup:
5. If you are using Galera in your new instance, migrate your previous users and grants to use the User and Grant CRs. Refer to the SQL resource documentation for further detail.
mariadb-dump --user=${MARIADB_USER} --password=${MARIADB_PASSWORD} --host=${MARIADB_HOST} --single-transaction --events --routines --all-databases > backup.2024-08-26T12:24:34Z.sqlmariadb-dump --user=${MARIADB_USER} --password=${MARIADB_PASSWORD} --host=${MARIADB_HOST} --single-transaction --events --routines --all-databases --skip-add-locks --ignore-table=mysql.global_priv > backup.2024-08-26T12:24:34Z.sqlapiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-galera
spec:
rootPasswordSecretKeyRef:
name: mariadb
key: root-password
replicas: 3
galera:
enabled: true
storage:
size: 1Gi
bootstrapFrom:
s3:
bucket: backups
prefix: mariadb
endpoint: minio.minio.svc.cluster.local:9000
accessKeyIdSecretKeyRef:
name: minio
key: access-key-id
secretAccessKeySecretKeyRef:
name: minio
key: secret-access-key
tls:
enabled: true
caSecretKeyRef:
name: minio-ca
key: tls.crt
targetRecoveryTime: 2024-08-26T12:24:34Zkubectl get mxs maxscale-galera -o yaml > maxscale-galera.yaml
kubectl delete mxs maxscale-galeraapiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-galera
spec:
tls:
+ required: true
+ galeraServerSSLMode: SERVER_X509curl -sLO https://operator.mariadb.com/scripts/migrate_galera_ssl.sh
chmod +x migrate_galera_ssl.sh./migrate_galera_ssl.sh <mariadb-name>apiVersion: enterprise.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-galera
spec:
tls:
+ galeraSSTEnabled: true
+ galeraClientSSLMode: VERIFY_IDENTITYapiVersion: enterprise.mariadb.com/v1alpha1
kind: MaxScale
metadata:
name: maxscale-galera
spec:
+ tls:
+ enabled: trueThis page is: Copyright © 2025 MariaDB. All rights reserved.
This page is: Copyright © 2025 MariaDB. All rights reserved.
This page is: Copyright © 2025 MariaDB. All rights reserved.