暂无图片
MySQL 5.7服务异常重启
我来答
分享
Root__Liu
2022-08-23
MySQL 5.7服务异常重启

环境:

双主 + keepalived
版本:5.7.38
复制

现象:
其中一个节点重启了,但是诡异的是只有启动日志,并没有服务宕的日志或者报错。在message和error-log里面都没有发现宕机的异常点,如下error-log:

2022-08-22T20:15:57.465802+08:00 9705 [Note] Got an error reading communication packets
2022-08-22T20:16:03.004961+08:00 9707 [Note] Got an error reading communication packets
2022-08-22T20:16:09.238795+08:00 9708 [Note] Got an error reading communication packets
2022-08-22T20:16:15.484480+08:00 9710 [Note] Got an error reading communication packets
2022-08-22T20:16:20.611301+08:00 9711 [Note] Got an error reading communication packets
2022-08-22T20:16:26.876640+08:00 9713 [Note] Got an error reading communication packets
2022-08-22T20:16:32.462721+08:00 9715 [Note] Got an error reading communication packets
2022-08-22T20:16:38.417674+08:00 9717 [Note] Got an error reading communication packets
2022-08-22T20:16:44.238416+08:00 9718 [Note] Got an error reading communication packets
2022-08-22T20:16:50.255752+08:00 9719 [Note] Got an error reading communication packets
2022-08-22T20:16:56.215739+08:00 9720 [Note] Got an error reading communication packets
2022-08-22T20:17:10.175327+08:00 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.
2022-08-22T20:17:10.175511+08:00 0 [Warning] 'NO_AUTO_CREATE_USER' sql mode was not set.
2022-08-22T20:17:10.177930+08:00 0 [Note] /usr/sbin/mysqld (mysqld 5.7.38-enterprise-commercial-advanced-log) starting as process 4385 ...
2022-08-22T20:17:10.301503+08:00 0 [Note] InnoDB: PUNCH HOLE support available
2022-08-22T20:17:10.301583+08:00 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2022-08-22T20:17:10.301594+08:00 0 [Note] InnoDB: Uses event mutexes
2022-08-22T20:17:10.301603+08:00 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2022-08-22T20:17:10.301614+08:00 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-08-22T20:17:10.301622+08:00 0 [Note] InnoDB: Using Linux native AIO
2022-08-22T20:17:10.304611+08:00 0 [Note] InnoDB: Number of pools: 1
2022-08-22T20:17:10.305220+08:00 0 [Note] InnoDB: Using CPU crc32 instructions
2022-08-22T20:17:10.313681+08:00 0 [Note] InnoDB: Initializing buffer pool, total size = 75G, instances = 8, chunk size = 128M
2022-08-22T20:17:14.412285+08:00 0 [Note] InnoDB: Completed initialization of buffer pool
2022-08-22T20:17:14.880688+08:00 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2022-08-22T20:17:14.898022+08:00 0 [Note] InnoDB: Highest supported file format is Barracuda.
2022-08-22T20:17:15.267908+08:00 0 [Note] InnoDB: Log scan progressed past the checkpoint lsn 406127388625
2022-08-22T20:17:15.280827+08:00 0 [Note] InnoDB: Doing recovery: scanned up to log sequence number 406127598149
2022-08-22T20:17:15.281340+08:00 0 [Note] InnoDB: Database was not shutdown normally!
2022-08-22T20:17:15.281360+08:00 0 [Note] InnoDB: Starting crash recovery.
2022-08-22T20:17:15.629491+08:00 0 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
2022-08-22T20:17:18.457506+08:00 0 [Note] InnoDB: Apply batch completed
2022-08-22T20:17:18.457558+08:00 0 [Note] InnoDB: Last MySQL binlog file position 0 16404727, file name mysql-bin.000006
2022-08-22T20:17:19.004933+08:00 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-08-22T20:17:19.004969+08:00 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2022-08-22T20:17:19.005073+08:00 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2022-08-22T20:17:19.019072+08:00 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2022-08-22T20:17:19.021214+08:00 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
····
复制

求教各位大神如何定位宕机并自动重启原因?

我来答
添加附件
收藏
分享
问题补充
3条回答
默认
最新
张sir

1、看下history看看是不是有啥特殊操作

2、看看/var/log/message ,查系统的问题

3、看监控,cpu、内存、io、以及数据库监控,看看是否有异常

暂无图片 评论
暂无图片 有用 0
打赏 0
刘贵宾

会不会是OOM把MySQL给杀了


dmesg | grep -i memory 

检查OOM干扰

暂无图片 评论
暂无图片 有用 2
打赏 0
薛晓刚

这个上面要么不全,要么是就这样看不出来。操作系统重启也会这样写日志

暂无图片 评论
暂无图片 有用 0
打赏 0
回答交流
Markdown


请输入正文
提交
相关推荐
MYSQL EXTRACT(type FROM d)函数的使用
回答 1
已采纳
在 MySQL 中,EXTRACT()函数用于从日期或时间值中提取特定的部分。EXTRACT(typeFROMd)函数的参数说明:type:指定要提取的日期或时间部分的类型。常见的
统计一个B表的gid等于A表id的数据有多少个,这个语句好慢,要怎么优化
回答 2
leftjoin改为innerjoin如果两个表数据量都比较大,执行计划走hashjoin会得到最佳效果。
MySQL的二进制日志(binlog)有什么重要用途?
回答 1
已采纳
二进制日志(binlog)记录着数据库的变更,还记录着每个变更花费时间的信息,记录的单位是事件(enent),不是事务(transaction),一个事务可以包含多个事件。从MySQL8.0开始,二进
请问下mysql 的decode 怎么用呢?
回答 1
已采纳
mysql没有decode函数,可以用casewhen
mysql如何跟踪ddl语句实际是如何执行的?
回答 3
自己编译源码,然后开启debug模式,应该可以看到有对应的日志输出。
mysql如何获得delete语句的真实计划?
回答 2
在MySQL中,您可以通过使用EXPLAIN关键字来获取DELETE语句的执行计划。这个命令会显示MySQL如何处理您的DELETE请求,包括它将扫描哪些索引、表以及其他相关的执行细节。例如,如果您想
MariaDB的备份用xtrabackup工具能热备份吗?
回答 1
官方没有说支持mariadb,而且源码是依赖mysql的,估计是不支持mariadb了
MySQL 8默认TCP端口都有哪些? A3306、B33060、C33063、D33062
回答 4
已采纳
ABDMySQL默认TCP端口号: 1、3306用于MySQLClassic协议(服务器端口选项) 2、33060用于MySQLX协议(服务器mysqlxport选项) 
MySQL 8.0.21 漏洞如何修复
回答 4
谢谢各位指导。
MySQL主从和oracle的adg有什么区别?
回答 2
已采纳
1、mysql主从是逻辑复制,通过binlog进行复制的,容易产生延迟。oracleadg是物理复制,是块级别的recover,速度快。2、由于是逻辑复制,mysql主从复制容易产生数据不一致的情况,