Tried running a mariadb container by mounting a host directory but does not even start with no logs. My goal is to not lose the data.
$ docker run -e MYSQL_ROOT_PASSWORD=user -v //c/Users/docker-workspace/mariadb-data-dir:/var/lib/mysql -d mariadb
$ docker logs 9309b32a7582
2016-01-28 4:48:44 139801728346048 [Note] mysqld (mysqld 10.1.10-MariaDB-1~jessie) starting as process 1 ...
2016-01-28 4:48:44 139801728346048 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: The InnoDB memory heap is disabled
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Memory barrier is not used
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Using Linux native AIO
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Using SSE crc32 instructions
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Completed initialization of buffer pool
2016-01-28 4:48:44 139801728346048 [Warning] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Highest supported file format is Barracuda.
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: 128 rollback segment(s) are active.
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Waiting for purge to start
2016-01-28 4:48:44 139801728346048 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-76.0 started; log sequence number 1600729
2016-01-28 4:48:44 139800942184192 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-01-28 4:48:44 139801728346048 [Note] Plugin 'FEEDBACK' is disabled.
2016-01-28 4:48:44 139801728346048 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2016-01-28 4:48:44 139801728346048 [Note] Recovering after a crash using tc.log
2016-01-28 4:48:44 139801728346048 [ERROR] Can't init tc log
2016-01-28 4:48:44 139801728346048 [ERROR] Aborting
Data volumes don't work either.
docker create -v //c/Users/docker-workspace/mariadb-data-dir:/var/lib/mysql --name docker-mariadb-data hello-world
MINGW64 ~
$ docker inspect docker-mariadb-data
[
{
"Id": "eff843a06bbe4b5cfb575ca095572d4dba735ce3e4ddd84ffa02a8bb7ae2ba76",
"Created": "2016-01-28T04:44:09.997407335Z",
"Path": "/hello",
"Args": [],
"State": {
"Status": "created",
"Running": false,
"Paused": false,
"Restarting": false,
"OOMKilled": false,
"Dead": false,
"Pid": 0,
"ExitCode": 0,
"Error": "",
"StartedAt": "0001-01-01T00:00:00Z",
"FinishedAt": "0001-01-01T00:00:00Z"
},
"Image": "0a6ba66e537a53a5ea94f7c6a99c534c6adb12e3ed09326d4bf3b38f7c3ba4e7",
"ResolvConfPath": "",
"HostnamePath": "",
"HostsPath": "",
"LogPath": "",
"Name": "/docker-mariadb-data",
"RestartCount": 0,
"Driver": "aufs",
"ExecDriver": "native-0.2",
"MountLabel": "",
"ProcessLabel": "",
"AppArmorProfile": "",
"ExecIDs": null,
"HostConfig": {
"Binds": [
"//c/Users/docker-workspace/mariadb-data-dir:/var/lib/mysql"
],
"ContainerIDFile": "",
"LxcConf": [],
"Memory": 0,
"MemoryReservation": 0,
"MemorySwap": 0,
"KernelMemory": 0,
"CpuShares": 0,
"CpuPeriod": 0,
"CpusetCpus": "",
"CpusetMems": "",
"CpuQuota": 0,
"BlkioWeight": 0,
"OomKillDisable": false,
"MemorySwappiness": -1,
"Privileged": false,
"PortBindings": {},
"Links": null,
"PublishAllPorts": false,
"Dns": null,
"DnsOptions": null,
"DnsSearch": null,
"ExtraHosts": null,
"VolumesFrom": null,
"Devices": [],
"NetworkMode": "default",
"IpcMode": "",
"PidMode": "",
"UTSMode": "",
"CapAdd": null,
"CapDrop": null,
"GroupAdd": null,
"RestartPolicy": {
"Name": "no",
"MaximumRetryCount": 0
},
"SecurityOpt": null,
"ReadonlyRootfs": false,
"Ulimits": null,
"LogConfig": {
"Type": "json-file",
"Config": {}
},
"CgroupParent": "",
"ConsoleSize": [
0,
0
],
"VolumeDriver": ""
},
"GraphDriver": {
"Name": "aufs",
"Data": null
},
"Mounts": [
{
"Source": "/c/Users/docker-workspace/mariadb-data-dir",
"Destination": "/var/lib/mysql",
"Mode": "",
"RW": true
}
],
"Config": {
"Hostname": "eff843a06bbe",
"Domainname": "",
"User": "",
"AttachStdin": false,
"AttachStdout": true,
"AttachStderr": true,
"Tty": false,
"OpenStdin": false,
"StdinOnce": false,
"Env": null,
"Cmd": [
"/hello"
],
"Image": "hello-world",
"Volumes": null,
"WorkingDir": "",
"Entrypoint": null,
"OnBuild": null,
"Labels": {},
"StopSignal": "15"
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "",
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"Ports": null,
"SandboxKey": "",
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "",
"Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "",
"IPPrefixLen": 0,
"IPv6Gateway": "",
"MacAddress": "",
"Networks": null
}
}
]
$ winpty docker run --volumes-from docker-mariadb-data -e MYSQL_ROOT_PASSWORD=user -p 3306:3306 -d mariadb
$ docker logs 34f8e5e53db5
2016-01-28 7:46:26 140139439015872 [Note] mysqld (mysqld 10.1.10-MariaDB-1~jessie) starting as process 1 ...
2016-01-28 7:46:26 140139439015872 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: The InnoDB memory heap is disabled
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Memory barrier is not used
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Using Linux native AIO
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Using SSE crc32 instructions
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Completed initialization of buffer pool
2016-01-28 7:46:26 140139439015872 [Warning] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Highest supported file format is Barracuda.
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: 128 rollback segment(s) are active.
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Waiting for purge to start
2016-01-28 7:46:26 140139439015872 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.26-76.0 started; log sequence number 1600739
2016-01-28 7:46:26 140138654959360 [Note] InnoDB: Dumping buffer pool(s) not yet started
2016-01-28 7:46:26 140139439015872 [Note] Plugin 'FEEDBACK' is disabled.
2016-01-28 7:46:26 140139439015872 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
2016-01-28 7:46:26 140139439015872 [Note] Recovering after a crash using tc.log
2016-01-28 7:46:26 140139439015872 [ERROR] Can't init tc log
2016-01-28 7:46:26 140139439015872 [ERROR] Aborting
Now, I cannot save the changes in MariaDB in windows.
+1
No fix for this isssue ?
It looks like this is specifically mariadb 10.1. If I change the ids for mysql user and group in the mariadb images to 1000:50 so that it matches the vbox shared folder, I am able to get mariadb 10.0 and 5 to work with a volume mounted to the host. If you are just looking for persistence between restarts then a named volume should work docker run -d -v mariadb-data:/var/lib/mysql/ -e MYSQL_ROOT_PASSWORD=user mariadb. As long as you don't docker rm -v the container the volume should stick around (also don't do a docker run -it --rm -v mariadb-data:/... since that would delete the volume when it stops).
I used the user/group id changing that was described here: https://github.com/docker-library/mysql/issues/99#issuecomment-145665645.
@tianon why was this closed? It appears this is still an issue.
mariadb service:
mariadb:
user: "1000:50"
image: mariadb
env_file:
- ./env/mariadb.env
volumes:
- ./store/mysql:/var/lib/mysql
docker-compose up:
โ docker-compose up --force-recreate
Recreating XXXXX20_mariadb_1
Recreating XXXXX20_phpfpm_1
Recreating XXXXX20_nginx_1
Attaching to XXXXX20_mariadb_1, XXXXX20_phpfpm_1, XXXXX20_nginx_1
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] mysqld (mysqld 10.1.21-MariaDB-1~jessie) starting as process 1 ...
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
phpfpm_1 | [24-Feb-2017 02:32:30] NOTICE: fpm is running, pid 1
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Using mutexes to ref count buffer pool pages
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: The InnoDB memory heap is disabled
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Compressed tables use zlib 1.2.8
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Using Linux native AIO
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Using generic crc32 instructions
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Initializing buffer pool, size = 256.0M
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Completed initialization of buffer pool
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Warning] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Highest supported file format is Barracuda.
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: 128 rollback segment(s) are active.
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Waiting for purge to start
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.34-79.1 started; log sequence number 1600709
mariadb_1 | 2017-02-24 2:32:29 139801009293056 [Note] InnoDB: Dumping buffer pool(s) not yet started
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] Plugin 'FEEDBACK' is disabled.
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [Note] Recovering after a crash using tc.log
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [ERROR] Can't init tc log
mariadb_1 | 2017-02-24 2:32:29 139801783801792 [ERROR] Aborting
mariadb_1 |
XXXXX20_mariadb_1 exited with code 1
@MarkehMe this was closed because it looks like we've done as much as we possibly can from the perspective of this image to make this work and that there's not really anything else we _can_ do :disappointed:
Hi all! The info here https://github.com/docker-library/percona/issues/42 suggests that this indeed might be an image-related bug. It seems to work with mysql:8 and other mariadb images. Do we know why this is happening?
version 10.1.22
Use -it option instead of -d to get console message output.
Seems something went wrong when writing file "ibdata1" to host storage.
The folder "MariaDB" does not have any exist files when I execute this command.
Command:
docker run --name db -e MYSQL_ROOT_PASSWORD=test -e MYSQL_DATABASE=test -e MYSQL_USER=eavictor -e MYSQL_PASSWORD=test -v /d/MariaDB:/var/lib/mysql -it -p 3306:3306 mariadb:latest --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci > "C:\Users\eavictor\Desktop\mariadb-docker_error-log.txt"
Error Log (complete):
Initializing database
2017-05-03 15:11:06 140715339528128 [Note] /usr/sbin/mysqld (mysqld 10.1.22-MariaDB-1~jessie) starting as process 59 ...
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Using mutexes to ref count buffer pool pages
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: The InnoDB memory heap is disabled
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Compressed tables use zlib 1.2.8
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Using Linux native AIO
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Using SSE crc32 instructions
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Initializing buffer pool, size = 256.0M
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Completed initialization of buffer pool
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created!
2017-05-03 15:11:06 140715339528128 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB
2017-05-03 15:11:06 7ffad7d3b7c0 InnoDB: Error: Write to file ./ibdata1 failed at offset 0.
InnoDB: 1048576 bytes should have been written, only 0 were written.
InnoDB: Operating system error number 22.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk quota exceeded.
InnoDB: Error number 22 means 'Invalid argument'.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html
2017-05-03 15:11:06 140715339528128 [ERROR] InnoDB: Error in creating ./ibdata1: probably out of disk space
2017-05-03 15:11:06 140715339528128 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data!
2017-05-03 15:11:06 140715339528128 [ERROR] Plugin 'InnoDB' init function returned error.
2017-05-03 15:11:06 140715339528128 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2017-05-03 15:11:06 140715339528128 [ERROR] Unknown/unsupported storage engine: InnoDB
2017-05-03 15:11:06 140715339528128 [ERROR] Aborting
Installation of system tables failed! Examine the logs in
/var/lib/mysql/ for more information.
The problem could be conflicting information in an external
my.cnf files. You can ignore these by doing:
shell> /usr/scripts/scripts/mysql_install_db --defaults-file=~/.my.cnf
You can also try to start the mysqld daemon with:
shell> /usr/sbin/mysqld --skip-grant --general-log &
and use the command line tool /usr/bin/mysql
to connect to the mysql database and look at the grant tables:
shell> /usr/bin/mysql -u root mysql
mysql> show tables;
Try 'mysqld --help' if you have problems with paths. Using
--general-log gives you a log in /var/lib/mysql/ that may be helpful.
The latest information about mysql_install_db is available at
https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
MariaDB is hosted on launchpad; You can find the latest source and
email lists at http://launchpad.net/maria
Please check all of the above before submitting a bug report
at http://mariadb.org/jira
Hi @yosifkit
I was able to run it on a specific version of mariadb that doesn't even require the script that changes the ids for mysql user and group because it doesn't create tc.log file on the data directory.
Version I used: mariadb:10.0.22
Obviously this doesn't fix the problem with boot2docker, and I tried using the script, etc as per the other solutions but nothing worked, except for the version I mentioned above.
hi @mario-rivera,
For boot2docker, we adjusted the image to be able to start as any user with https://github.com/docker-library/mariadb/pull/59 so the script I mentioned is no longer necessary. You can just run it on Windows or Mac when using boot2docker:
$ docker run -d -v C:/Users/....:/var/lib/mysql --user 1000:50 -e MYQSL_ROOT_PASSWORD=secr3t martiadb:10.0
Unfortunately, there is something not related to permissions that causes 10.1 to fail in this scenario (a volume shared from a windows/mac host to the VM via VirtualBox Shared Folder) and all versions of MariaDB currently fail on Docker for Mac/Docker for Windows when using a volume shared from the host (https://github.com/docker-library/percona/issues/42#issuecomment-298109103).
+1
+1
I think it's InnoDB O_DIRECT bug. Turn off innodb_flush_method=O_DIRECT helps me.
@igorbarkowsky O_DIRECT does not exist on Windows and therefore has no effect. The default value for Windows is async_unbuffered.
+1
+1
+1
+1
+1
Setting innodb_flush_method=O_DSYNC fixed issue for me.
Using mariadb:10.0.33
Docker through HyperV on Windows 10
+1
System: Windows 10 v1607 with Docker for Windows (Hyper-V): 17.06.0-ce-win18 (12627) (current Docker is also failing with following error message)
Using latest mariadb docker image:
docker-compose.yml:
...
volumes:
- ./db/data/:/var/lib/mysql:rw
...
Logs:
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] mysqld (mysqld 10.2.14-MariaDB-10.2.14+maria~jessie) starting as process 1 ...
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Uses event mutexes
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Compressed tables use zlib 1.2.8
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Using Linux native AIO
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Number of pools: 1
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Using SSE2 crc32 instructions
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Completed initialization of buffer pool
db_1 | 2018-04-25 8:13:24 139821292693248 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
db_1 | 2018-04-25 8:13:24 139822027995008 [ERROR] InnoDB: The Auto-extending innodb_system data file './ibdata1' is of a different size 0 pages than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages!
db_1 | 2018-04-25 8:13:24 139822027995008 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
db_1 | 2018-04-25 8:13:24 139822027995008 [Note] InnoDB: Starting shutdown...
db_1 | 2018-04-25 8:13:25 139822027995008 [ERROR] Plugin 'InnoDB' init function returned error.
db_1 | 2018-04-25 8:13:25 139822027995008 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
db_1 | 2018-04-25 8:13:25 139822027995008 [Note] Plugin 'FEEDBACK' is disabled.
db_1 | 2018-04-25 8:13:25 139822027995008 [ERROR] Could not open mysql.plugin table. Some plugins may be not loaded
db_1 | 2018-04-25 8:13:25 139822027995008 [ERROR] Unknown/unsupported storage engine: InnoDB
db_1 | 2018-04-25 8:13:25 139822027995008 [ERROR] Aborting
db_1 |
docker_db_1 exited with code 1
Tried Bugfix from @jszoja, unfortunately with no success.
@rgj8 I have the same issue and the fix from @jszoja work for me, try this :
volumes:
- ./config:/etc/mysql/conf.d
- ./data:/var/lib/mysql
And create file local.cnf in ./config
[mysqld]
innodb_flush_method=O_DSYNC
Delete old files in ./data directory and docker-compose up ๐
@LuaxY Thanks for your reply. I've tested it now with mounting the configuration folder completely to /etc/mysql/conf.d with overlaying existing files in that folder.
Now it works! Thank you ๐
@LuaxY, @rgj8: I am using these command in docker-compose.yml:
``yml
command: --innodb-flush-method=O_DSYNC --innodb-use-native-aio=0 --log_bin=ON
````
However, the daemon seems still usingO_DIRECTandAIO` and fails starting up.
@strarsis, I used to set this parameter through the command as you did, but I found it failing when starting container with empty db. I suspect that mariadb requires --initialize parameter for the first time it runs to populate the users table etc.
Once I started passing flush method through the custom config file all started working for me.
Looks like we need to update line 91 so that it takes all the args passed via command for mysqld since any options that are not mysql_install_db specific "are passed to the mysqld program" (see mysql_install_db --help output).
Maybe something like:
mysql_install_db "${@:2}" --datadir="$DATADIR" --rpm
@yosifkit: Yes! Please change and push to Docker Hub so I can use it via command!
@yosifkit you mean something like we did over in https://github.com/docker-library/mysql/pull/358? :innocent: :speak_no_evil:
Edit: The config part (innodb-fix.cnf) is not needed anymore when
recent mariadb images are used, see https://github.com/docker-library/mariadb/issues/38#issuecomment-428015769.
Based on the hint that the command line arguments aren't passed when the database is initialized,
I managed to base of a working mariadb container. Edit: Improved the setup (@jszoja):
docker-compose.yml:
```yml
db:
image: mariadb:10.2.14
environment:
MYSQL_ROOT_PASSWORD: example
MYSQL_DATABASE: app
MYSQL_USER: app
MYSQL_PASSWORD: test
user: "1000:50"
command: mysqld --innodb-flush-method=littlesync --innodb-use-native-aio=OFF --log_bin=ON
volumes:
- ./db:/var/lib/mysql
- ./innodb-fix.cnf:/etc/mysql/conf.d/innodb-fix.cnf
````
innodb-fix.cnf:
```yml
[mysqld]
innodb_flush_method=littlesync
innodb_use_native_aio=OFF
log_bin=ON
````
I noticed that initialization and subsequent startup only work with innodb_flush_method option set to littlesync or nosync. Interestingly, it doesn't work for me with O_DSYNC, maybe the Windows 10 April 2018 update has something to do with this?
Also note that when the database has been already initialized (and persisted, mounted host directory),
then you have to remove it before starting the fixed mariadb setup, otherwise mariadb will encounter the indorrectly initialized database and just fail to start.
I found that the COPY command might be inconvenient when you want to update the config file. Looks like you have to rebuild the image to have the new changes in place, whereas mounting a file/volume approach loads changes after restarting container ๐
@strarsis 's solution works for me. The line ' - ./innodb-fix.cnf:/etc/mysql/conf.d/innodb-fix.cnf' is not used. I'm using vbox in windows 7 and latest mariadb.
:-(
db_1 | Initializing database
db_1 | Warning: World-writable config file '/etc/mysql/conf.d/innodb-fix.cnf' is ignored
db_1 | 2018-07-23 14:04:19 139782540920704 [Warning] InnoDB: Failed to set O_DIRECT on file./ibdata1;CREATE: Invalid argument, ccontinuing anyway. O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662.
db_1 | 2018-07-23 14:04:21 139782540920704 [ERROR] InnoDB: Operating system error number 22 in a file operation.
db_1 | 2018-07-23 14:04:21 139782540920704 [ERROR] InnoDB: Error number 22 means 'Invalid argument'
db_1 | 2018-07-23 14:04:21 139782540920704 [ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 222. Cannot continue operation
db_1 | 180723 14:04:21 [ERROR] mysqld got signal 6 ;
db_1 | This could be because you hit a bug. It is also possible that this binary
db_1 | or one of the libraries it was linked against is corrupt, improperly built,
db_1 | or misconfigured. This error can also be caused by malfunctioning hardware.
db_1 |
db_1 | To report this bug, see https://mariadb.com/kb/en/reporting-bugs
db_1 |
db_1 | We will try our best to scrape up some info that will hopefully help
db_1 | diagnose the problem, but since we have already crashed,
db_1 | something is definitely wrong and this may fail.
db_1 |
db_1 | Server version: 10.2.14-MariaDB-10.2.14+maria~jessie
@cjk: For some reasons the config file that should fix the issue is not read in your case.
Warning: World-writable config file '/etc/mysql/conf.d/innodb-fix.cnf' is ignored
Apparently because it is 'word-writable', its file permissions not restrictive enough for
mariadb security checks at startup.
Also you have to let it create new database data files because when
they had been created without the fix they stay corrupted.
Move the old data dirs folder so a new one can be created.
Edit: Found some source code that is somehow relevant: https://github.com/twitter/mysql/blob/master/mysys/default.c#L797
@strarsis yes, saw this
I got it to "work" with creating an own Docker image based on mariadb with copying the file...
FROM mariadb:10.3
COPY innodb-fix.cnf /etc/mysql/conf.d/innodb-fix.cnf
version: '3'
services:
db:
build: docker/db
environment:
- MYSQL_ROOT_PASSWORD=_secret
- MYSQL_DATABASE=vs4m
- MYSQL_USER=vs4m
- MYSQL_PASSWORD=_vs4m
# user: "1000:50"
# command: mysqld --innodb-flush-method=littlesync --innodb-use-native-aio=OFF --log_bin=ON
volumes:
- ./db:/var/lib/mysql
ports:
- "3306:3306"
phpmyadmin:
image: phpmyadmin/phpmyadmin
environment:
PMA_ARBITRARY: 1
PMA_HOST: db
PMA_USER: root
PMA_PASSWORD: _secret
ports:
- "8081:80"
links:
- "db:db"
But when I start filling the database I get other exceptions.
db_1 | 2018-07-24 5:21:06 0 [Note] mysqld: ready for connections.
db_1 | Version: '10.3.8-MariaDB-1:10.3.8+maria~jessie-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution
db_1 | 2018-07-24 5:23:30 9 [ERROR] InnoDB: Operating system error number 26 in a file operation.
db_1 | 2018-07-24 5:23:30 9 [ERROR] InnoDB: Error number 26 means 'Text file busy'
db_1 | 2018-07-24 5:23:30 9 [Note] InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/
db_1 | 2018-07-24 5:23:30 9 [ERROR] InnoDB: Cannot rename file './vs4m/stored_file.ibd' to './vs4m/#sql-ib26-822361204.ibd'
db_1 | 2018-07-24 05:23:30 0x7f92d0b0b700 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.3.8/storage/innobase/handler/handler0alter.cc line 8812
db_1 | InnoDB: Failing assertion: error == DB_SUCCESS
db_1 | InnoDB: We intentionally generate a memory trap.
db_1 | InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
db_1 | InnoDB: If you get repeated assertion failures or crashes, even
db_1 | InnoDB: immediately after the mysqld startup, there may be
db_1 | InnoDB: corruption in the InnoDB tablespace. Please refer to
db_1 | InnoDB: https://mariadb.com/kb/en/library/xtradbinnodb-recovery-modes/
db_1 | InnoDB: about forcing recovery.
db_1 | 180724 5:23:30 [ERROR] mysqld got signal 6 ;
db_1 | This could be because you hit a bug. It is also possible that this binary
I think the central point here is
db_1 | 2018-07-24 5:23:30 9 [ERROR] InnoDB: Cannot rename file './vs4m/stored_file.ibd' to './vs4m/#sql-ib26-822361204.ibd'
and I simply think, that the filename might not perhaps not be possible on windows or is a problem with Docker Toolbox/Virtualbox or whatever.
Iยดm giving up on using docker on windows with mysql/mariadb and install a native MariaDB-Server ... and thinking again about switching from windows to linux.
@cljk: Not sure whether this could help, but you could try to run all this via WSL (Bash on Windows).
I made it work again by moving the config option back to the command attribute in the yaml file. It doesn't seem to cause the issue with database initialization since it has been fixed according to previous @yosifkit comment.
db10:
image: mariadb:10.0
volumes:
- ./db_data10:/var/lib/mysql:z
- ./db10.cnf:/etc/mysql/conf.d/db10.cnf:ro # doesn't work, unless you set read-only attribute in windows for this file
- ./create-dbs:/docker-entrypoint-initdb.d:z
ports:
- "3307:3306"
restart: always
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
command: mysqld --innodb-flush-method=O_DSYNC #pass the config through the command
It might be important to cleanup the whole db before running it with this customized command parameter. Otherwise it is too late and your DB is already corrupted as @strarsis mentioned in comment.
It works for me on Windows 10 and docker 18.06.0.ce. All databases were recreated properly on the first run.
Additionally I tried to set readonly mode for mounting db10.cnf file, but that didn't help and the config file was ignored by mariadb.
I also made it work by setting the config file with readonly attribute in windows: right-click->properties->read-only checkbox.
Could someone explain why this is happening?
Could someone explain why this is happening?
It works on Linux-hosts - not on Docker-Machine mapping the datadir via SMB or VM specific FS (vboxsf f.e.). I think the problem are Linux-specific file-access methods wich are not compatible on network/virtualized storage.
FYI, the command arguments not being passed to mysql_install_db was fixed in https://github.com/docker-library/mariadb/pull/168. So using a config file is not required.
@yosifkit: I have to pull the recent mariadb image from Dockerhub for this fix?
Are the specific tags (mariadb versions) also fixed?
@strarsis, Correct. You'll need to pull the newer images to get that fix; which should be any image after
the builds from https://github.com/docker-library/official-images/pull/4385. That applies to all the image tags that were available at that time (ie all these versions 10.3.6, 10.3, 10.2.15, 10.2, 10, latest, 10.1.33, 10.1, 10.0.35, 10.0, 5.5.60, 5.5, 5) and any newer tags.
@rgj8 I have the same issue and the fix from @jszoja work for me, try this :
volumes: - ./config:/etc/mysql/conf.d - ./data:/var/lib/mysqlAnd create file
local.cnfin ./config[mysqld] innodb_flush_method=O_DSYNCDelete old files in ./data directory and
docker-compose up๐
YOU ARE MY HERO!!!
@Hobart2967
Did you also try to fill the running database ... and does it then still run after restart?
Windows 7 here, with kitematic. Nothing works:
mariadb_1 | 2019-05-14 16:23:40 0 [Note] InnoDB: Ignoring data file './data/#sql-ib29.ibd' with space ID 5. Another data file called ./data/bannedusers.ibd exists with the same space ID.
mariadb_1 | 2019-05-14 16:23:40 0 [Note] InnoDB: Ignoring data file './data/bannedusers.ibd' with space ID 14. Another data file called ./data/#sql-6e_f.ibd exists with the same space ID.
mariadb_1 | 2019-05-14 16:23:40 0 [Note] InnoDB: Ignoring data file './data/#sql-ib29.ibd' with space ID 5. Another data file called ./data/bannedusers.ibd exists with the same space ID.
mariadb_1 | 2019-05-14 16:23:40 0 [ERROR] InnoDB: Operating system error number 26 in a file operation.
mariadb_1 | 2019-05-14 16:23:40 0 [ERROR] InnoDB: Error number 26 means 'Text file busy'
mariadb_1 | 2019-05-14 16:23:40 0 [Note] InnoDB: Some operating system error numbers are described at https://mariadb.com/kb/en/library/operating-system-error-codes/
mariadb_1 | 2019-05-14 16:23:40 0 [ERROR] InnoDB: Cannot rename file './data/bannedusers.ibd' to './data/#sql-ib29.ibd'
mariadb_1 | 2019-05-14 16:23:40 0x7f55b1b10540 InnoDB: Assertion failure in file /home/buildbot/buildbot/build/mariadb-10.3.14/storage/innobase/fil/fil0fil.cc line 2245
Well dang, so many hours lost on this. Meanwhile, bitnami/mariadb just works.โข
Is there a place to suggest that this bug be mentioned in the Docker Hub Caveats?
For anyone who has been getting a headache (hopefully not) for a couple of days what worked for me is to downgrade to mariadb:10.0.33 as @jszoja highlighted. There is no other sane solution, except to use another alternative database like Cassandra if you care about your health.
Also, I just TESTED this. Environment file is being ignored by mariadb for some reason, so if you have to set env vars, make sure to declare your env inside the Dockerfile. Pretty disappointing how this issue is almost 4 years old and completely ignored
Also, I just TESTED this. Environment file is being ignored by mariadb for some reason, so if you have to set env vars, make sure to declare your env inside the Dockerfile. Pretty disappointing how this issue is almost 4 years old and completely ignored
Several direct repository maintainer interactions is far from "completely ignored" ๐
What I feel is being most strongly ignored here is the sentiment from two years ago in https://github.com/docker-library/mariadb/issues/38#issuecomment-283191398 that this is not the right place to report or discuss this. We aren't going to patch quirks of MariaDB itself in this image. Full stop. If you want changes to MariaDB itself, those should be filed and discussed with the upstream MariaDB project.
I'm going to lock this discussion here, because I think continuing here is counterproductive.
If you would like to continue discussing _workarounds_, please take those discussions to dedicated support forums such as the Docker Community Forums, the Docker Community Slack, or Stack Overflow.
Most helpful comment
@rgj8 I have the same issue and the fix from @jszoja work for me, try this :
And create file
local.cnfin ./configDelete old files in ./data directory and
docker-compose up๐