cannot connect to laradock mysql container via phpmyadmin

Question

I have cloned laradock inside my laravel application. Now, I am trying to set my environment up and running. I have built images for nginx, mysql, mariadb, phpmyadmin and etc. Now, my problem is with mysql (and actuallly mariadb, too). When I boot up phpmyadmin at localhost:8080 and try to connect to mysql from there I get these two similar error messages:

mysqli_real_connect(): php_network_getaddresses: getaddrinfo failed: Name or service not known mysqli_real_connect(): (HY000/2002): php_network_getaddresses: getaddrinfo failed: Name or service not known

I have tried different configurations to resolve this. Currently my laradock .env file is like

MYSQL_VERSION=5.7
MYSQL_DATABASE=default
MYSQL_USER=default
MYSQL_PASSWORD=secret 
MYSQL_PORT=3306
MYSQL_ROOT_PASSWORD=root
MYSQL_ENTRYPOINT_INITDB=./mysql/docker-entrypoint-initdb.d

And the .env file of my laravel application is like

DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret

My laradock/mysql/Dockerfile is like

ARG MYSQL_VERSION=5.7
FROM mysql:${MYSQL_VERSION}
LABEL maintainer="Mahmoud Zalt <mahmoud@zalt.me>"
ARG TZ=UTC
ENV TZ ${TZ}
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > 
/etc/timezone && chown -R mysql:root /var/lib/mysql/
COPY my.cnf /etc/mysql/conf.d/my.cnf
CMD ["mysqld"]
EXPOSE 3306

My docker-compose.yml is like

 ### MySQL ################################################
    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_PATH_HOST}/mysql:/var/lib/mysql
        - ${MYSQL_ENTRYPOINT_INITDB}:/docker-entrypoint-initdb.d
      ports:
        - "${MYSQL_PORT}:3306"
      networks:
        - backend

I am using mysql 5.7 to avoid authentication method problem issue. I have run this to build mysql:

docker-compose build --no-cache mysql

And my mysql container cannot be up and mysql logs is like

