0

I am initializing a new MariaDB database. Running docker with a volume to my home directory allows MariaDB to start up just fine:

docker run -it --rm --name mymaria \
  -e MYSQL_RANDOM_ROOT_PASSWORD=yes \
  -e MYSQL_PASSWORD=p@$$w0rd \
  -e MYSQL_DATABASE=myapp \
  -e MYSQL_USER=myapp \
  -v /home/myuser/mysql:/var/lib/mysql \
  mariadb:10.2

However, running the mariadb container with a volume via a mounted directory like so:

docker run -it --rm --name mymaria \
  -e MYSQL_RANDOM_ROOT_PASSWORD=yes \
  -e MYSQL_PASSWORD=p@$$w0rd \
  -e MYSQL_DATABASE=myapp \
  -e MYSQL_USER=myapp \
  -v /mnt/storage/mysql:/var/lib/mysql \
  mariadb:10.2

This configuration returns this from the docker logs output:

Initializing database
2019-09-23  5:12:13 139724696503616 [ERROR] Can't init tc log
2019-09-23  5:12:13 139724696503616 [ERROR] Aborting


Installation of system tables failed!
...

Simply removing tc.log as some folks have suggested does not work. Restarting mariadb will rewrite tc.log back into the volume /var/lib/mysql.

Perhaps this is a permissions issue? I feel like I've tried every combination of chown with each directory.

I encounter this issue only with the 10.2 tag and not the latest. However, for an orchestration I'm working on, it suggests mariadb:10.2.

3
  • I previously posted this question in SuperUser and DBA. I've deleted those questions as this is probably the best place for this issue. Sep 24 '19 at 16:54
  • /mnt/storage/mysql what kind of storage is?
    – c4f4t0r
    Sep 24 '19 at 16:58
  • @c4f4t0r It's a mounted xfs drive connected via sata. Everything appears to get written to /mnt/storage/mysql by mariadb, until it hits the tc.log file Sep 25 '19 at 0:13
1

Background

In my situation, I was using mergerfs to combine a variety of disks into a single file system. One of its features direct_io inhibits mmap and is likely what causes the fatal error. There are similar conflicts with other software that use mmap as pointed out by the mergerfs documentation.

Mmap is a used in MariaDB and is not supported by all filesystems. I believe in later versions mmap is no longer used, so in my own tests I only ran into this issue with mariadb:10.2.

This background may help others using mergerfs or with similar issues causing conflicts with mmap in MariaDB.

Possible Solutions

1. Allow mmap to work

In my scenario this requires disabling a now deprecated feature called direct_io which bypasses page cache. According to the mergerfs documentation, this is recommended.

2. Activate Binary Log

This can be tested with either a configuration file or as a command to the container's process. I tested this by adding the --log-bin command:

docker run -it --rm --name mymaria \
  -e MYSQL_RANDOM_ROOT_PASSWORD=yes \
  -e MYSQL_PASSWORD=p@$$w0rd \
  -e MYSQL_DATABASE=myapp \
  -e MYSQL_USER=myapp \
  -v /mnt/storage/mysql:/var/lib/mysql \
  mariadb:10.2 --log-bin --log-basename=some_hostname

3. Move the volume elsewhere

While not ideal, this is an option. Either use a volume on the host or another disk. My particular issue with the MariaDB volume was because of a conflict between two different pieces of software.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.