“docker-compose up” on Windows failed with error on Mysql container step #361
Description
I am trying to set my environment for php developing on Windows 10 in phpstorm using docker and docker-compose.yml but got some errors on Mysql setup step. Cannot find the issue.
This is my docker-compose.yml:
version: '2'
volumes:
database_data:
driver: local
services:
nginx:
image: nginx:latest
ports:
- 8080:80
volumes:
- ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf
volumes_from:
- php
php:
build: ./docker/php/
expose:
- 9000
volumes:
- .:/var/www/html
mysql:
image: mysql:latest
ports:
- 3306:3306
expose:
- 3306
environment:
MYSQL_ROOT_PASSWORD: pass
MYSQL_DATABASE: fs_db
MYSQL_USER: fs_user
MYSQL_PASSWORD: pass
volumes:
- database_data:/var/lib/mysql
Then in console im trying to: docker-compose up
But on the mysql container setup step got this:
mysql_1 | 2018-01-10T18:47:16.115382Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1 | 2018-01-10T18:47:16.116034Z 0 [Note] mysqld (mysqld 5.7.20) starting as process 1 ...
mysql_1 | 2018-01-10T18:47:16.117730Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1 | 2018-01-10T18:47:16.117747Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1 | 2018-01-10T18:47:16.117750Z 0 [Note] InnoDB: Uses event mutexes
mysql_1 | 2018-01-10T18:47:16.117751Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1 | 2018-01-10T18:47:16.117753Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
mysql_1 | 2018-01-10T18:47:16.117758Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1 | 2018-01-10T18:47:16.117964Z 0 [Note] InnoDB: Number of pools: 1
mysql_1 | 2018-01-10T18:47:16.118084Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1 | 2018-01-10T18:47:16.118933Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1 | 2018-01-10T18:47:16.122885Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1 | 2018-01-10T18:47:16.123824Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
mysql_1 | 2018-01-10T18:47:16.134547Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4000!
mysql_1 | 2018-01-10 18:47:16 0x7f6fcbe6d740 InnoDB: Assertion failure in thread 140118139000640 in file ut0ut.cc line 916
mysql_1 | InnoDB: We intentionally generate a memory trap.
mysql_1 | InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
mysql_1 | InnoDB: If you get repeated assertion failures or crashes, even
mysql_1 | InnoDB: immediately after the mysqld startup, there may be
mysql_1 | InnoDB: corruption in the InnoDB tablespace. Please refer to
mysql_1 | InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
mysql_1 | InnoDB: about forcing recovery.
mysql_1 | 18:47:16 UTC - mysqld got signal 6 ;
mysql_1 | This could be because you hit a bug. It is also possible that this binary
mysql_1 | or one of the libraries it was linked against is corrupt, improperly built,
mysql_1 | or misconfigured. This error can also be caused by malfunctioning hardware.
mysql_1 | Attempting to collect some information that could help diagnose the problem.
mysql_1 | As this is a crash and something is definitely wrong, the information
mysql_1 | collection process might fail.
mysql_1 |
mysql_1 | key_buffer_size=8388608
mysql_1 | read_buffer_size=131072
mysql_1 | max_used_connections=0
mysql_1 | max_threads=151
mysql_1 | thread_count=0
mysql_1 | connection_count=0
mysql_1 | It is possible that mysqld could use up to
mysql_1 | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68193 K bytes of memory
mysql_1 | Hope that's ok; if not, decrease some variables in the equation.
mysql_1 |
mysql_1 | Thread pointer: 0x0
mysql_1 | Attempting backtrace. You can use the following information to find out
mysql_1 | where mysqld died. If you see no messages after this, something went
mysql_1 | terribly wrong...
mysql_1 | stack_bottom = 0 thread_stack 0x40000
mysql_1 | mysqld(my_print_stacktrace+0x2c)[0xe889ac]
mysql_1 | mysqld(handle_fatal_signal+0x459)[0x7aba79]
mysql_1 | /lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f6fcba4a890]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x7f6fca453067]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x7f6fca454448]
mysql_1 | mysqld[0x781ae3]
mysql_1 | mysqld(_ZN2ib5fatalD1Ev+0x15d)[0x1113dbd]
mysql_1 | mysqld[0x11c5afc]
mysql_1 | mysqld[0x11c5fdc]
mysql_1 | mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x1e0)[0x11d1380]
mysql_1 | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xcf)[0x118224f]
mysql_1 | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x389)[0x11529b9]
mysql_1 | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x10f2b63]
mysql_1 | mysqld[0x780ded]
mysql_1 | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x357d)[0x10c07bd]
mysql_1 | mysqld[0xf86e28]
mysql_1 | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x51)[0x7f7001]
mysql_1 | mysqld[0xc7bb66]
mysql_1 | mysqld(_Z11plugin_initPiPPci+0x5b8)[0xc82bf8]
mysql_1 | mysqld[0x7a42be]
mysql_1 | mysqld(_Z11mysqld_mainiPPc+0x7e9)[0x7a58d9]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f6fca43fb45]
mysql_1 | mysqld[0x79c384]
mysql_1 | The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
mysql_1 | information that should help you find out what is causing the crash.
fightstarter_mysql_1 exited with code 2
Sorry if i missed something... this is my first comment on GitHub.