Mysql容器持续重启You can use the following information to find out 2022-11-30T02:14:55.156651911Z where mysqld died.terribly wrong…()-sql
Mysql容器持续重启You can use the following information to find out 2022-11-30T02:14:55.156651911Z where mysqld died.terribly wrong…()
迁移MySQL容器从一台服务器到另外一台服务器后，容器持续重启，信息如下：
2022-11-30T02:14:55.156625218Z max_threads=500
2022-11-30T02:14:55.156628081Z thread_count=0
2022-11-30T02:14:55.156631205Z connection_count=0
2022-11-30T02:14:55.156634058Z It is possible that mysqld could use up to
2022-11-30T02:14:55.156636997Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 206887 K bytes of memory
2022-11-30T02:14:55.156640049Z Hope that’s ok; if not, decrease some variables in the equation.
2022-11-30T02:14:55.156643238Z
2022-11-30T02:14:55.156645999Z Thread pointer: 0x0
2022-11-30T02:14:55.156648903Z Attempting backtrace. You can use the following information to find out
2022-11-30T02:14:55.156651911Z where mysqld died. If you see no messages after this, something went
2022-11-30T02:14:55.156655053Z terribly wrong…
2022-11-30T02:14:55.156736457Z 77 78 stack_bottom = 0 thread_stack 0x40000
2022-11-30T02:14:55.157747585Z 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 mysqld(my_print_stacktrace+0x2c)[0x55c41b69898c]
2022-11-30T02:14:55.158160041Z 94 95 96 97 98 99 mysqld(handle_fatal_signal+0x501)[0x55c41af98f71]
2022-11-30T02:14:55.158171867Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fa0e063a730]
2022-11-30T02:14:55.158188923Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7fa0e01157bb]
2022-11-30T02:14:55.158202042Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7fa0e0100535]
2022-11-30T02:14:55.158604564Z mysqld(+0x6c3e0f)[0x55c41af5fe0f]
2022-11-30T02:14:55.159002341Z mysqld(+0x6c41ed)[0x55c41af601ed]
2022-11-30T02:14:55.159592825Z mysqld(_Z25page_cur_parse_insert_recmPKhS0_P11buf_block_tP12dict_index_tP5mtr_t+0x937)[0x55c41b8c1697]
2022-11-30T02:14:55.160187143Z mysqld(+0x1001cf0)[0x55c41b89dcf0]
2022-11-30T02:14:55.160775571Z mysqld(_Z22recv_recover_page_funcmP11buf_block_t+0x8ab)[0x55c41b89eb7b]
2022-11-30T02:14:55.161365916Z mysqld(_Z20buf_page_io_completeP10buf_page_tb+0x31a)[0x55c41b9faf7a]
2022-11-30T02:14:55.161934954Z mysqld(_Z12fil_aio_waitm+0x10f)[0x55c41ba6913f]
2022-11-30T02:14:55.162517976Z mysqld(io_handler_thread+0xa8)[0x55c41b963e88]
2022-11-30T02:14:55.162522744Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7fa0e062ffa3]
2022-11-30T02:14:55.162556382Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fa0e01d74cf]
2022-11-30T02:14:55.162561313Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2022-11-30T02:14:55.162564409Z information that should help you find out what is causing the crash.
2022-11-30T02:15:55.888897279Z 2022-11-30 10:15:55+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.36-1debian10 started.
2022-11-30T02:15:55.993553673Z 2022-11-30 10:15:55+08:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’
2022-11-30T02:15:56.002747365Z 2022-11-30 10:15:56+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.36-1debian10 started.
2022-11-30T02:15:56.332120572Z 2022-11-30T02:15:56.327748Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).
2022-11-30T02:15:56.332136825Z 2022-11-30T02:15:56.330172Z 0 [Note] mysqld (mysqld 5.7.36) starting as process 1 …
2022-11-30T02:15:56.333771634Z 2022-11-30T02:15:56.333706Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-11-30T02:15:56.333792845Z 2022-11-30T02:15:56.333727Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-11-30T02:15:56.333797042Z 2022-11-30T02:15:56.333731Z 0 [Note] InnoDB: Uses event mutexes
2022-11-30T02:15:56.333800496Z 2022-11-30T02:15:56.333735Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-11-30T02:15:56.333804065Z 2022-11-30T02:15:56.333738Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-11-30T02:15:56.333807340Z 2022-11-30T02:15:56.333744Z 0 [Note] InnoDB: Using Linux native AIO
2022-11-30T02:15:56.334315238Z 2022-11-30T02:15:56.334278Z 0 [Note] InnoDB: Number of pools: 1
2022-11-30T02:15:56.334463358Z 2022-11-30T02:15:56.334428Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-11-30T02:15:56.336716335Z 2022-11-30T02:15:56.336665Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-11-30T02:15:56.347031658Z 2022-11-30T02:15:56.346987Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-11-30T02:15:56.349784983Z 2022-11-30T02:15:56.349730Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2022-11-30T02:15:56.362019261Z 2022-11-30T02:15:56.361974Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2022-11-30T02:15:56.363497080Z 2022-11-30T02:15:56.363455Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 16769275155
2022-11-30T02:15:56.363550016Z 2022-11-30T02:15:56.363522Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 16769336906
2022-11-30T02:15:56.364908428Z 2022-11-30T02:15:56.364869Z 0 [Note] InnoDB: Database was not shutdown normally!
2022-11-30T02:15:56.364914442Z 2022-11-30T02:15:56.364879Z 0 [Note] InnoDB: Starting crash recovery.
2022-11-30T02:15:56.385297501Z 2022-11-30T02:15:56.385244Z 0 [Note] InnoDB: Starting an apply batch of log records to the database…
2022-11-30T02:15:56.390699511Z InnoDB: Progress in percent: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 2022-11-30T02:15:56.390660Z 0 [ERROR] [FATAL] InnoDB: is_short 0, info_and_status_bits 0, offset 7575, o_offset 22, mismatch index 31227, end_seg_len 9 parsed len 3
2022-11-30T02:15:56.390722863Z 2022-11-30 10:15:56 0x7f8d9c9f2700 InnoDB: Assertion failure in thread 140246194792192 in file ut0ut.cc line 921
2022-11-30T02:15:56.390728835Z InnoDB: We intentionally generate a memory trap.
2022-11-30T02:15:56.390732056Z InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2022-11-30T02:15:56.390735063Z InnoDB: If you get repeated assertion failures or crashes, even
2022-11-30T02:15:56.390738010Z InnoDB: immediately after the mysqld startup, there may be
2022-11-30T02:15:56.390741084Z InnoDB: corruption in the InnoDB tablespace. Please refer to
2022-11-30T02:15:56.390744172Z InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
2022-11-30T02:15:56.390747193Z InnoDB: about forcing recovery.
2022-11-30T02:15:56.390755118Z 02:15:56 UTC – mysqld got signal 6 ;
2022-11-30T02:15:56.390758131Z This could be because you hit a bug. It is also possible that this binary
2022-11-30T02:15:56.390761347Z or one of the libraries it was linked against is corrupt, improperly built,
2022-11-30T02:15:56.390764214Z or misconfigured. This error can also be caused by malfunctioning hardware.
2022-11-30T02:15:56.390767154Z Attempting to collect some information that could help diagnose the problem.
2022-11-30T02:15:56.390770153Z As this is a crash and something is definitely wrong, the information
2022-11-30T02:15:56.390773363Z collection process might fail.
2022-11-30T02:15:56.390782688Z
2022-11-30T02:15:56.390790912Z key_buffer_size=8388608
2022-11-30T02:15:56.390794088Z read_buffer_size=131072
2022-11-30T02:15:56.390804617Z max_used_connections=0
2022-11-30T02:15:56.390817998Z max_threads=500
2022-11-30T02:15:56.390823256Z thread_count=0
2022-11-30T02:15:56.390826189Z connection_count=0
2022-11-30T02:15:56.390829129Z It is possible that mysqld could use up to
2022-11-30T02:15:56.390832322Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 206887 K bytes of memory
2022-11-30T02:15:56.390835477Z Hope that’s ok; if not, decrease some variables in the equation.
2022-11-30T02:15:56.390838630Z
2022-11-30T02:15:56.390841381Z Thread pointer: 0x0
2022-11-30T02:15:56.390844343Z Attempting backtrace. You can use the following information to find out
2022-11-30T02:15:56.390847265Z where mysqld died. If you see no messages after this, something went
2022-11-30T02:15:56.390850206Z terribly wrong…
2022-11-30T02:15:56.390925513Z 75 76 77 stack_bottom = 0 thread_stack 0x40000
2022-11-30T02:15:56.391907126Z 78 79 80 81 82 83 84 85 86 87 88 89 90 91 mysqld(my_print_stacktrace+0x2c)[0x55557b64598c]
2022-11-30T02:15:56.392322250Z 92 93 94 95 96 97 mysqld(handle_fatal_signal+0x501)[0x55557af45f71]
2022-11-30T02:15:56.392327083Z 98 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f8da89d8730]
2022-11-30T02:15:56.392365480Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f8da84b37bb]
2022-11-30T02:15:56.392375323Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f8da849e535]
2022-11-30T02:15:56.392773987Z 99 mysqld(+0x6c3e0f)[0x55557af0ce0f]
2022-11-30T02:15:56.393167575Z mysqld(+0x6c41ed)[0x55557af0d1ed]
2022-11-30T02:15:56.393759410Z mysqld(_Z25page_cur_parse_insert_recmPKhS0_P11buf_block_tP12dict_index_tP5mtr_t+0x937)[0x55557b86e697]
2022-11-30T02:15:56.394351587Z mysqld(+0x1001cf0)[0x55557b84acf0]
2022-11-30T02:15:56.394946085Z mysqld(_Z22recv_recover_page_funcmP11buf_block_t+0x8ab)[0x55557b84bb7b]
2022-11-30T02:15:56.395519850Z mysqld(_Z20buf_page_io_completeP10buf_page_tb+0x31a)[0x55557b9a7f7a]
2022-11-30T02:15:56.396097883Z mysqld(_Z12fil_aio_waitm+0x10f)[0x55557ba1613f]
2022-11-30T02:15:56.396680487Z mysqld(io_handler_thread+0xa8)[0x55557b910e88]
2022-11-30T02:15:56.396686164Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7f8da89cdfa3]
2022-11-30T02:15:56.396716397Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f8da85754cf]
2022-11-30T02:15:56.396721333Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2022-11-30T02:15:56.396724558Z information that should help you find out what is causing the crash.
解决办法：找到如下3个文件
$sudo find / -name ibdata*
../mysql/data/docker/mysql/ibdata1
$sudo find / -name ib_logfile*
../mysql/data/docker/mysql/ib_logfile0
../mysql/data/docker/mysq/lib_logfile1
然后删除找到的文件。
结束。
迁移MySQL容器从一台服务器到另外一台服务器后，容器持续重启，信息如下：
2022-11-30T02:14:55.156625218Z max_threads=500
2022-11-30T02:14:55.156628081Z thread_count=0
2022-11-30T02:14:55.156631205Z connection_count=0
2022-11-30T02:14:55.156634058Z It is possible that mysqld could use up to
2022-11-30T02:14:55.156636997Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 206887 K bytes of memory
2022-11-30T02:14:55.156640049Z Hope that’s ok; if not, decrease some variables in the equation.
2022-11-30T02:14:55.156643238Z
2022-11-30T02:14:55.156645999Z Thread pointer: 0x0
2022-11-30T02:14:55.156648903Z Attempting backtrace. You can use the following information to find out
2022-11-30T02:14:55.156651911Z where mysqld died. If you see no messages after this, something went
2022-11-30T02:14:55.156655053Z terribly wrong…
2022-11-30T02:14:55.156736457Z 77 78 stack_bottom = 0 thread_stack 0x40000
2022-11-30T02:14:55.157747585Z 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 mysqld(my_print_stacktrace+0x2c)[0x55c41b69898c]
2022-11-30T02:14:55.158160041Z 94 95 96 97 98 99 mysqld(handle_fatal_signal+0x501)[0x55c41af98f71]
2022-11-30T02:14:55.158171867Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7fa0e063a730]
2022-11-30T02:14:55.158188923Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7fa0e01157bb]
2022-11-30T02:14:55.158202042Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7fa0e0100535]
2022-11-30T02:14:55.158604564Z mysqld(+0x6c3e0f)[0x55c41af5fe0f]
2022-11-30T02:14:55.159002341Z mysqld(+0x6c41ed)[0x55c41af601ed]
2022-11-30T02:14:55.159592825Z mysqld(_Z25page_cur_parse_insert_recmPKhS0_P11buf_block_tP12dict_index_tP5mtr_t+0x937)[0x55c41b8c1697]
2022-11-30T02:14:55.160187143Z mysqld(+0x1001cf0)[0x55c41b89dcf0]
2022-11-30T02:14:55.160775571Z mysqld(_Z22recv_recover_page_funcmP11buf_block_t+0x8ab)[0x55c41b89eb7b]
2022-11-30T02:14:55.161365916Z mysqld(_Z20buf_page_io_completeP10buf_page_tb+0x31a)[0x55c41b9faf7a]
2022-11-30T02:14:55.161934954Z mysqld(_Z12fil_aio_waitm+0x10f)[0x55c41ba6913f]
2022-11-30T02:14:55.162517976Z mysqld(io_handler_thread+0xa8)[0x55c41b963e88]
2022-11-30T02:14:55.162522744Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7fa0e062ffa3]
2022-11-30T02:14:55.162556382Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fa0e01d74cf]
2022-11-30T02:14:55.162561313Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2022-11-30T02:14:55.162564409Z information that should help you find out what is causing the crash.
2022-11-30T02:15:55.888897279Z 2022-11-30 10:15:55+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.36-1debian10 started.
2022-11-30T02:15:55.993553673Z 2022-11-30 10:15:55+08:00 [Note] [Entrypoint]: Switching to dedicated user ‘mysql’
2022-11-30T02:15:56.002747365Z 2022-11-30 10:15:56+08:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 5.7.36-1debian10 started.
2022-11-30T02:15:56.332120572Z 2022-11-30T02:15:56.327748Z 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use –explicit_defaults_for_timestamp server option (see documentation for more details).
2022-11-30T02:15:56.332136825Z 2022-11-30T02:15:56.330172Z 0 [Note] mysqld (mysqld 5.7.36) starting as process 1 …
2022-11-30T02:15:56.333771634Z 2022-11-30T02:15:56.333706Z 0 [Note] InnoDB: PUNCH HOLE support available
2022-11-30T02:15:56.333792845Z 2022-11-30T02:15:56.333727Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-11-30T02:15:56.333797042Z 2022-11-30T02:15:56.333731Z 0 [Note] InnoDB: Uses event mutexes
2022-11-30T02:15:56.333800496Z 2022-11-30T02:15:56.333735Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-11-30T02:15:56.333804065Z 2022-11-30T02:15:56.333738Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-11-30T02:15:56.333807340Z 2022-11-30T02:15:56.333744Z 0 [Note] InnoDB: Using Linux native AIO
2022-11-30T02:15:56.334315238Z 2022-11-30T02:15:56.334278Z 0 [Note] InnoDB: Number of pools: 1
2022-11-30T02:15:56.334463358Z 2022-11-30T02:15:56.334428Z 0 [Note] InnoDB: Using CPU crc32 instructions
2022-11-30T02:15:56.336716335Z 2022-11-30T02:15:56.336665Z 0 [Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
2022-11-30T02:15:56.347031658Z 2022-11-30T02:15:56.346987Z 0 [Note] InnoDB: Completed initialization of buffer pool
2022-11-30T02:15:56.349784983Z 2022-11-30T02:15:56.349730Z 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2022-11-30T02:15:56.362019261Z 2022-11-30T02:15:56.361974Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2022-11-30T02:15:56.363497080Z 2022-11-30T02:15:56.363455Z 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 16769275155
2022-11-30T02:15:56.363550016Z 2022-11-30T02:15:56.363522Z 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 16769336906
2022-11-30T02:15:56.364908428Z 2022-11-30T02:15:56.364869Z 0 [Note] InnoDB: Database was not shutdown normally!
2022-11-30T02:15:56.364914442Z 2022-11-30T02:15:56.364879Z 0 [Note] InnoDB: Starting crash recovery.
2022-11-30T02:15:56.385297501Z 2022-11-30T02:15:56.385244Z 0 [Note] InnoDB: Starting an apply batch of log records to the database…
2022-11-30T02:15:56.390699511Z InnoDB: Progress in percent: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 2022-11-30T02:15:56.390660Z 0 [ERROR] [FATAL] InnoDB: is_short 0, info_and_status_bits 0, offset 7575, o_offset 22, mismatch index 31227, end_seg_len 9 parsed len 3
2022-11-30T02:15:56.390722863Z 2022-11-30 10:15:56 0x7f8d9c9f2700 InnoDB: Assertion failure in thread 140246194792192 in file ut0ut.cc line 921
2022-11-30T02:15:56.390728835Z InnoDB: We intentionally generate a memory trap.
2022-11-30T02:15:56.390732056Z InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2022-11-30T02:15:56.390735063Z InnoDB: If you get repeated assertion failures or crashes, even
2022-11-30T02:15:56.390738010Z InnoDB: immediately after the mysqld startup, there may be
2022-11-30T02:15:56.390741084Z InnoDB: corruption in the InnoDB tablespace. Please refer to
2022-11-30T02:15:56.390744172Z InnoDB: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
2022-11-30T02:15:56.390747193Z InnoDB: about forcing recovery.
2022-11-30T02:15:56.390755118Z 02:15:56 UTC – mysqld got signal 6 ;
2022-11-30T02:15:56.390758131Z This could be because you hit a bug. It is also possible that this binary
2022-11-30T02:15:56.390761347Z or one of the libraries it was linked against is corrupt, improperly built,
2022-11-30T02:15:56.390764214Z or misconfigured. This error can also be caused by malfunctioning hardware.
2022-11-30T02:15:56.390767154Z Attempting to collect some information that could help diagnose the problem.
2022-11-30T02:15:56.390770153Z As this is a crash and something is definitely wrong, the information
2022-11-30T02:15:56.390773363Z collection process might fail.
2022-11-30T02:15:56.390782688Z
2022-11-30T02:15:56.390790912Z key_buffer_size=8388608
2022-11-30T02:15:56.390794088Z read_buffer_size=131072
2022-11-30T02:15:56.390804617Z max_used_connections=0
2022-11-30T02:15:56.390817998Z max_threads=500
2022-11-30T02:15:56.390823256Z thread_count=0
2022-11-30T02:15:56.390826189Z connection_count=0
2022-11-30T02:15:56.390829129Z It is possible that mysqld could use up to
2022-11-30T02:15:56.390832322Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 206887 K bytes of memory
2022-11-30T02:15:56.390835477Z Hope that’s ok; if not, decrease some variables in the equation.
2022-11-30T02:15:56.390838630Z
2022-11-30T02:15:56.390841381Z Thread pointer: 0x0
2022-11-30T02:15:56.390844343Z Attempting backtrace. You can use the following information to find out
2022-11-30T02:15:56.390847265Z where mysqld died. If you see no messages after this, something went
2022-11-30T02:15:56.390850206Z terribly wrong…
2022-11-30T02:15:56.390925513Z 75 76 77 stack_bottom = 0 thread_stack 0x40000
2022-11-30T02:15:56.391907126Z 78 79 80 81 82 83 84 85 86 87 88 89 90 91 mysqld(my_print_stacktrace+0x2c)[0x55557b64598c]
2022-11-30T02:15:56.392322250Z 92 93 94 95 96 97 mysqld(handle_fatal_signal+0x501)[0x55557af45f71]
2022-11-30T02:15:56.392327083Z 98 /lib/x86_64-linux-gnu/libpthread.so.0(+0x12730)[0x7f8da89d8730]
2022-11-30T02:15:56.392365480Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x10b)[0x7f8da84b37bb]
2022-11-30T02:15:56.392375323Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x121)[0x7f8da849e535]
2022-11-30T02:15:56.392773987Z 99 mysqld(+0x6c3e0f)[0x55557af0ce0f]
2022-11-30T02:15:56.393167575Z mysqld(+0x6c41ed)[0x55557af0d1ed]
2022-11-30T02:15:56.393759410Z mysqld(_Z25page_cur_parse_insert_recmPKhS0_P11buf_block_tP12dict_index_tP5mtr_t+0x937)[0x55557b86e697]
2022-11-30T02:15:56.394351587Z mysqld(+0x1001cf0)[0x55557b84acf0]
2022-11-30T02:15:56.394946085Z mysqld(_Z22recv_recover_page_funcmP11buf_block_t+0x8ab)[0x55557b84bb7b]
2022-11-30T02:15:56.395519850Z mysqld(_Z20buf_page_io_completeP10buf_page_tb+0x31a)[0x55557b9a7f7a]
2022-11-30T02:15:56.396097883Z mysqld(_Z12fil_aio_waitm+0x10f)[0x55557ba1613f]
2022-11-30T02:15:56.396680487Z mysqld(io_handler_thread+0xa8)[0x55557b910e88]
2022-11-30T02:15:56.396686164Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7fa3)[0x7f8da89cdfa3]
2022-11-30T02:15:56.396716397Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7f8da85754cf]
2022-11-30T02:15:56.396721333Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2022-11-30T02:15:56.396724558Z information that should help you find out what is causing the crash.
解决办法：找到如下3个文件
$sudo find / -name ibdata*
../mysql/data/docker/mysql/ibdata1
$sudo find / -name ib_logfile*
../mysql/data/docker/mysql/ib_logfile0
../mysql/data/docker/mysq/lib_logfile1
然后删除找到的文件。
结束。