- 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.
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 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:
MariaDB Kubernetes Helm Charts are early-access releases, available for non-production use only. We are currently testing them for stability with a few customers. Submit your access or support requests to MariaDB Corporation Support.