Gcov in MariaDB

Gcov is a coverage testing tool, used to create better programs. It can show which parts of the codebase are untested. Gcov is located in the same package as gcc. MariaDB takes care of code quality and checks test coverage with Gcov. We are looking forward to have Gcov used soon as a part of our buildbot (MDBF-158).

How to use Gcov

Let’s write a demo example to demonstrate how it works.

— Source code:

$ cat -n test.c
int f1()
{
return 0; …

replicate_rewrite_db as a system variable in MariaDB

MariaDB 10.11.0, our latest preview release, features quite a number of improvements. The one we’ll talk about here is replicate-rewrite-db. This option has become a system variable from 10.11.0 based on MDEV-15530. Before this version it was just an option used by the mariadbd and mariadb-binlog binaries. There have been no behaviour changes with the option; it has simply become a dynamic variable.

How to try out this feature

The fastest way is to take MariaDB 10.11 for a spin in docker / podman (consult the blog mariadb-replication-using-containers) with the following commands:

To start a primary 10.11.0 MariaDB container, clone the directory, navigate to the cloned directory and run the following command:

docker run -d –rm –name mariadb-primary \
-v $PWD/config-files/primarycnf:/etc/mysql/conf.d:z \
-v $PWD/primaryinit:/docker-entrypoint-initdb.d:z \
-v $PWD/log-files-primary:/var/lib/mysql \
-e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=True \
quay.io/mariadb-foundation/mariadb-devel:10.11

To start the replica/secondary run the command to start the mariadbd process as well as specify the replicate-rewrite-db option on the command line:

docker run -d –rm –name mariadb-secondary-1 \
-v $PWD/config-files/secondary-1:/etc/mysql/conf.d:z \
-v $PWD/secondaryinit:/docker-entrypoint-initdb.d:z \
-v $PWD/log-files-secondary-1:/var/lib/mysql \
-e MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=True \
quay.io/mariadb-foundation/mariadb-devel:10.11 –replicate-rewrite-db=’db1->db2′

Besides specifying the option as a command line argument, you can use a configuration file.

MariaDB & K8s: How to replicate MariaDB in K8s

In the previous blog we have seen how to create a statefulset MariaDB application. Also, we learned how replication works in MariaDB in this blog. Now, we will try to create a replicated statefulset application. As good references for creating this blog, I would like to give credit to the Kubernetes documentation as well as an example from Alibaba Cloud.

Configure replication

To replicate a MariaDB application we are going to create a statefulset that will consist of a single init container and one application container.

MariaDB replication using containers

In this blog we are going to demonstrate how to replicate a MariaDB database that runs in a Docker container (let’s call it primary) to one or more MariaDB servers that run in a Docker container (let’s call them replicas) using binary logging, a method that creates binary log files and an index that contains the record of all changes to the database (both data and structure). You can find an overview of how replication works here and you can find how to setup replication here. An example can be found in this GitHub script.

Create statefulset MariaDB application in K8s

In the previous blog we created a stateless application, deployed with K8s resource Deployment, which allows one to replicate the application, but where data is lost when Pods are restarted, meaning there were no data consistency. In the same blog we used PersistentVolumeClaim for dynamic provisioning of PersistentVolume, but we used Deployment, meant for stateless application, and this way is *not recommended* for statefulset application where each replica should have its own persistent volume. The proper way to achieve that is through the Statefulset resource and this post we will cover that.

In K8s one can create a stateful application, an application like a database, which needs to save data to persistent disk storage for use by the server/clients/other applications, to keep track of its state and to be able to replicate and be used in distributed systems.

MariaDB & K8s: Deploy MariaDB and WordPress using Persistent Volumes

In the previous blog, MariaDB & K8s: Create a Secret and use it in MariaDB deployment, we used the Secrets resource to hide confidential root user data, and in the blog before that in the series, MariaDB & K8s: Communication between containers/Deployments, we created 2 containers (namely MariaDB and phpmyadmin) in a Pod. That kind of deployment didn’t have any persistent volumes.

In this blog we are going to create separate Deployments for MariaDB and WordPress applications as well as a Service for both in order to connect them. Additionally we will create Volume in a Pods of a MariaDB Deployment.

MariaDB & K8s: Create a Secret and use it in MariaDB deployment

In the previous blog we created a stateless application, deployed it with K8s resource Deployment, and exposed the root password, which, regarding security, is of course not recommended. K8s allows one to hide confidential data using specific K8s resources.

Let’s see how to use Secrets in K8s.

Secrets in K8s

In order to save confidential data one can use a K8s resource called Secret.

One can create Secret from the CLI by running kubectl create secret.

Here we will use two methods to create the secret.

Quick peek: MariaDB Galera Cluster Security talk

Seppo Jaakola is going to present the topic “MariaDB Galera Cluster Security” at the Security MariaDB Server Fest (Wed 6 April 2022).

I’m currently watching his talk. Let me share with you some details. Seppo is not talking about native MariaDB security features that are by default supported by Galera, but due to the distributed cluster topology additional security related measures are needed. He talks about cluster topology, cluster communication security, Galera enhancement Data at REST encryption and the new 10.9 feature Node screening by IP Allowlist.

Do you have questions to ask Seppo?