Bug 256112 - new port: databases/mariadb106-server
Summary: new port: databases/mariadb106-server
Status: In Progress
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bernard Spil
Depends on:
Reported: 2021-05-23 22:53 UTC by Vincent Milum Jr
Modified: 2021-07-08 03:59 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Milum Jr 2021-05-23 22:53:27 UTC
MariaDB just released version 10.6.1 BETA a couple days ago. I don't think we should have these beta versions in the main ports tree until they're deemed stable. HOWEVER, I do think these should still have some level of testing prior to their full release status, so we're not scrambling to adapt to all the new changes. As such, I've added mariadb106-client and mariadb106-server to my personal Ports collection that is publicly available.

The most notable changes are the Galera Cluster WSREP scripts have had a massive overhaul. As such, the 10.5 and earlier FreeBSD ports modifications to these files no longer applies. I've yet to test the new upstream WSREP scripts to see if they work.

So far, I've compiled the mariadb106-client and mariadb106-server port successfully and launched them both on my Aarch64 server under FreeBSD 14-CURRENT. But I've yet to issue any SQL queries other than checking server status.

More testing would be GREATLY appreciated!

My personal ports collections:

For this to work, the base FreeBSD ports tree should also be installed.

You'll need to modify the following file:

And add the line:

After that, everything should compile, install, and run!
Comment 1 Bernard Spil freebsd_committer 2021-05-24 18:49:54 UTC
Thanks Vincent! Much appreciated.

I'll provide feedback soon, prod me if I dont!
Comment 2 Vincent Milum Jr 2021-05-24 19:08:14 UTC
One quick hack that I did that'll probably need updating is in "patch-tpool_CMakeLists.txt"

tpool/CMakeLists.txt was modified heavily upstream. So for a quick fix, I just put the "ADD_DEFINITIONS(-fPIC)" line at the top of the file, rather than finding a true appropriate location for it.

Most of the other patches were left in unchanged. I dont recall off the top of my head, but one or two of the FreeBSD patches were added upstream, so those files have been removed from the port.

I'll probably start on WSREP testing sometime this week, as I deploy 10.6.1 on my personal test cluster.
Comment 3 Vincent Milum Jr 2021-05-26 19:19:48 UTC
I'm trying my first Galera SST today, and it isn't going well.

On the receiving node, it has started rsync and that looks good. But no other existing node in the cluster is in the donor state. The receiving node simply waits indefinitely.

I've not dug into logs yet, but at least for now I can indeed confirm WSREP is broken.
Comment 4 Vincent Milum Jr 2021-06-19 00:27:23 UTC
I've updated my port to 10.6.2, but I've yet to investigate the issues with with the Galera WSREP scripts.
Comment 5 Vincent Milum Jr 2021-07-07 05:20:24 UTC
10.6.3 is GA, and needs 1 additional patch since they have a broken return value in one file. I'll get that fixed up in my personal ports collection soon.

Also, Galera WSREP SST is still broken on FreeBSD, still have not had a chance to diagnose exactly why. I've created an upstream bug report for it: https://jira.mariadb.org/browse/MDEV-26101
Comment 6 Vincent Milum Jr 2021-07-08 03:59:42 UTC
Some more updates to the port in my personal repo.

All options except for Columnstore are now compiling.

All options except for Columnstore and RocksDB are now compiling.

I previously worked in porting RocksDB for Aarch64 upstream a while ago, but I don't know how much of that work has been imported into the upstream MariaDB tree yet (last I checked, none of that work was imported). I'll have to pull up my notes again soon and merge them in as a ports patch set most likely.

For Columnstore, there are at least two issues right now.

1) There is a problem with one of the C++ templates, I think GCC vs LLVM handles it differently. This needs to be validated and hopefully a solution found.

2) There are now a bunch of Linuxisms for no good reason. They're using CGroups to query the number of CPU cores and free RAM, which can be queried otherwise. So this will need patching as well.

No fixes for Galera WSREP SST either as of yet. I've now opened this as a bug upstream: