The Ultimate Guide to High Availability with MariaDB

Kubernetes Operators for MariaDB

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 for declaratively managing your MariaDB using Kubernetes CRDs rather than 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: SemiSync Replication and Galera.
  • 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.
    • Query-based routing: Transparently route write queries to the primary nodes and read queries to the replica nodes.
    • Connection-based routing: Load balance connections between multiple servers.
    • Automated primary failover based on MariaDB internals.
    • Replay pending transactions when a server goes down.
    • Support for Galera and Replication.
  • Flexible storage configuration. Volume expansion.
  • Take and restore backups.
  • Scheduled backups.
  • Multiple backup storage types: S3 compatible, PVCs and Kubernetes volumes.
  • Backup retention policy.
  • Target recovery time: infer which backup to restore.
  • Bootstrap new instances from: Backups, S3, PVCs ...
  • Prometheus metrics via mysqld-exporter.
  • Manage users, grants and logical databases.
  • Configure connections for your applications.
  • Orchestrate and schedule sql scripts.
  • Validation webhooks to provide CRD inmutability.
  • Additional printer columns to report the current CRD status.
  • CRDs designed according to the Kubernetes API conventions.
  • GitOps friendly.
  • Multi-arch distroless based image.
  • Install it using kubectl, helm or OLM.

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.