5
3

More than 3 years have passed since last update.

【docker】mysqlのコンテナがバグで立ち上がらなくなった

Posted at

状況

dockerでmysqlのコンテナが全く起動できなくなってしまいました。

db            | 2020-02-18 11:55:23+09:00 [Note] [Entrypoint]: Entrypoint script for MySQ
db            | 2020-02-18 11:55:23+09:00 [Note] [Entrypoint]: Switching to dedicated use
db            | 2020-02-18 11:55:23+09:00 [Note] [Entrypoint]: Entrypoint script for MySQ
db            | 2020-02-18T02:55:23.964250Z 0 [Warning] TIMESTAMP with implicit DEFAULT verver option (see documentation for more details).
db            | 2020-02-18T02:55:23.970525Z 0 [Note] mysqld (mysqld 5.7.29) starting as p
db            | 2020-02-18T02:55:23.987944Z 0 [Note] InnoDB: PUNCH HOLE support available
db            | 2020-02-18T02:55:23.988018Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC
db            | 2020-02-18T02:55:23.988026Z 0 [Note] InnoDB: Uses event mutexes
db            | 2020-02-18T02:55:23.988030Z 0 [Note] InnoDB: GCC builtin __atomic_thread_
db            | 2020-02-18T02:55:23.988033Z 0 [Note] InnoDB: Compressed tables use zlib 1
db            | 2020-02-18T02:55:23.988037Z 0 [Note] InnoDB: Using Linux native AIO
db            | 2020-02-18T02:55:23.988249Z 0 [Note] InnoDB: Number of pools: 1
db            | 2020-02-18T02:55:23.988361Z 0 [Note] InnoDB: Using CPU crc32 instructions
db            | 2020-02-18T02:55:23.990183Z 0 [Note] InnoDB: Initializing buffer pool, to
db            | 2020-02-18T02:55:23.997519Z 0 [Note] InnoDB: Completed initialization of 
db            | 2020-02-18T02:55:23.999353Z 0 [Note] InnoDB: If the mysqld execution userhe man page of setpriority().
db            | 2020-02-18T02:55:24.090309Z 0 [ERROR] [FATAL] InnoDB: Table flags are 0 i
db            | 2020-02-18 11:55:24 0x7fb2e0664740  InnoDB: Assertion failure in thread 1
db            | InnoDB: We intentionally generate a memory trap.
db            | InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
db            | InnoDB: If you get repeated assertion failures or crashes, even
db            | InnoDB: immediately after the mysqld startup, there may be
db            | InnoDB: corruption in the InnoDB tablespace. Please refer to
db            | InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.ht
db            | InnoDB: about forcing recovery.
db            | 02:55:24 UTC - mysqld got signal 6 ;
db            | This could be because you hit a bug. It is also possible that this binary
db            | or one of the libraries it was linked against is corrupt, improperly buil
db            | or misconfigured. This error can also be caused by malfunctioning hardwar
db            | Attempting to collect some information that could help diagnose the probl
db            | As this is a crash and something is definitely wrong, the information
db            | collection process might fail.
db            |
db            | key_buffer_size=8388608
db            | read_buffer_size=131072
db            | max_used_connections=0
db            | max_threads=151
db            | thread_count=0
db            | connection_count=0
db            | It is possible that mysqld could use up to
db            | key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 681
db            | /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fb2de9cf42a]
db            | mysqld(+0x699b25)[0x5562a20f0b25]
db            | mysqld(_ZN2ib5fatalD1Ev+0x12d)[0x5562a2b60d8d]
db            | mysqld(+0x11b68f1)[0x5562a2c0d8f1]
db            | mysqld(_Z6fil_ioRK9IORequestbRK9page_id_tRK11page_size_tmmPvS8_+0x2b0)[0x5562a2c17110]
db            | mysqld(_Z13buf_read_pageRK9page_id_tRK11page_size_t+0xce)[0x5562a2bcc33e]
db            | mysqld(_Z16buf_page_get_genRK9page_id_tRK11page_size_tmP11buf_block_tmPKcmP5mtr_tb+0x4aa)[0x5562a2b9b57a]
db            | mysqld(_Z31trx_rseg_get_n_undo_tablespacesPm+0x143)[0x5562a2b3f1f3]      
db            | mysqld(+0x698c99)[0x5562a20efc99]
db            | mysqld(_Z34innobase_start_or_create_for_mysqlv+0x2f3d)[0x5562a2b0c06d]   
db            | mysqld(_Z24ha_initialize_handlertonP13st_plugin_int+0x4f)[0x5562a216b0ff]
db            | mysqld(+0xb8c0f6)[0x5562a25e30f6]
db            | mysqld(_Z40plugin_register_builtin_and_init_core_sePiPPc+0x2f0)[0x5562a25e6300]
db            | mysqld(+0x6bbece)[0x5562a2112ece]
db            | mysqld(_Z11mysqld_mainiPPc+0xc71)[0x5562a2114a71]
db            | /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb2de9bb2e1]  
db            | mysqld(_start+0x2a)[0x5562a210aeaa]
db            | The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
db            | information that should help you find out what is causing the crash.

ログを見てみるとなにやら恐ろしげなことが書いてあります。

This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built or misconfigured. This error can also be caused by malfunctioning hardwar Attempting to collect some information that could help diagnose the problem As this is a crash and something is definitely wrong, the information collection process might fail.

どうやらmysqlのバグが原因のようです。なんらかの原因によりクラッシュしたみたいです。

何度、やり直してもこのエラーが出ます。
このコンテナを削除しまったく新しくmysqlのコンテナを作り直してもダメです。

とりあえず解決

こちらを参考に対処しました。
https://github.com/laradock/laradock/issues/1173

結局mysqlのイメージ、コンテナ、data volumeを削除してから再起動して解決しました。

イメージの削除

docker imagesで一覧を取得します。


$ docker images
REPOSITORY   TAG    IMAGE ID       CREATED
mysql        5.7    c4f186b9e038   2 weeks ago   435MB

コンテナを停止させてからdocker rmi (IMAGE ID)で削除します。

$ docker rmi c4f186b9e038

data volumeの削除

data volumeとしてマウントしているフォルダを削除します。docker-compose.ymlのvolumesで指定のファイルになります。

docker
 ├─mysql
 │  ├─conf.d
 │  └─data ←削除

立ち上げてみます

$ docker-compose up -d --build

自分はこれで無事起動することができました。

5
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
3