- About Us
MariaDB has always been available for deployment into a wide range of environments, and as container packaging and the Kubernetes orchestration system have become a dominant deployment model, MariaDB has provided the assets and expertise required for successfully deploying and managing our database with these technologies.
Containers allow software programs to be packaged into a simple image file. Any server that has installed the appropriate container runtime software can then execute the image file, creating a “container” that runs the packaged software and keeps it isolated from other containers or software that may be running on the same server.
In many ways this is similar to virtual machine images and the hypervisors used to execute those images. Containers, however do not require that each image include a full operating system, resulting in a much smaller image file and a much faster start-up time. These two aspects of containers have allowed them to address thorny IT issues like high availability and scalability in ways that were impossible before.
By default all data written to the filesystem inside a container is ephemeral. That is, it will be lost when the container is terminated. For many software components this is not a problem. Web servers, application servers, proxies and a host of other applications do not store data directly themselves, relying instead on a database for secure, reliable information storage. And it is precisely those applications (application servers, etc.) where containers first gained in popularity.
As organizations have moved towards managing more software via containers, and as their container runtime environments have grown to include hundreds or thousands of servers, pressure has mounted to run persistent applications on containers as well. Fortunately, there are now many options for associating persistent storage with a running container.
As container deployments have grown from simple application stacks to complex, service-based deployments across hundreds of machines in each enterprise, orchestration and management of containers has become a first-class problem for IT organizations. In the last several years, the Kubernetes project has emerged as the de-facto standard for managing containerized workloads. Many vendor specific orchestration tools that pre-date the Kubernetes project have adopted Kubernetes functionality as the core of their orchestration strategy.
Kubernetes allows controllers to define higher-level objects such as services, persistent volumes, and replica sets. Rather than deploying containers by hand, controllers use these objects to declare the desired of your containerized workload and then automatically deploy to match that state.
With a standardized approach to container management, much of the time consuming and error prone work of deploying complex application stacks is removed. Operators need only declare a few higher-level settings and can allow Kubernetes to take care of the rest.
Whether you are running a single instance of MariaDB Server for development purposes, or supporting a mission-critical production workload, MariaDB provides the assets required for success.
Official MariaDB Container Images are available or Docker Hub, with source code available on Github. Full documentation for MariaDB images are available with in the Docker Hub and Github readmes referenced below.
This image provides MariaDB Server configured to run in a single container and configured to support OLTP workloads. Launched with a simple docker run command, this image is a popular starting point for developers who want to quickly instantiate a MariaDB database and begin executing SQL.
This image provides MariaDB with the ColumnStore storage engine configured to support analytic workloads. Operators may launch either a single container image or a multi-container deployment use the provided docker-compose file.
MariaDB MaxScale provides routing, security and other features for a MariaDB deployment. This image can be used to launch one or more MaxScale containers that can then be manually configured to work with your MariaDB database.
MariaDB Platform – Single Node
This image provides all of the functionality of MariaDB Platform packed into a single image. This includes replicated MaxScale, MariaDB Server running with replication, and CDC configured to stream changes into a separate MariaDB ColumnStore installation for analytical purposes. Used for test and development purposes only, this is the fastest way to run the full MariaDB stack.
MariaDB Helm charts allow you to create complex MariaDB topologies for mission-critical applications. The topologies are comprised of multiple containers. Specifically, these deployments are comprised of multiple instances of MariaDB Server in a replicated or clustered configuration and two instances of MariaDB MaxScale for high availability, or multiple instances of MariaDB ColumnStore for ad hoc, interactive analytics scale, using distributed storage and massively parallel processing to query billions of rows in real time.
The following MariaDB Platform topologies are supported:
To learn more about deploying MariaDB Platform on Kubernetes with Helm charts, see the documentation here.
The MariaDB Kubernetes Operator builds on the Helm charts and automates the deployment and scaling of MariaDB Platform on Kubernetes, and is certified for Red Hat OpenShift Container Platform. It provides customers with native support for Kubernetes so rather than defining MariaDB deployments in terms of Kubernetes (i.e.., pods ands services), administrators can define MariaDB Platform deployments in terms of components (i.e., MariaDB MaxScale and MariaDB Server). The MariaDB Kubernetes Operator enables administrators to specify how many databases instances are required and whether they should be configured for transactional processing, replicated or clustered, or analytical processing, standalone or fully distributed.
To learn more about deploying MariaDB Platform on Kubernetes with a native operator, see the documentation here.