Writing User-Defined Functions in Rust

One of the most straightforward ways to add functionality to MariaDB or MySQL server instances is by creating a user-defined function (UDF). These are compiled functions loaded from dynamic binaries that can be much more performant and flexible than what can be written in SQL, providing the same capabilities as builtin functions.

These UDFs are typically written in C or C++, but a library is now available that makes it easy to write them in Rust. This blog discusses some of the reasoning for writing this library, followed by a very basic usage example that doesn’t require any experience with the language.

Going for a Code of Conduct

It may be long overdue, but based on recent events, we have launched Code of Conduct project at MariaDB Foundation. Our aim is to get your feedback and define a CoC, ideally by end of January, if we see convergence.

In the meantime, if we see unacceptable behaviour on the MariaDB mailing list or elsewhere, we will take action. We want to extend our apology to those who have had unpleasant experiences, about which we have done nothing in the past.

As for the code of conduct wording, our goal is to keep it short. Lofty goals often trigger distractive debates;

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.

GRANT TO PUBLIC in MariaDB

MariaDB 10.11.0, our latest preview release, features quite a number of improvements. The one we’ll talk about today is GRANT … TO PUBLIC.

Background

MariaDB has quite a complex privilege system. Most of it is based on the SQL Standard spec; however we do have some specific MariaDB extensions. GRANT … TO PUBLIC (MDEV-5215) is a standard feature that is now available as a preview in MariaDB 10.11.0. It is related to ROLES and DEFAULT ROLE, but it covers a different use case.

ROLES are effectively “privilege packages” that you can enable and disable as a user.

Regressions in recent MariaDB Server releases

Our most recent MariaDB Server release introduced some regressions starting with the 10.6 series, affecting 10.7 – 10.9 as well. This blog post is here to explain the problems in hopes that the impact is minimized. We are likely going to release a new version of MariaDB correcting these problems soon.

InnoDB Full Text Index on tables causes an assertion error (MDEV-29342)

There was a bug in the InnoDB Storage Engine where the full text index could go out of sync with the actual table data. This would happen when only one new row was inserted between the last InnoDB sync (which happens asynchronously) and a server shutdown.

The Path to Code Contributions in MariaDB Server

I have been working for the MariaDB Foundation as the Chief Contributions Officer for a couple of weeks and it is fantastic being part of the MariaDB family again. Part of my job is to help the community massage pull requests into something that we can merge. I am, however, finding that one of the worst parts of my job is having to say “no” to contributions that clearly took a lot of time and effort on the part of the developer.

Contributions could be turned down or at least will require changes for a number of reasons.

Contribution Wish List

Would you like to contribute to the MariaDB Server code base, its feature set, its quality? Here’s what you can do to help – in other words, here’s our Contribution Wish List

Scratching your own itch

The assumption around code contributions is usually that the code contributor extends the product in a direction that corresponds to the contributor’s own needs, which in turn are close to the needs of other users. “Scratching your own itch” is the phrase commonly used.

Some itches are more for the common good

That said, we have also been approached by potential providers of contributions that would take a more general approach.

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.