The container hangs after docker installs MySQL, and executes optimize

problem description

I installed the general operation of MySQL, with docker, but when I deleted part of the data to optimize storage, after executing the optimize command, the container closed unexpectedly. I tried it twice and encountered the same situation, until the third time, it was successfully executed. I want to know what the reason is

the platform version of the problem and what methods you have tried

Ubuntu 18.10 CPU Generation 8 i5 memory 8G
docker 18.06MySQL 5.6G

related codes

/ / this is docker"s log

2018-11-29T07:57:53.748628846Z Main thread process no. 1, id 140634823509760, state: enforcing dict cache limit
2018-11-29T07:57:53.748638650Z Number of rows inserted 0, updated 0, deleted 500000, read 1000025
2018-11-29T07:57:53.748648265Z 0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
2018-11-29T07:57:53.748657822Z ----------------------------
2018-11-29T07:57:53.748667432Z END OF INNODB MONITOR OUTPUT
2018-11-29T07:57:53.748677298Z ============================
2018-11-29T07:58:01.330201271Z InnoDB: -sharp-sharp-sharp-sharp-sharp-sharp Diagnostic info printed to the standard error stream
2018-11-29T07:58:01.330256078Z InnoDB: Error: semaphore wait has lasted > 600 seconds
2018-11-29T07:58:01.330271953Z InnoDB: We intentionally crash the server, because it appears to be hung.
2018-11-29T07:58:01.330283530Z 2018-11-29 07:58:01 7fe819b2e700  InnoDB: Assertion failure in thread 140634840295168 in file srv0srv.cc line 1757
2018-11-29T07:58:01.330294135Z InnoDB: We intentionally generate a memory trap.
2018-11-29T07:58:01.330304101Z InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2018-11-29T07:58:01.330314217Z InnoDB: If you get repeated assertion failures or crashes, even
2018-11-29T07:58:01.330353114Z InnoDB: immediately after the mysqld startup, there may be
2018-11-29T07:58:01.330364784Z InnoDB: corruption in the InnoDB tablespace. Please refer to
2018-11-29T07:58:01.330375697Z InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
2018-11-29T07:58:01.330385931Z InnoDB: about forcing recovery.
2018-11-29T07:58:01.330395975Z 07:58:01 UTC - mysqld got signal 6 ;
2018-11-29T07:58:01.330408020Z This could be because you hit a bug. It is also possible that this binary
2018-11-29T07:58:01.330419073Z or one of the libraries it was linked against is corrupt, improperly built,
2018-11-29T07:58:01.330428760Z or misconfigured. This error can also be caused by malfunctioning hardware.
2018-11-29T07:58:01.330438247Z We will try our best to scrape up some info that will hopefully help
2018-11-29T07:58:01.330448883Z diagnose the problem, but since we have already crashed, 
2018-11-29T07:58:01.330458865Z something is definitely wrong and this may fail.
2018-11-29T07:58:01.330468227Z 
2018-11-29T07:58:01.330477549Z key_buffer_size=8388608
2018-11-29T07:58:01.330486914Z read_buffer_size=131072
2018-11-29T07:58:01.330496185Z max_used_connections=3
2018-11-29T07:58:01.330506383Z max_threads=151
2018-11-29T07:58:01.330517415Z thread_count=1
2018-11-29T07:58:01.330527401Z connection_count=1
2018-11-29T07:58:01.330537193Z It is possible that mysqld could use up to 
2018-11-29T07:58:01.330547634Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68108 K  bytes of memory
2018-11-29T07:58:01.330557770Z Hope that"s ok; if not, decrease some variables in the equation.
2018-11-29T07:58:01.330567551Z 
2018-11-29T07:58:01.330578014Z Thread pointer: 0x0
2018-11-29T07:58:01.330587976Z Attempting backtrace. You can use the following information to find out
2018-11-29T07:58:01.330598936Z where mysqld died. If you see no messages after this, something went
2018-11-29T07:58:01.330609343Z terribly wrong...
2018-11-29T07:58:01.330624111Z stack_bottom = 0 thread_stack 0x40000
2018-11-29T07:58:01.332006805Z mysqld(my_print_stacktrace+0x2c)[0x55da4cb9d05c]
2018-11-29T07:58:01.332397783Z mysqld(handle_fatal_signal+0x4b1)[0x55da4c93ab51]
2018-11-29T07:58:01.332416149Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fe82f3e90c0]
2018-11-29T07:58:01.332426557Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fe82df85fff]
2018-11-29T07:58:01.332529820Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fe82df8742a]
2018-11-29T07:58:01.333542705Z mysqld(+0x7a6e98)[0x55da4cc81e98]
2018-11-29T07:58:01.333555593Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7fe82f3df494]
2018-11-29T07:58:01.333701818Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fe82e03bacf]
2018-11-29T07:58:01.333737718Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2018-11-29T07:58:01.333749000Z information that should help you find out what is causing the crash.

I hope someone can help me solve it, is it because there is not enough memory? Or is it something else? How can I prevent this situation?

Dec.24,2021

set global innodb_adaptive_hash_index=0;
see if there will be another restart

Menu