I am running Docker 20.10.23 on windows, and working in WSL to create an environment for web-dev that uses multiple services like: PHP, nginx, redis, etc. Everything was working fine until it wasn’t, and if I recall correctly that was after a windows update. The relevant part of the docker-compose file is the following:
services:
database:
restart: always
build:
context: ./
dockerfile: ./database/Dockerfile
volumes:
- ./data/db:/var/lib/mysql
- ./database/ssl:/etc/mysql/ssl
environment:
MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
MYSQL_DATABASE: ${MYSQL_DATABASE}
MYSQL_USER: ${MYSQL_USER}
MYSQL_PASSWORD: ${MYSQL_PASSWORD}
MYSQL_ROOT_HOST: ${MYSQL_ROOT_HOST}
networks:
- <the network>
ports:
- "3306:3306"
the dockerfile of the database contains:
FROM mariadb:10.3.28
EXPOSE 3306
LABEL maintainer=""
COPY ./database/my.cnf /etc/mysql/conf.d/my.cnf
#COPY --chown=mysql:mysql ./database/ssl /etc/mysql/ssl
CMD ["mysqld"]
and the error I am getting is the following:
2023-04-22 17:11:08 2023-04-22 14:11:08+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2023-04-22 17:11:08 2023-04-22 14:11:08+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.3.28+maria~focal started.
2023-04-22 17:11:09 Warning: World-writable config file '/etc/mysql/conf.d/my.cnf' is ignored
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] mysqld (mysqld 10.3.28-MariaDB-1:10.3.28+maria~focal) starting as process 1 ...
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Warning] Setting lower_case_table_names=2 because file system for /var/lib/mysql/ is case insensitive
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Using Linux native AIO
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Uses event mutexes
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Number of pools: 1
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Using SSE2 crc32 instructions
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: Completed initialization of buffer pool
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [ERROR] InnoDB: Encrypted page [page id: space=0, page number=7] in file ./ibdata1 looks corrupted; key_version=1
2023-04-22 17:11:09 2023-04-22 14:11:09 0 [ERROR] [FATAL] InnoDB: Aborting because of a corrupt database page.
2023-04-22 17:11:09 230422 14:11:09 [ERROR] mysqld got signal 6 ;
2023-04-22 17:11:09 This could be because you hit a bug. It is also possible that this binary
2023-04-22 17:11:09 or one of the libraries it was linked against is corrupt, improperly built,
2023-04-22 17:11:09 or misconfigured. This error can also be caused by malfunctioning hardware.
2023-04-22 17:11:09
2023-04-22 17:11:09 To report this bug, see https://mariadb.com/kb/en/reporting-bugs
2023-04-22 17:11:09
2023-04-22 17:11:09 We will try our best to scrape up some info that will hopefully help
2023-04-22 17:11:09 diagnose the problem, but since we have already crashed,
2023-04-22 17:11:09 something is definitely wrong and this may fail.
2023-04-22 17:11:09
2023-04-22 17:11:09 Server version: 10.3.28-MariaDB-1:10.3.28+maria~focal
2023-04-22 17:11:09 key_buffer_size=134217728
2023-04-22 17:11:09 read_buffer_size=2097152
2023-04-22 17:11:09 max_used_connections=0
2023-04-22 17:11:09 max_threads=102
2023-04-22 17:11:09 thread_count=0
2023-04-22 17:11:09 It is possible that mysqld could use up to
2023-04-22 17:11:09 key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 760035 K bytes of memory
2023-04-22 17:11:09 Hope that's ok; if not, decrease some variables in the equation.
2023-04-22 17:11:09
2023-04-22 17:11:09 Thread pointer: 0x0
2023-04-22 17:11:09 Attempting backtrace. You can use the following information to find out
2023-04-22 17:11:09 where mysqld died. If you see no messages after this, something went
2023-04-22 17:11:09 terribly wrong...
2023-04-22 17:11:09 stack_bottom = 0x0 thread_stack 0x49000
2023-04-22 17:11:09 mysqld(my_print_stacktrace+0x32)[0x556afe6a5022]
2023-04-22 17:11:09 mysqld(handle_fatal_signal+0x55d)[0x556afe17ff7d]
2023-04-22 17:11:09 /lib/x86_64-linux-gnu/libpthread.so.0(+0x153c0)[0x7fc11d2a23c0]
2023-04-22 17:11:09 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcb)[0x7fc11cdaf18b]
2023-04-22 17:11:09 /lib/x86_64-linux-gnu/libc.so.6(abort+0x12b)[0x7fc11cd8e859]
2023-04-22 17:11:09 mysqld(+0x4ea1bf)[0x556afde8e1bf]
2023-04-22 17:11:09 mysqld(+0x4f0b62)[0x556afde94b62]
2023-04-22 17:11:09 mysqld(+0xb0f84d)[0x556afe4b384d]
2023-04-22 17:11:09 mysqld(+0xaf0b0a)[0x556afe494b0a]
2023-04-22 17:11:09 mysqld(+0xb11a34)[0x556afe4b5a34]
2023-04-22 17:11:09 mysqld(+0x4e2126)[0x556afde86126]
2023-04-22 17:11:09 mysqld(+0x97d4b0)[0x556afe3214b0]
2023-04-22 17:11:09 mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x70)[0x556afe182790]
2023-04-22 17:11:09 mysqld(+0x5f6195)[0x556afdf9a195]
2023-04-22 17:11:09 mysqld(_Z11plugin_initPiPPci+0x87e)[0x556afdf9b33e]
2023-04-22 17:11:09 mysqld(+0x525680)[0x556afdec9680]
2023-04-22 17:11:09 mysqld(_Z11mysqld_mainiPPc+0x408)[0x556afdecf878]
2023-04-22 17:11:09 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x7fc11cd900b3]
2023-04-22 17:11:09 mysqld(_start+0x2e)[0x556afdec240e]
2023-04-22 17:11:09 The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
2023-04-22 17:11:09 information that should help you find out what is causing the crash.
2023-04-22 17:11:09 Writing a core file...
2023-04-22 17:11:09 Working directory at /var/lib/mysql
2023-04-22 17:11:09 Resource Limits:
2023-04-22 17:11:09 Limit Soft Limit Hard Limit Units
2023-04-22 17:11:09 Max cpu time unlimited unlimited seconds
2023-04-22 17:11:09 Max file size unlimited unlimited bytes
2023-04-22 17:11:09 Max data size unlimited unlimited bytes
2023-04-22 17:11:09 Max stack size 8388608 unlimited bytes
2023-04-22 17:11:09 Max core file size 0 unlimited bytes
2023-04-22 17:11:09 Max resident set unlimited unlimited bytes
2023-04-22 17:11:09 Max processes unlimited unlimited processes
2023-04-22 17:11:09 Max open files 1048576 1048576 files
2023-04-22 17:11:09 Max locked memory 83968000 83968000 bytes
2023-04-22 17:11:09 Max address space unlimited unlimited bytes
2023-04-22 17:11:09 Max file locks unlimited unlimited locks
2023-04-22 17:11:09 Max pending signals 31207 31207 signals
2023-04-22 17:11:09 Max msgqueue size 819200 819200 bytes
2023-04-22 17:11:09 Max nice priority 0 0
2023-04-22 17:11:09 Max realtime priority 0 0
2023-04-22 17:11:09 Max realtime timeout unlimited unlimited us
2023-04-22 17:11:09 Core pattern: /mnt/wslg/dumps/core.%e
2023-04-22 17:11:09
2023-04-22 17:11:09 Fatal signal 11 while backtracing
I am fairly new to docker but I understand its way of working. I have a backup of the database but since I cannot start the container I do not know how to replace the corrupted one with the working one.
I have tried to use innodb_force_recovery = x and the container still keeps restarting, and doesn’t even take into account the innobd_force_recovery, it spits out the same error.