无法通过phpmyadmin连接到laradock mysql容器
[英]cannot connect to laradock mysql container via phpmyadmin
问题描述
I have cloned laradock inside my laravel application. 
我已经在laravel应用程序中克隆了laradock。 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). 我已经为nginx，mysql，mariadb，phpmyadmin等构建了映像。现在，我的问题是mysql（实际上也是mariadb）。 When I boot up phpmyadmin at localhost:8080 and try to connect to mysql from there I get these two similar error messages: 当我在localhost:8080启动phpmyadmin并尝试从那里连接到mysql时，我得到了这两个类似的错误消息：
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 目前我的laradock .env文件就像
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 我的laravel应用程序的.env文件就像
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret
My laradock/mysql/Dockerfile is like 我的laradock / mysql / Dockerfile就像
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 我的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
I am using mysql 5.7 to avoid authentication method problem issue. 我正在使用mysql 5.7以避免身份验证方法问题。 I have run this to build mysql: 我已经运行了这个来构建mysql：
docker-compose build --no-cache mysql
And my mysql container cannot be up and mysql logs is like 而且我的mysql容器无法启动并且mysql日志就像
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.
3 个解决方案
解决方案1
0 2019-07-25 12:35:28
In mysql host you have to provide the name of the service you used for your docker compose file: 在mysql主机中，您必须提供用于docker compose文件的服务名称：
For example: If your docker-compose file is this:- version: "3" 例如：如果您的docker-compose文件是这样的：-版本：“ 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: 如您在上面看到的，服务名称是示例服务名称，您必须在mysql主机中像这样添加，假设您已经暴露了3306端口：
DB_CONNECTION=mysql
DB_HOST=example-service-name
DB_PORT=3306
DB_DATABASE=default
DB_USERNAME=default
DB_PASSWORD=secret
解决方案2
0 2019-07-25 13:12:16
In my my.cnf I have: 在我的my.cnf中，我有：
# 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: 然后在我的DockerFile中，我有：
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 在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. 并在.env中设置5.7 mysql版本。
Try with this configuration, for me it works, if not work try to see this post on github: 尝试使用此配置，对我来说它可以工作，如果不起作用，请尝试在github上查看此帖子：
https://github.com/laradock/laradock/issues/1350 https://github.com/laradock/laradock/issues/1350
Could be the problem with volume. 可能是音量问题。
解决方案3
0 2019-07-25 19:02:24
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. 经过很多努力后，我意识到从mysql 8降级到较低版本时，清除data文件夹的内容可以解决mysql容器的问题。
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. 因为您将丢失所有数据。
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
相关问题
如何通过phpMyAdmin连接到mysql docker容器？ - How to connect to mysql docker container via phpMyAdmin?
PHPMyAdmin无法连接到MySQL - PHPMyAdmin cannot connect to MySQL
phpMyAdmin 无法连接到 MySQL 服务器 - phpMyAdmin cannot connect to MySQL server
无法通过phpMyAdmin连接到MySQL - Cannot connect to MySQL through phpMyAdmin
无法连接到mysql数据库[phpmyadmin] - Cannot connect to mysql database [phpmyadmin]
mysql_connect上的Laradock错误 - Laradock error on mysql_connect
通过PHPMyAdmin连接到MySQL本地数据库 - Connect to MySQL local database via PHPMyAdmin
MYSQL 和 PHPMYADMIN 无法通过 php 连接 - MYSQL and PHPMYADMIN cant connect via php
在 Centos7 上无法从 PhpMyadmin 连接到 Mysql - Cannot Connect To Mysql From PhpMyadmin On Centos7
无法登录phpmyadmin但可以连接到mysql - Cannot log into phpmyadmin but can connect to mysql
相关标签