ttaching to laradock_mysql_1
mysql_1                | 2019-07-25T12:20:23.891774Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1                | 2019-07-25T12:20:23.891822Z 0 [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.
mysql_1                | 2019-07-25T12:20:23.891826Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
mysql_1                | 2019-07-25T12:20:23.893370Z 0 [Note] mysqld (mysqld 5.7.27) starting as process 1 ...
mysql_1                | 2019-07-25T12:20:23.896715Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1                | 2019-07-25T12:20:23.896733Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1                | 2019-07-25T12:20:23.896736Z 0 [Note] InnoDB: Uses event mutexes
mysql_1                | 2019-07-25T12:20:23.896742Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1                | 2019-07-25T12:20:23.896745Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
mysql_1                | 2019-07-25T12:20:23.896753Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1                | 2019-07-25T12:20:23.897008Z 0 [Note] InnoDB: Number of pools: 1
mysql_1                | 2019-07-25T12:20:23.897097Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1                | 2019-07-25T12:20:23.898802Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1                | 2019-07-25T12:20:23.908814Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1                | 2019-07-25T12:20:23.910783Z 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                | 2019-07-25T12:20:23.922124Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
mysql_1                | 2019-07-25 12:20:23 0x7fc59faa0740  InnoDB: Assertion failure in thread 140486764005184 in file ut0ut.cc line 910
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                | 12:20:23 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 = 68196 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)[0x55fa4df18dcc]
mysql_1                | mysqld(handle_fatal_signal+0x479)[0x55fa4d843099]
mysql_1                | /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fc59f67d0e0]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fc59de09fff]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fc59de0b42a]
mysql_1                | mysqld(+0x62a713)[0x55fa4d819713]
mysql_1                | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55fa4e0e964d]
mysql_1                | mysqld(+0xfa73b1)[0x55fa4e1963b1]
mysql_1                | mysqld(+0xfa79e8)[0x55fa4e1969e8]
mysql_1                | mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55fa4e19fba0]
mysql_1                | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55fa4e154c2e]
mysql_1                | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55fa4e123e6a]
mysql_1                | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55fa4e0c7ab3]
mysql_1                | mysqld(+0x629887)[0x55fa4d818887]
mysql_1                | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55fa4e09494d]
mysql_1                | mysqld(+0xd70f08)[0x55fa4df5ff08]
mysql_1                | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55fa4d88df6f]
mysql_1                | mysqld(+0xb16d66)[0x55fa4dd05d66]
mysql_1                | mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55fa4dd08f70]
mysql_1                | mysqld(+0x64c79e)[0x55fa4d83b79e]
mysql_1                | mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55fa4d83d361]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fc59ddf72e1]
mysql_1                | mysqld(_start+0x2a)[0x55fa4d833a3a]
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.
mysql_1                | 2019-07-25T12:21:15.105788Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1                | 2019-07-25T12:21:15.105833Z 0 [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.
mysql_1                | 2019-07-25T12:21:15.105836Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
mysql_1                | 2019-07-25T12:21:15.107370Z 0 [Note] mysqld (mysqld 5.7.27) starting as process 1 ...
mysql_1                | 2019-07-25T12:21:15.111983Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1                | 2019-07-25T12:21:15.112000Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1                | 2019-07-25T12:21:15.112022Z 0 [Note] InnoDB: Uses event mutexes
mysql_1                | 2019-07-25T12:21:15.112026Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1                | 2019-07-25T12:21:15.112045Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
mysql_1                | 2019-07-25T12:21:15.112051Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1                | 2019-07-25T12:21:15.112331Z 0 [Note] InnoDB: Number of pools: 1
mysql_1                | 2019-07-25T12:21:15.112535Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1                | 2019-07-25T12:21:15.114207Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1                | 2019-07-25T12:21:15.124248Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1                | 2019-07-25T12:21:15.126363Z 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                | 2019-07-25T12:21:15.137968Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
mysql_1                | 2019-07-25 12:21:15 0x7fa7fac61740  InnoDB: Assertion failure in thread 140359443552064 in file ut0ut.cc line 910
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                | 12:21:15 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 = 68196 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)[0x561981daddcc]
mysql_1                | mysqld(handle_fatal_signal+0x479)[0x5619816d8099]
mysql_1                | /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7fa7fa83e0e0]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fa7f8fcafff]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fa7f8fcc42a]
mysql_1                | mysqld(+0x62a713)[0x5619816ae713]
mysql_1                | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x561981f7e64d]
mysql_1                | mysqld(+0xfa73b1)[0x56198202b3b1]
mysql_1                | mysqld(+0xfa79e8)[0x56198202b9e8]
mysql_1                | mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x561982034ba0]
mysql_1                | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x561981fe9c2e]
mysql_1                | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x561981fb8e6a]
mysql_1                | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x561981f5cab3]
mysql_1                | mysqld(+0x629887)[0x5619816ad887]
mysql_1                | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x561981f2994d]
mysql_1                | mysqld(+0xd70f08)[0x561981df4f08]
mysql_1                | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x561981722f6f]
mysql_1                | mysqld(+0xb16d66)[0x561981b9ad66]
mysql_1                | mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x561981b9df70]
mysql_1                | mysqld(+0x64c79e)[0x5619816d079e]
mysql_1                | mysqld(_Z11mysqld_mainiPPc+0xc71)[0x5619816d2361]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fa7f8fb82e1]
mysql_1                | mysqld(_start+0x2a)[0x5619816c8a3a]
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.
mysql_1                | 2019-07-25T12:25:56.459453Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
mysql_1                | 2019-07-25T12:25:56.459503Z 0 [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.
mysql_1                | 2019-07-25T12:25:56.459506Z 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
mysql_1                | 2019-07-25T12:25:56.460845Z 0 [Note] mysqld (mysqld 5.7.27) starting as process 1 ...
mysql_1                | 2019-07-25T12:25:56.464153Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1                | 2019-07-25T12:25:56.464165Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1                | 2019-07-25T12:25:56.464170Z 0 [Note] InnoDB: Uses event mutexes
mysql_1                | 2019-07-25T12:25:56.464198Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1                | 2019-07-25T12:25:56.464202Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
mysql_1                | 2019-07-25T12:25:56.464206Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1                | 2019-07-25T12:25:56.464484Z 0 [Note] InnoDB: Number of pools: 1
mysql_1                | 2019-07-25T12:25:56.464606Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1                | 2019-07-25T12:25:56.466105Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1                | 2019-07-25T12:25:56.475677Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1                | 2019-07-25T12:25:56.477663Z 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                | 2019-07-25T12:25:56.489195Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
mysql_1                | 2019-07-25 12:25:56 0x7f7c3ad1d740  InnoDB: Assertion failure in thread 140171539502912 in file ut0ut.cc line 910
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                | 12:25:56 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 = 68196 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)[0x55b95da21dcc]
mysql_1                | mysqld(handle_fatal_signal+0x479)[0x55b95d34c099]
mysql_1                | /lib/x86_64-linux-gnu/libpthread.so.0(+0x110e0)[0x7f7c3a8fa0e0]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7f7c39086fff]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7f7c3908842a]
mysql_1                | mysqld(+0x62a713)[0x55b95d322713]
mysql_1                | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55b95dbf264d]
mysql_1                | mysqld(+0xfa73b1)[0x55b95dc9f3b1]
mysql_1                | mysqld(+0xfa79e8)[0x55b95dc9f9e8]
mysql_1                | mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x55b95dca8ba0]
mysql_1                | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55b95dc5dc2e]
mysql_1                | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55b95dc2ce6a]
mysql_1                | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55b95dbd0ab3]
mysql_1                | mysqld(+0x629887)[0x55b95d321887]
mysql_1                | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55b95db9d94d]
mysql_1                | mysqld(+0xd70f08)[0x55b95da68f08]
mysql_1                | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55b95d396f6f]
mysql_1                | mysqld(+0xb16d66)[0x55b95d80ed66]
mysql_1                | mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55b95d811f70]
mysql_1                | mysqld(+0x64c79e)[0x55b95d34479e]
mysql_1                | mysqld(_Z11mysqld_mainiPPc+0xc71)[0x55b95d346361]
mysql_1                | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f7c390742e1]
mysql_1                | mysqld(_start+0x2a)[0x55b95d33ca3a]
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.

