首页 > 数据库 >Mysql容器持续重启You can use the following information to find out 2022-11-30T02:14:55.156651911Z where my

Mysql容器持续重启You can use the following information to find out 2022-11-30T02:14:55.156651911Z where my

时间:2022-11-30 12:11:58浏览次数:43  
标签:11 30T02 use 55.156651911 15 14 mysqld 2022

迁移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

然后删除找到的文件。

结束。

标签:11,30T02,use,55.156651911,15,14,mysqld,2022
From: https://www.cnblogs.com/liusingbon/p/16938034.html

相关文章

  • Use Closures Not Enumerations
    ​​http://c2.com/​​ UseClosuresNotEnumerationsIwasreallydisappointedwhenthisturnedoutnottobereferringtoenums... Thisisoneofthe ​​J......
  • pybind11
    pybind11.hpppybind11.cpp#include"pybind11.hpp"#include<stdio.h>#include<iostream>usingnamespacestd;namespacepy=pybind11;classAnimal{public......
  • VIJOS-P1132(求先序遍历,已知中后)
    描述    给出一棵二叉树的中序与后序排列。求出它的先序排列。(约定树结点用不同的大写字母表示,长度≤8)。输入第一行为二叉树的中序序列第二行为二叉树的后序......
  • react18使用useContext实现多级多级间传值与修改
     a、组件关系:依次嵌套Demo2->Demo2ComA->Demo2CompAA。。。b、实现可实现Demo2ComA与Demo2CompAA两组件间数据获取与修改(多层次嵌套时,也可实现,此处仅展示2......
  • 题解 UVA11244
    题解UVA11244题目大意:判断大小为1连通块有几个这个题说实话真的挺水的,你可以考虑用dfs来判断联通块然后记录大小这只是其中一个思路,另一个思路是,直接判断*的8连......
  • 在 win11 下搭建并使用 ubuntu 子系统(同时测试 win10)——(附带深度学习环境搭建)
    对于一个深度学习从事者来说,Windows训练模型有着诸多不便,还好现在Windows的Ubuntu子系统逐渐完善,近期由于工作需求,配置了Windows的工作站,为了方便起见,搭建了Ubuntu子系......
  • 题解 CF1711B
    题解CF1711B这个题说明了,蛋糕的个数只跟好友的对数有关,跟去的人或者是单个的人的个数是无关的(是不是单个的人去没有蛋糕吃)所以我们就要考虑,怎样才能满足吃掉的蛋糕正好......
  • kx-000011-按位置删除元素,remove
    顺序表结构体定义。具体的结构体定义请查看头文件:https://www.cnblogs.com/kxwslmsps/p/16937235.htmltypedefstatusint;//定义函数结果状态typedefintetyp......
  • Wargames-Bandit-Level11
    Level11目录Level11LevelGoalSolutionLevelGoalThepasswordforthenextlevelisstoredinthefiledata.txt,wherealllowercase(a-z)anduppercase(A-Z......
  • 云计算CloudSim20221128
    在写顺序策略调度虚拟机时出现了问题原本应该是设置4台虚拟机8个任务按顺序分配,但是这里只有四个任务核两台机器发现日志中有这么几行在host中分配虚拟机失败因为MIP......