Showing results for 
Search instead for 
Did you mean: 

Deploying Galera Maria DB Cluster using Veritas InfoScale in a Kubernetes Environment

Level 1

What is MariaDB Galera Cluster?

MariaDB Galera Cluster is a  virtually synchronous, multi-primary cluster for MariaDB. It is available on Linux only.

More details about MariaDB Galera Cluster’s features can be found at the following link: Features of MariaDB Galera Cluster. For its limitations, see:

MariaDB Galera Cluster in Kubernetes backed by Veritas InfoScale for Containers

Kubernetes is a complex platform that consists of many abstractions for managing applications and their data to provide advanced container orchestration services.

Veritas provides enterprise data services focused on data management and protection. These services are designed to provide an enterprise foundation to support your containerized applications like Oracle, Postgres, MySQL, MariaDB in environments like vanilla Kubernetes or RedHat OpenShift platform.

The persistent storage to the application pods like MariaDB can be provided by using the standard Container Storage Interface (CSI) interface. The CSI interface supports a variety of data protection options for resiliency, scaling, and resizing.

Benefits of Veritas InfoScale for Containers against node/disk failure of a Kubernetes worker node

If any Kubernetes worker node goes down during data insertion, data insertion operations get affected if a non-InfoScale Storage Class is used to provide storage to the MariaDB application. Manual intervention is thus needed for re-mapping the new storage from the new node where the MariaDB pod fails over. Additional wait time is needed till the new pod re-synchronizes with the other two instances.

Using an InfoScale Storage Class with Flexible Shared Storage (i.e., local storage from the worker nodes) ensures that your data insertion operations can continue to run as if there was no storage loss. It appears like a minor glitch that would get rectified in a matter of some minutes (usually the time taken for the MariaDB application pod to failover) as the storage is available across all the cluster nodes. PVC gets mapped to the failed over pod automatically, whereas the other two instances of the MariaDB continue to run unaffected.

Using an InfoScale Storage Class with Shared storage from a SAN array protects from a worker node or a disk failure with minimal pause time only until MariaDB pod fails over to a new node.

Pre-requisites for Deployment of MariaDB Galera Cluster

Following are some of the pre-requisites for deploying MariaDB Galera Cluster with Veritas InfoScale:

  • Veritas InfoScale for Containers 8.0.0
  • Load balancer applications like Metallb for distributing the load across the cluster or nodePort service for accessing the individual MariaDB instances from internal/external clients.
  • Helm Charts 3.1.0+ bootstraps a MariaDB Galera cluster on Kubernetes by using the Helm package manager.

Deployment of MariaDB Galera Cluster by using persistent storage managed by Veritas Infoscale

The following figure provides an overview of how Veritas provides data management and protection for MariaDB Galera Cluster application and IT services running in a Kubernetes (K8s) environment.


Configuring MariaDB Galera cluster in Kubernetes by using persistent storage from Veritas InfoScale

  • Install the Kubernetes cluster v1.20.11 on Oracle Linux 8.4 (supported Kubernetes version) with one master and up to four Worker nodes configuration depending on the number of nodes in the MariaDB cluster you need.
  • Configure Veritas InfoScale for Containers: Install Guide link
  • After the Veritas InfoScale cluster is up and running, create an InfoScale Storage Class in the Kubernetes cluster by using the sample yaml:


kind: StorageClass


    name: csi-infoscale-mirror-sc       # Name for the Storage Class


        # Default Storage class    "true"

provisioner:    org.veritas.infoscale

reclaimPolicy:  Delete                   # Reclaim Policy can be delete/retain

allowVolumeExpansion:   True             # Allow growing of PV


    # Veritas InfoScale Storage Class parameters

    fstype: vxfs                  # FS type, default vxfs

    layout: "mirror"              # Storage layout mirror/stripe/stripe-mirror

    faultTolerence: "2"           # No. of mirrors

    encryption: "false"           # param for supporting encryption in future

    mediaType: "hdd"              # Media type of storage to be used hdd/ssd

  • Set up the Load balancer (optionally nodePort service can also be used) like Metallb. You can refer to its documentation.
  • Add the bitnami repo for MariaDB Galera Cluster by using Helm
  • Deploy the MariaDB Galera Cluster with MetallB as a load balancer by using the command:

helm install my-galera --set rootUser.forcePassword=true --set rootUser.password=<root-user-password> --set db.forcePassword=true --set db.user=app_database --set db.password=<user-password> --set<DB-Name> --set global.storageClass=<InfoScale-Storage-Class-Name> --set image.tag=latest --set service.type=LoadBalancer --set service.loadBalancerIP=<metallb-VIP-to-be-used-for-load-balancing> --set galera.mariabackup.forcePassword=true --set galera.mariabackup.password=<backup-password> --set persistence.size=<PV size for each MariaDB instance>   bitnami/mariadb-galera

Note: Based on your Kubernetes cluster environments you may have to tweak some additional configurations to get the MariaDB Galera Cluster in a running state. To know the additional parameters, see charts/bitnami/mariadb-galera at master · bitnami/charts · GitHub.  

  • A three-node MariaDB Galera Cluster is set up by default using Stateful Set configuration with the specified database size as defined above.
  • Check the MariaDB Galera Cluster readiness by using the command

kubectl get sts -w --namespace default -l my-galera

  • After the MariaDB Galera cluster is up, connect to any instance of the MariaDB pod by using
    • A temporary client by spawning a MySQL client container. run the command:

kubectl run my-galera-mariadb-galera-client --rm --tty -i --restart='Never' --namespace default \

--image --command \

-- mysql -h my-galera-mariadb-galera -P 3306 -uapp_database \

-p$(kubectl get secret --namespace default my-galera-mariadb-galera \

-o jsonpath="{.data.mariadb-password}" | base64 --decode) galera_mariadb

    • An external client with a Metallb Load Balancer VIP or the nodePort service configuration
  • Start inserting/updating data in the MariaDB by using any supported data insertion method or tool.


Veritas InfoScale is a proven solution for enterprise storage management providers for managing infrastructure availability. Veritas InfoScale has evolved into a premier software-defined platform for managing storage and high availability. In Containers, InfoScale can provide several benefits that are not available natively, which provide the functionality and confidence needed to use Kubernetes or OpenShift as a target environment for hosting various applications.

You can also find additional InfoScale information and resources in the InfoScale technical library

1 Comment
Level 1

The bitnami/mariadb-galera chart is using by default mariadb 10.6. In the example above we are setting image.tag=latest so at some point you started using mariadb 10.7 instead of 10.6

My recommendation, if you are working in a development environment and you don't need version 10.7, set image.tag=10.6 this configuration will use latest release for version 10.6.

And you will not face any compatibility/configuration issues while deploying Galera Maria DB cluster.

Details of this issue with MariaDB version compatibility issue is described in the following link: Galera mariadb pod restarting after Setting wsrep_sst_auth option as per logs · Issue #82 · bitnami/...