Mariadb/docker error : Can’t init tc log

Woohoo, I found it! For now, at least. Digging through the source suggests that this might have something to do with mmap() calls, and lo and behold - VirtualBox has a bug in that area. Fortunately that same source hints at a workaround - the log_bin option. Enable this (either from the command line as --log_bin or from the config file as log_bin=ON) and things start to work again!

Update

They're saying they've fixed it in VirtualBox 6.0.6!

I've come up with an answer for this - it seems like a bit of a hack, but it seems to work.

To recap: the goal was to set up a master with a single slave using MariaDB 10.3.4 (in Docker containers, although this isn't necessarily a requirement) from scratch (ie. newly-installed, empty databases), so that the system will simply start up and work without any errors. I wanted to use MariaDB's global transaction IDs.

The issue I was encountering was that some of the queries were failing because users already existed in the database (having been set up as part of the Docker container initialization). When the master sent the queries for creating these users, the slave failed since these rows already exist in the mysql.users table.

The solution was to simply drop those users before executing the CHANGE MASTER statement. Here's the SQL which the slave runs at startup:

-- drop the application user
DROP USER IF EXISTS 'myuser'@'%';
-- drop the root user
DROP USER IF EXISTS 'root'@'localhost';

CHANGE MASTER TO
    MASTER_HOST='database',
    MASTER_USER='replicant',
    MASTER_PASSWORD='password',
    MASTER_PORT=3306,
    MASTER_USE_GTID=slave_pos,
    MASTER_CONNECT_RETRY=10;

Trial and error revealed that those were the two users that were failing.

One issue that comes up with this configuration: once the slave finishes its initial sync, you can no longer log in as root@localhost. There are a couple of solutions to this:

1. log in as root@slave_hostname, or
2. create a new user which is unique to the slave which has root privileges.