The Ultimate Guide to High Availability with MariaDB

Kubernetes Operators for MariaDB

You are viewing an old version of this article. View the current version here.

Operators basically instruct Kubernetes about how to manage a certain technology. Kubernetes comes with some default operators, but it is possible to create custom operators. Operators created by the community can be found on OperatorHub.io.

Contents

  1. Custom Operators
  2. MariaDB Operator
  3. Other Operators

Custom Operators

Kubernetes provides a declarative API. To support a specific (i.e. MariaDB) technology or implement a desired behavior (i.e. provisioning a replica), we extend Kubernetes API. This involves creating two main components:

  • A custom resource.
  • A custom controller.

A custom resource adds an API endpoint, so the resource can be managed via the API server. It includes functionality to get information about the resource, like a list of the existing servers.

A custom controller implements the checks that must be performed against the resource to check if its state should be corrected using the API. In the case of MariaDB, some reasonable checks would be verifying that it accepts connections, replication is running, and a server is (or is not) read only.

MariaDB Operator

mariadb-operator is a Kubernetes operator that allows you to run and operate MariaDB in a cloud native way. It aims to declaratively manage MariaDB instances using Kubernetes CRDs instead of imperative commands.

It's available in both Artifact Hub and Operator Hub and supports the following features:

  • Easily provision MariaDB servers in Kubernetes.
  • Highly configurable MariaDB servers.
  • Multiple HA modes: Galera and SemiSync Replication.
  • Automated primary failover.
  • Automated Galera cluster recovery.
  • Enhanced HA with MaxScale: a sophisticated database proxy, router, and load balancer designed specifically for and by MariaDB.
  • Flexible storage configuration. Volume expansion.
  • Take and restore backups.
  • Scheduled backups.
  • Multiple backup storage types: S3 compatible, PVCs and Kubernetes volumes.
  • Backup retention policy.
  • Backup compression: bzip2 and gzip algorithms supported.
  • Target recovery time: infer which backup to restore.
  • Bootstrap new instances from: Backups, S3, PVCs ...
  • Multiple update strategies: ReplicasFirstPrimaryLast, RollingUpdate, OnDelete and Never.
  • Cluster-aware rolling update: roll out replica Pods one by one, wait for each of them to become ready, and then proceed with the primary Pod.
  • Automated data-plane updates.
  • my.cnf configuration. Automatically trigger updates when my.cnf changes.
  • Suspend operator reconciliation for maintenance operations.
  • Prometheus metrics via mysqld-exporter.
  • Declaratively manage SQL resources: users, grants and logical databases.
  • Configure connections for your applications.
  • Orchestrate and schedule sql scripts.
  • Validation webhooks to provide CRD immutability.
  • Additional printer columns to report the current CRD status.
  • CRDs designed according to the Kubernetes API conventions.
  • Install it using helm, OLM or static manifests.
  • Multiple deployment modes: cluster-wide and single namespace.
  • Multi-arch distroless image.
  • GitOps friendly.

This operator is open source and released under the terms of the MIT license. The source code is available on GitHub.

Other Operators

If you know about other MariaDB operators, feel free to add them to this page (see Writing and Editing Knowledge Base Articles).

MySQL and Percona Server operators should work as well, though some changes may be necessary to fix incompatibilities or take advantage of certain MariaDB features.

Content initially contributed by Vettabase Ltd.

Comments

Comments loading...
Content reproduced on this site is the property of its respective owners, and this content is not reviewed in advance by MariaDB. The views, information and opinions expressed by this content do not necessarily represent those of MariaDB or any other party.