laradock_mysql_1 docker-entrypoint.sh mysqld Exit 2

[guider]

Info:

• Docker version ($ docker --version):
  Client:
  Version: 18.03.0-ce
  API version: 1.37
  Go version: go1.9.4
  Git commit: 0520e24
  Built: Wed Mar 21 23:06:22 2018
  OS/Arch: darwin/amd64
  Experimental: false
  Orchestrator: swarm

Server:
Engine:
Version: 18.03.0-ce
API version: 1.37 (minimum version 1.12)
Go version: go1.9.4
Git commit: 0520e24
Built: Wed Mar 21 23:14:32 2018
OS/Arch: linux/amd64
Experimental: true

• Laradock commit ($ git rev-parse HEAD):
• System info (Mac, PC, Linux):
• System info disto/version:

Issue:

---

Expected behavior:

---

Reproduce:

---

[guider]

i have change mysql version to 5.7 and try buy invalid

[guider]

Laradock commit 0c41fce
system info mac 10.13.4

[guider]

Attaching to laradock_mysql_1
mysql_1 | 2018-04-11T03:51:04.311015Z 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-04-11T03:51:04.311065Z 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 | 2018-04-11T03:51:04.315056Z 0 [Note] mysqld (mysqld 5.7.21) starting as process 1 ...
mysql_1 | 2018-04-11T03:51:04.320095Z 0 [Note] InnoDB: PUNCH HOLE support available
mysql_1 | 2018-04-11T03:51:04.320126Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
mysql_1 | 2018-04-11T03:51:04.320129Z 0 [Note] InnoDB: Uses event mutexes
mysql_1 | 2018-04-11T03:51:04.320131Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
mysql_1 | 2018-04-11T03:51:04.320133Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.3
mysql_1 | 2018-04-11T03:51:04.320135Z 0 [Note] InnoDB: Using Linux native AIO
mysql_1 | 2018-04-11T03:51:04.320344Z 0 [Note] InnoDB: Number of pools: 1
mysql_1 | 2018-04-11T03:51:04.320452Z 0 [Note] InnoDB: Using CPU crc32 instructions
mysql_1 | 2018-04-11T03:51:04.321537Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
mysql_1 | 2018-04-11T03:51:04.326542Z 0 [Note] InnoDB: Completed initialization of buffer pool
mysql_1 | 2018-04-11T03:51:04.328128Z 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-04-11T03:51:04.350206Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 in the data dictionary but the flags in file ./ibdata1 are 0x4800!
mysql_1 | 2018-04-11 03:51:04 0x7fb9dc8bd740 InnoDB: Assertion failure in thread 140436245829440 in file ut0ut.cc line 942
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 | 03:51:04 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)[0x55e3173280dc]
mysql_1 | mysqld(handle_fatal_signal+0x479)[0x55e316c54df9]
mysql_1 | /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fb9dc49b0c0]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fb9dac27fff]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fb9dac2942a]
mysql_1 | mysqld(+0x61f729)[0x55e316c2b729]
mysql_1 | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x55e3174f66ed]
mysql_1 | mysqld(+0xf97441)[0x55e3175a3441]
mysql_1 | mysqld(+0xf97a78)[0x55e3175a3a78]
mysql_1 | mysqld(Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8+0x2b0)[0x55e3175acba0]
mysql_1 | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x55e317561c2e]
mysql_1 | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x55e317530d6a]
mysql_1 | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x55e3174d48b3]
mysql_1 | mysqld(+0x61e89d)[0x55e316c2a89d]
mysql_1 | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x55e3174a176d]
mysql_1 | mysqld(+0xd62a5b)[0x55e31736ea5b]
mysql_1 | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x55e316ca047f]
mysql_1 | mysqld(+0xb0d316)[0x55e317119316]
mysql_1 | mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x55e31711c400]
mysql_1 | mysqld(+0x641596)[0x55e316c4d596]
mysql_1 | mysqld(_Z11mysqld_mainiPPc+0xc6b)[0x55e316c4f14b]
mysql_1 | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb9dac152e1]
mysql_1 | mysqld(_start+0x2a)[0x55e316c4582a]
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.

[chrisp-github]

Ok so note on this if you are upgrading your fork of laradock from pre 6.0 then don't set the mysql version to latest as this will try to pull down the GA release which is on V5 of mysql. Before laradock 6.0 that mysql version was set to 8.0 which is the current development version so if you then try to set it to latest it tries to downgrade your mysql version to 5 and will give you this error.

[guider]

@shadow2004
what can I do to resolve it? and i have set mysql version 5.7 but useless.

[chrisp-github]

Try setting your mysql version to 8.0.0/8.0.1/8.0.2/8.0.3/8.0.4 and rebuild mysql container.

So basically if you did build your DB with an 8.0 build then one of those version numbers will be the correct one.

[Ablegang]

I also encountered this problem.

I rebuild mysql container , and I delete the "~/.laradock/data/mysql" directory , and I:

docker-compose up -d mysql

It works.

[chrisp-github]

Ye that is another option if you don't care about the data in the database.

Now if you do care about the data but want to go back onto the latest release, v5. Then you will want to dump all your data into a SQL file then delete the mysql folder in the docker data. Then up the mysql container which will create a new database for then, then the last thing is to re-import your data from the SQL dump.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

Hi again 👋 we would like to inform you that this issue has been automatically closed 🔒 because it had not recent activity during the stale period. We really really appreciate your contributions, and looking forward for more in the future 🎈.

[wangdeer]

It's sovled my problem. Thank you !