记录一次 MYSQL 应急运维的过程

今天接到通知,有专家将对公司的X 项目进行检查 , X 项目的数据库 是MYSQL 5.7.24 版本的 , 不知道为什总是频繁的异常重启。
项目上的小伙伴为了保证系统的稳定,决定将后台切换的 MYSQL 5.7.25 版本的数据库去运行。
但切换数据库后出现了 ORDER BY clause is not in SELECT list 这一 SQL 报错 , 项目上的小伙伴不知道具体的发生原因,遂切回原来的 5.7.24 版本的数据库
但报错信息依旧存在 ,百度查得 这一错误是应为MYSQL 5.7 默认启用了 ONLY_FULL_GROUP_BY 配置导致的 , 于是小伙伴修改了 /etc/my.cnf 并重启 MYSQL,但报错信息依旧存在。

被找到的时候,其实我也很迷茫。 因为 /etc/my.cnf 我看过了 , 没有问题啊 。 而且配置文件是 公司自动化部署脚本自动部署的 , 为什么其他项目可以正常使用 ,但是 X 项目就不行了呢?
由于事情紧急,使用 ROOT 账号登录到数据库 , 使用 select @@global.sql_mode; 查到,当前MYSQL 确实开启了 ONLY_FULL_GROUP_BY 功能 , 这就很奇怪了 …
使用 set @@global.sql_mode ='' 临时修改了MYSQL 的全局配置 , 项目正常运行

晚上闲下来的时候就在想 ,为什么 /etc/my.cnf 的配置不生效呢
百度了一下,通过 /usr/local/mysql/bin/mysqld --verbose --help |grep -A 1 'Default options' 查看当前MYSQL 的 配置文件
结果看到了这样的回显

本来按照[Warning] = [OK] 的习惯,我直接忽视了这个报警,那么 现在MYSQL 到底使用了那个配置文件呢?
我一路 cat 下去

发现系统中除了 /etc/my.cnf 以外其他配置文件都不存在。
这…,仔细看看[Warning]消息。在 ll 一下 /etc/my.cnf , 我明白问题的关键了
因为系统中的/etc/my.cnf 被赋予了 777 权限 , MYSQL 任务该文件是任意用户可读的不安全文件,所以自动忽略了这个配置文件,又因为没有其他配置文件,所以 MYSQL 使用默认配置启动
chmod 644 /etc/my.cnf 并重启MYSQL , 查得问题解决,配置文件生效。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