An intra-pandemic Staff Meeting

Well over two years ago was the last time the MariaDB Foundation staff had met. That was at FOSDEM, in February 2020. Thus, no big surprise, one of our topmost goals for 2022 was to have a staff meeting, face to face. It’s about time to oil the social relationships, to work together without connection issues, to be reminded of how work and life can be in a world where Covid isn’t the top issue.

In other words: we planned a post-pandemic Staff Meeting.

The outcome was different. 

Choosing the venue

But let us start from the beginning, from the original euforia.

We’re hiring: Senior MariaDB Developer / Code Reviewers

Yes, we are hiring! 

And we are hiring for quite an interesting position: As a senior developer of MariaDB Server, with merging community code contributions as a main task.

A demanding job

This is a very demanding job. The MariaDB Server code base is large and complex, and being a good C / C++ developer is only the starting point for being able to contribute to it. You also need to understand databases, and the existing codebase architecture.

A demanding code base

The existing codebase is demanding. Depending on how you look at it, it’s either very efficient (if you know it well), or it has many dependencies (if you don’t).

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.

Contributions, our lifeblood

The lifeblood of MariaDB Foundation is contributions. Our trinity consists of the fundamental values of Adoption (of MariaDB Server), Openness (of the MariaDB Server codebase), and Continuity (of our operations and activities), all of which are centered around MariaDB Server. We rely on our financial sponsors to finance our activities, but the financial value of the code contributions we receive outshines the total sponsorship payments. That has been the case every year since MariaDB Server was launched.

Giving recognition to code contributions

The MariaDB Foundation has not given proper recognition to this fact, of the value of our contributions.

China Has Great Potential for MariaDB Server

Our Board Meeting in April 2022 elected two seasoned new voting board members. One of them is Xiang Peng (Sean), Director, RDS Open Source Databases at Alibaba Cloud. I had the pleasure of having a Fireside Chat with him, which we recorded and put up on YouTube. Read on for his recommendations for MariaDB Foundation in China.

A Man With the Right CV for MariaDB Foundation

Sean, as he calls himself for those of us who have problems remembering, reading or writing his real name 彭祥, is a great resource for MariaDB Foundation.

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.