Answer 1

After a lot of struggling I realized that when downgrading from mysql 8 to a lower version, clearing the contents of data folder fixes the mysql container issue.

cd ~/.laradock/data/mysql
sudo rm -rf *

Do not try this if you have a database full of important data! Since you will lose all your data.

Answer 2

In my my.cnf I have:

# The MySQL  Client configuration file.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

[mysql]

[mysqld]
sql-mode="STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"
character-set-server=utf8

then in my DockerFile i have:

ARG MYSQL_VERSION=latest
FROM mysql:${MYSQL_VERSION}

LABEL 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 && chown -R mysql:root /var/lib/mysql/

COPY my.cnf /etc/mysql/conf.d/my.cnf

CMD ["mysqld"]

EXPOSE 3306

In docker-compose.yml

### MySQL ################################################
    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_PATH_HOST}/mysql:/var/lib/mysql
        - ${MYSQL_ENTRYPOINT_INITDB}:/docker-entrypoint-initdb.d
      ports:
        - "${MYSQL_PORT}:3306"
      networks:
        - backend

And in .env set 5.7 mysql version.

Try with this configuration, for me it works, if not work try to see this post on github:

https://github.com/laradock/laradock/issues/1350

Could be the problem with volume.

Answer 3

In mysql host you have to provide the name of the service you used for your docker compose file:

For example: If your docker-compose file is this:- version: "3"

services:
  example-service-name:
    container_name: dzangohq-api
    image: your/image

As you can see above the service name is example service name which you have to add in mysql host like this assuming you have exposed 3306 port:

DB_CONNECTION=mysql
DB_HOST=example-service-name
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret