"docker-compose up " on Windows failed with error on Mysql container step

Question

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

Trying to find the issue on github, but i cant find any similar.

Answer 1

Thank you yamenk! Your answer plus some tweaks and it works:

1. docker-compose down
2. docker system prune --force --volumes
3. Added command: --disable-partition-engine-check to mysql section in docker-compose.yml
4. Ran it with docker-compose up -d to set it up in background.

Answer 2

This problem has been reported in here.

I suggest first that you stop the containers using docker-compose down and remove the dangling volumes and images using docker system prune --force --volumes