Using Laradock
System Info:
Docker version: 17.10.0-ce, build f4ffd25
OS: Windows 10 Home
When I run docker-compose up -d mysql I'm getting error. Following is the docker logs
[Note] Basedir set to /usr/
[Warning] The syntax '--symbolic-links/-s' is deprecated and will be removed in a future release
[Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
[ERROR] --initialize specified but the data directory has files in it. Aborting.
[ERROR] Aborting
I have tried deleting mysql folder under ~/.laradock\data and didn't work.
Update 1
MySQL Container under laradock Dockerfile
mysql:
build:
context: ./mysql
args:
- MYSQL_VERSION=${MYSQL_VERSION}
environment:
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
- TZ=${WORKSPACE_TIMEZONE}
volumes:
- ${DATA_SAVE_PATH}/mysql:/var/lib/mysql
- ${MYSQL_ENTRYPOINT_INITDB}:/docker-entrypoint-initdb.d
ports:
- "${MYSQL_PORT}:3306"
networks:
- backend
MySQL Dockerfile
ARG MYSQL_VERSION=8.0
FROM mysql:${MYSQL_VERSION}
MAINTAINER Mahmoud Zalt <mahmoud#zalt.me>
#####################################
# Set Timezone
#####################################
ARG TZ=UTC
ENV TZ ${TZ}
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone
RUN chown -R mysql:root /var/lib/mysql/
ADD my.cnf /etc/mysql/conf.d/my.cnf
CMD ["mysqld"]
EXPOSE 3306
Update 2
After I delete mysql folder under ~/.laradock/data I'm getting following error. After the command it generates the files in below image. When I rerun giving back the previous error mentioned above.
[Note] Basedir set to /usr/
[Warning] The syntax '--symbolic-links/-s' is deprecated and will be removed in a future release
[Warning] 'NO_ZERO_DATE', 'NO_ZERO_IN_DATE' and 'ERROR_FOR_DIVISION_BY_ZERO' sql modes should be used with strict mode. They will be merged with strict mode in a future release.
[Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
[Warning] You need to use --log-bin to make --log-slave-updates work.
libnuma: Warning: /sys not mounted or invalid. Assuming one node: No such file or directory
mbind: Operation not permitted
[ERROR]
InnoDB: Operating system error number 22 in a file operation.
[ERROR] InnoDB: Error number 22 means
'Invalid argument'
[ERROR] InnoDB: File
./ib_logfile101: 'aio write' returned OS error 122. Cannot continue
operation
[ERROR] InnoDB: Cannot
continue operation.
** I tried in a windows 7 machine and its working.
Disable AIO
This fixed it for me when I got the AIO error as you did when I was starting a container from a guest Debian OS from Virtualbox and creating the database files on a shared folder on Windows 10.
The issue seems to be that AIO is not supported on shared folders, or at least on some versions of Windows. It seems to have occurred for me after I moved from Windows 10 Pro to Home after my main machine crashed.
For details:
aio
disable aio in MySQL for zfs
Here are some options:
Option 1 - start the container like this :
docker run -it mysql --innodb_use_native_aio=0
Option 2 - add the command to your docker-compose file:
command: --innodb_use_native_aio=0
In context, this is the relevant portion of my working docker-compose.yml:
services:
db:
image: ${MYSQL_IMAGE}
command: "--innodb_use_native_aio=0"
volumes:
- ${DB_DATA_PATH}:/var/lib/mysql
ports:
- ${MYSQL_PORT}:3306
Option 3 -- add an option to your my.cnf file in your build
innodb_use_native_aio=0
Option 4 - Don't persist your DB on the local file system.(Can destroy your db, Not Recommended)
Simply remove the volume in your docker configuration that contains your mysql db. Of course, your DB will be deleted if you do a docker-compose down or otherwise destroy your container, so there's that.
I am not sure but Try this step.This is because of data folder.
Try remove the docker image. List all images using docker images then remove the mysql & laradock mysql using docker rmi imagename. Dont forget remove the docker volume using docker volume rm volumename
Also go to cd ~/.laradock/data remove the mysql folder.
Then try docker-compose up mysql for debuging. If no errors, you could try docker-compose up -d mysql
I had the same problem with my Windows 10 Enterprise, I couldn't find perfect solution around it because it seems to be my Windows version issue - I have ran the same image on other windows (8 & 10 professional) successfully. My temporary work around was to remove the /var/lib/mysql mount entirely from the docker-compose file allowing the database data files to be created and modified in the container itself.
I use kitematics which will restart and reattach my created container anytime I want to work on the container, like that I don't loose my data when the container exit. If you don't use kitematics this what it does.
After running docker-compose the image will be created and a container will be created to run it as well, I avoid using run on the created image because this will create new container
I stick to running the following sequentially
docker ps -a # this command will get container_id of all container, those that are running and those that are not
docker start <container_id> # start container from background
docker attach <container_id> # attach container to standard input
With these docker commands my data were preserved in the container even after exiting and restarting
BACK UP
Now whenever I want to move the data, I will commit my container into an image and save the image to local storage
docker commit <container_id> <backup_image_name>:<1_31_2017> # I use date to tag it
docker save -o <local_storage_tar_name> <backup_image_name>
RESTORE
Whenever I need to restore the mysql container either on my computer or for a new programming intern
cd <dir_containing_the_tar_file>
docker load -o <local_storage_tar_name>
This solution is for your update
File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation
I hope this helps somebody
In addition to the response above by AndrewD, you should change the permission on the my.cnf so that it does not get ignored when booting up. You can run the below command,
sudo chmod 400 my.cnf
Do this right before running docker-compose up -d
Related
I'm trying to run a mysql docker container with persistent data mapped to a folder that is mounted through CIFS.
(I orginally posted a more general question but got a bit further in terms of user rights and now the error seems to be specific to innodb/cifs mounts. Hence I'm reposting this as a new topic. Thanks for life888888 for the initial help.)
Here is the command to start the container:
docker run \
--name localmysql \
-v /mnt/mysqlshare:/var/lib/mysql \
--rm \
--env MYSQL_ALLOW_EMPTY_PASSWORD=true \
-it \
mysql:8.0.31-debian
/mnt/mysqlshare is a mounted cifs share. The command to map the CIFS mount is below:
sudo mount -t cifs -o username=linuxmount,cache=none,vers=3.0,uid=999,gid=999,rw [networkpath] /mnt/mysqlshare
On the machine where docker is running I have a user set up called "mysql" which is the owner of the mapped cifs drive. It is configured to have 999 as uid and group (which ties to mysql-user in the docker container which is used by default).
When remoting into the container (interactive session) and changing to "su mysql" I'm able to write into /var/lib/mysql and changes are reflected in the mounted drive.
However when starting up the container I'm getting the following error which just keeps repeating:
2022-12-08T21:12:56.435340Z 0 [ERROR] [MY-012894] [InnoDB] Unable to open './#innodb_redo/#ib_redo0' (error: 11).
2022-12-08T21:12:56.435784Z 0 [ERROR] [MY-012574] [InnoDB] Unable to lock ./#innodb_redo/#ib_redo0 error: 13
There's files added to the folder:
I had that same issue on MariaDB and I'm having some success with the following (in docker-compose.yml file):
redacted-volume:
driver: local
driver_opts:
type: "cifs"
o: "mfsymlinks,vers=3.0,username=redacted,password=redacted,uid=999,gid=999"
device: "//192.168.4.204/docker-data/redacted/data-db"
mfsymlinks enables symlinks that MariaDB needs. uid and gid are Linux UserId and GroupId of MariaDB user that accesses the share. This works for me with Windows Server connecting to SMB shares from TrueNAS Scale. Docker version 20.10.22.
I still have this same issue with MySQL. I can't get it to work with this same configuration and I feel like I have looked everywhere on the internet.
I had a spring-boot project that used mysql docker-image so I didn't need to download the mysql benchwork. For other reasons I had to start over so I created a new project that uses the same mysql docker image I previously used.
My docker-compose.yml mysql service looks like this
version: "3.7"
services:
db:
image: mysql:5.7
command: --lower_case_table_names=1
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: farming_db
MYSQL_USER: root
MYSQL_PASSWORD: root
restart: always
volumes:
- "./database/farming_db/:/var/lib/mysql" #local
- farming_db:/var/lib/mysql/data #docker
ports:
- "3306:3306"
container_name: farming_mysql
networks:
- backend-network
When I run
docker-compose up
This is the error :
Attaching to farming_mysql, farming_server_springboot_1
farming_mysql | 2021-03-18 07:03:20+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.33-1debian10 started.
farming_mysql | 2021-03-18 07:03:20+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
farming_mysql | 2021-03-18 07:03:20+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.33-1debian10 started.
farming_mysql | 2021-03-18 07:03:21+00:00 [Note] [Entrypoint]: Initializing database files
farming_mysql | 2021-03-18T07:03:21.058436Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server opti
on (see documentation for more details).
farming_mysql | 2021-03-18T07:03:21.063630Z 0 [ERROR] --initialize specified but the data directory has files in it. Aborting.
farming_mysql | 2021-03-18T07:03:21.063710Z 0 [ERROR] Aborting
farming_mysql |
farming_mysql exited with code 1
springboot_1 |
I understood that my directory is not empty. I am trying to use "./database/farming_db/:/var/lib/mysql" and "farming_db:/var/lib/mysql/data" both as the volume directories. I think the problem is with the latter directory because the prior directory is empty. I'm having a problem deleting the contents in the latter directory because I don't know how to access it.
So this is what I've tried :
I deleted all the containers and then deleted all the volumes.docker volume prune but didn't work.
I searched that I could do rm -rf /usr/local/var/mysql but I don't know where I can execute this command since the container won't run properly at all.
I deleted the mysql image and just ran docker-compose up again. This seems to pull a new mysql image from somewhere? but I still get the same error. I guess volume directory has nothing do with the docker image itself.
I deleted the "- farming_db:/var/lib/mysql/data #docker" line from the docker-compose. But the same error is still occuring!
I'm using Windows10.
My question :
How can I access the directory? I don't know where to use the rm -rf command.
Why does this error still occur even when I erase "- farming_db:/var/lib/mysql/data #docker" from the docker-compose?
And also could anyone explain what I am doing? I'm new to docker and I don't really understand these volume problems.
Run docker system prune --volumes
This frees up the memory by removing all unused containers. Sometimes, the mentioned issue can occur due to memory limitations
Generally I emptied the volume's data directory and just changed the versions of the MySQL.
So in steps:
empty volume directory content
modify docker-compose.yml mysql version from 5.7 to 5.7.16
This line indicate that mysql container is storing the data inside a directory database in the same directory than your docker-compose.yml:
volumes:
- "./database/farming_db/:/var/lib/mysql" #local
This kind of volume isn't managed by Docker, it's just a directory in your filesystem, this is why docker volume prune doesn't work. I know that, because it starts with a "path" relative or absolute.
The other volume, farming_db, are managed by Docker. I know that because it starts with a simple name. This kinds of volume are managed by Docker and are removed with prune.
So, answering:
In the same directory than your docker-compose.yml you can remove that database folder.
Because the first volume, the one with /var/lib/mysql still exists. MySQL keeps all files inside this directory and any other child directory are a database.
You're just trying to put a container running and docker-compose hides a lot of details.
This is just a detail, but MYSQL_USER should be different than root.
You can let Docker manage the entire volume, creating a single volume to hold all data, in this case I named it as mysql_data:
volumes:
- mysql_data:/var/lib/mysql
Or, you can explore a bit more the docker run equivalent command to get used with it:
docker run -d --name mysql \
-e MYSQL_ROOT_PASSWORD=root \
-e MYSQL_DATABASE=farming_db \
-e MYSQL_USER=myuser \
-e MYSQL_PASSWORD=mypass \
-v mysql_data:/var/lib/mysql \
-p 3306:3306 \
mysql:5.7
As vencedor's answer, it worked for me. If anyone need stay with mysql 5.7, you can add these lines to your db service in docker-compose.yml:
- /etc/group:/etc/group:ro
- /etc/passwd:/etc/passwd:ro
user: "1000:1000"
I used docker-compose to run mysql image and encountered the error.
I use the following configuration to set volume.
- ./mysql/data:/var/lib/mysql/data
Then I changed it to the following and the error was solved.
- ./mysql:/var/lib/mysql
I'm running docker in Ubuntu and trying to create and run a MySql container. I want to use a mounted network share for the data directory. I am trying the following docker run command, but I'm having issues with permissions. How do I fix this?
root#jarvis:/mnt/wayne/mysql-data$ sudo docker run -it -p 3306:3306 -e MYSQL_ROOT_PASSWORD=admin -v /mnt/wayne/mysql:/var/lib/mysql/ --name mysqlserver mysql/mysql-server
[Entrypoint] MySQL Docker Image 8.0.20-1.1.16
[Entrypoint] Initializing database
2020-06-08T21:43:25.253898Z 0 [System] [MY-013169] [Server] /usr/sbin/mysqld (mysqld 8.0.20) initializing of server in progress as process 22
2020-06-08T21:43:25.281460Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2020-06-08T21:43:27.815075Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
mysqld: Cannot change permissions of the file 'ca.pem' (OS errno 1 - Operation not permitted)
2020-06-08T21:43:29.851875Z 0 [ERROR] [MY-010295] [Server] Could not set file permission for ca.pem
2020-06-08T21:43:29.852970Z 0 [ERROR] [MY-013236] [Server] The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
2020-06-08T21:43:29.854806Z 0 [ERROR] [MY-010119] [Server] Aborting
2020-06-08T21:43:31.947298Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.20) MySQL Community Server - GPL.
You use CIFs for network mount means the remote server is windows right? My answer is based on this assumption.
The latest mysql docker image has a user named mysql and its uid=27,gid=27
You verify this by mounting an empty folder as data_dir. You will see that the files created by mysql container has user and group is as 27.
Hence the mysql container expects files with uid/gid(owner userid and owner group id) as 27 in its data_dir. But the files that you mounted from the windows share has uid/gid which belongs to the user that executes mount command in ubuntu. This is the default behavior of mount command.
To solve this you need to pass "uid=27,gid=27" parameters to the Linux mount command.
For instance
sudo mount -t cifs -o
username=windows-username,uid=27,gid=27
//WIN_SHARE_IP/ /mnt/wayne
You can have look here for further details
I must say it is unlikely to run mysql over a network share. It won't perform well.
This is not exactly with MySQL but I hope it can give you an idea, I basically use this for testing against a MySQL database from my local environment, for this I use docker-compose and MariaDB, I configure the "data-dir" as a volume so that I can stop/start the docker container without the need to "seed" every time the database.
This is the content of the /your/path/docker-compose.yml file:
---
version: '3'
services:
mariadb:
image: mariadb:10.4.13
container_name: mariadb
restart: always
ports:
- 13306:3306
environment:
MYSQL_DATABASE: world
MYSQL_ROOT_PASSWORD: test
command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
volumes:
- ${PWD}/mariadb/db/:/var/lib/mysql
In the same directory, I have the volume directory /your/path/mariadb/db
Then to bring up the container I use:
$ docker-compose up
From the docker-compose.yml has you can see I use port 13306 therefore for testing/connection I use:
$ mysql -h 127.0.0.1 -P13306 -uroot -p
All the data (databases) will be in /your/path/mariadb/db
If you run into the same "permissions" problem:
mysqld: Cannot change permissions of the file 'ca.pem' (OS errno 1 - Operation not permitted)
Try to change the permissions of your volume/mount point, for example:
chmod -R 777 /your/volume/mount_point
okay, I tried this and google also, what I found is
https://github.com/docker-library/mysql/issues/302#issuecomment-308745834
So basically if you are using mysql:5.7 then upgrade to mysql:5.7.16.
And if this doesn't help then I have one more solution.
Basically the problem is you are sharing dir to container -v /mnt/wayne/mysql:/var/lib/mysql/ but you ubuntu is not giving permission to access the /mnt/wayne/mysql dir. so give admin permission to this location or you can create a docker user chown and chmode.
Basically give permission to the host machine directory. so that docker container can access it.
and One more thing give permission to the docker container dir also, that is showing in your error
The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
Create a user in a docker container which have chown and chmod permissions to the dir /var/lib/mysql/.
if you are using dockerfile to create mysql container then use these following 2 lines in it
FROM mysql:5.7.16
WORKDIR /app
RUN chown -R admin:admin /app
RUN chmod 755 /app
USER admin
CMD ["Your command"]
To operate normally, MariaDB or MySQL needs to set some permissions on their own files. Some external file systems (such as FTP and many others) do not support these features. You need to use a file system which supports these features.
there is a permission issue to access the mounted volume. Please read the documentation about use volumes:
https://docs.docker.com/storage/volumes/#use-a-volume-driver
For NFSv3 Partition:
$ docker service create -d \
--name nfs-service \
--mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,volume-opt=o=addr=10.0.0.10' \
nginx:latest
Or check the CA.pem file permissions (use chmod 777 /path/to/ca.pem)
For NFSv4 Partition:
docker service create -d \
--name nfs-service \
--mount 'type=volume,source=nfsvolume,target=/app,volume-driver=local,volume-opt=type=nfs,volume-opt=device=:/var/docker-nfs,"volume-opt=o=10.0.0.10,rw,nfsvers=4,async"' \
nginx:latest
Check https://docs.docker.com/storage/volumes/#use-a-volume-driver
I have a docker-compose.yml with a MariaDB database service that looks like this:
version: '2'
services:
db:
container_name: misp_db
image: mariadb
restart: unless-stopped
volumes:
- ${DATA_DIR}/db:/var/lib/mysql
environment:
- MYSQL_DATABASE=${MYSQL_DATABASE}
- MYSQL_USER=${MYSQL_USER}
- MYSQL_PASSWORD=${MYSQL_PASSWORD}
- MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
When spinning up my containers, I noticed these errors:
[ERROR] Missing system table mysql.roles_mapping; please run mysql_upgrade to create it
[ERROR] Incorrect definition of table mysql.event: expected column 'sql_mode' at position 14 to have type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','IGNORE_BAD_TABLE_OPTIONS','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVALID_DATES','ERROR_FOR_DIVISION_BY_ZERO','TRADITIONAL','NO_AUTO_CREATE_USER','HIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH','EMPTY_STRING_IS_NULL','SIMULTANEOUS_ASSIGNMENT'), found type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_B
[ERROR] mysqld: Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
I was able to work around this problem by running docker exec -it db /bin/bash to get a shell, and then running mysql_upgrade -p and entering my configured MySQL root password, but this should be automated.
How can I do this in Docker Compose?
You can't run it directly from the docker-compose but it can be done rather simply using a one-line Dockerfile called from docker-compose.
This can be done by simply adding the following to your service definition in the docker-compose.yaml file:
build: .
This will cause docker-compose to run the Dockerfile located in the working directory ".".
In the Dockerfile, you can then run the upgrade script itself.
RUN mysql_upgrade -p
This will cause the upgrade to be run once; while building the image. Subsequently, your mySQL version will be frozen at the time you build the image; not when you start the container. This seems like a reasonable approach to me.
You could run an entrypoint.sh script from the Dockerfile (see here for more details), which gets called when you start the container. That would perform the upgrade when you start the container as you originally requested but, I agree with #blokje5, upgrading when starting the container seems a bit risky. If they accidentally break something (it happens), then an image that once worked would no longer be working and that can be a bit of a nightmare to debug; especially since it's happening before the service is considered ready.
I have a mysql 5.7 docker container. When I run the mysql command:
SELECT now();
It shows the time -3 hours to my current time (which is logical). I want to set the time zone in a config file. Following the documentation in https://hub.docker.com/_/mysql/ I create a volume in my docker-compose.yml file like the following:
mysqldb:
image: mysql:5.7.21
container_name: mysql_container
ports:
- "3306:3306"
volumes:
- ./.docker/etc/mysql/custom.cnf:/etc/mysql/conf.d/custom.cnf
When I browse the files inside the container the file custom.cnf is there.
In that file, I tried some of the ways I found as solutions like:
[mysqld]
default_time_zone='Europe/Sofia'
or a compromise solution which is less elegant as the zone will have to be changed twice a year (summer / winter):
[mysqld]
default_time_zone='+03:00'
but none works. I have the sensation the this file is not loaded by mysql at all because if I try to put invalid configuration in there nothing happens either (the container starts normally).
Any suggestions on that?
So you need to use a Dockerfile in this case and handle it like below
FROM mysql:5.7.21
RUN echo "USE mysql;" > /docker-entrypoint-initdb.d/timezones.sql && mysql_tzinfo_to_sql /usr/share/zoneinfo >> /docker-entrypoint-initdb.d/timezones.sql
This makes sure that when the mysql container loads it will load all the timezone info. Now you can use it using environment variables
Environment variable
mysqldb:
#image: mysql:5.7.21
build: .
#container_name: mysql_container
ports:
- "3306:3306"
environment:
- MYSQL_ROOT_PASSWORD=root
- TZ=Europe/Sofia
To use it with a config file is a problem. When you start the DB it will give your an error
mysqldb_1 | 2018-04-24T12:29:43.169214Z 0 [Warning] InnoDB: New log files created, LSN=45790
mysqldb_1 | 2018-04-24T12:29:43.215187Z 0 [Warning] InnoDB: Creating foreign key constraint system tables.
mysqldb_1 | 2018-04-24T12:29:43.281229Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 2a87fec6-47bb-11e8-9f1e-0242ac110002.
mysqldb_1 | 2018-04-24T12:29:43.284010Z 0 [Warning] Gtid table is not ready to be used. Table 'mysql.gtid_executed' cannot be opened.
mysqldb_1 | 2018-04-24T12:29:43.284404Z 0 [ERROR] Fatal error: Illegal or unknown default time zone 'Europe/Sofia'
mysqldb_1 | 2018-04-24T12:29:43.284567Z 0 [ERROR] Aborting
This is because it needs the timezone to have been already loaded. It is possible to fix this also, but too much of hassle. I will go with the environment variable only as that means when the container starts the timezone is already setup.
The mariadb:10.3 docker container interprets the TZ environment variable, although it's not mentioned on the Readme.md for the docker image. In my case providing the value of America\New_York worked perfectly.
value should be
default_time_zone=Europe/Sofia
check details
But this could give you error like this while restarting the mysql service so you should use below command before editing custom.cnf file.
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p
For me, I'm using Keramatic https://kitematic.com configure by click on MySQL container General and add TZ specify with your current time show list in https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
Cheers