CentOS7.4 MySQL服务启动失败故障排查及解决方法

Linux如果服务器意外断电，mysql服务启动失败。

关闭服务器后MySQL服务无法启动的解决方案：第一步是创建mysqld.pid文件。
在/tmp目录中，使用cd/tmp命令移动到该目录。
使用mkdir命令创建一个名为mysqld的目录。
再次使用cd命令导航到mysqld目录。
使用touch命令创建名为mysqld.pid的文件。
要返回到上一个目录，请使用cd..来实现。
调整文件权限，使用chown-Rmysql:mysql命令将mysqld目录的所有权更改为mysql用户和用户组。
再次进入mysqld目录，使用chmod755mysqld.pid调整mysqld.pid文件的权限，使其具有执行权限。
最后使用服务管理命令启动MySQL服务。
您可以尝试通过servicemysqlstart或servicemysqldstart命令重启MySQL服务。

mysql开机自动启动mysql服务失败解决方法

前段时间，有测试人员联系我寻求帮助，测试环境中的一个mysql数据库不断重启，如果他们的测试时间较长，会影响上线进度。
先说一下测试环境中的事件。
CentOS7.4系统上部署了Mysql5.7。
测试人员使用LoadRunner运行应用程序的压力测试。
出现LoadRunner日志，错误信息显示MySQL服务被终止，几秒后恢复，并断开连接。
为了排除故障，我登录到服务器并查看数据库内存，然后查看CentOS系统日志(/var/log/messages)。
由于mysql服务因OOM而暂停，之后mysql服务守护进程自动重新启动。
经验丰富的MySQL数据库运维人员应该能够快速判断OOM的原因。
首先，mysqlbufferpool内存参数配置不合理。
是的，这里没有列出4G。
修改测试环境模拟mysql5.7、centos7.7、2G内存为了更好的模拟上述故障，这里我们禁用模拟环境变量。
mtotalusedfreesharedbuff/cacheavailableMem:212456564099171398Swap:204702047[root@localhostdata]#swapon-s文使用的文件名类型大小权限/dev/dm-1partition2097148264-2[root@localhostdata]#swapoff/dev/dm-1[root@localhostdata]#FRee-mtotalusedfreesharedbuff/cacheavailableMem:212425494499251709Swap:000从上面的free-m结果来看，swap为0。
释放缓存内存[root@localhostdata]#sync[root@localhostdata]#echo1>/proc/sys/vm/drop_caches;[root@localhostdata]#free-mTotalusedfreesharedbuff/cacheavailableMem:212425417849841748Swap:000剩余内存1784M可以看到mysql数据库主要占用2大块内存ool占用，第二：这里设置初始连接占用的内存将mysql缓冲区设置为1500M，会话参数设置为read_buffer_size=32Mread_rnd_buffer_size=32Msort_buffer_size=32Mtmp_table_size=32Mmax_heap_table_size=32Mjoin_buffer_size=32M然后开始大查询操作已建立5个连接。
:40localhostkernel:内存不足:killingprocess2534(mykilled)point658为儿童牺牲8月3105:37:40本地主机:Killedprocess2534(mysqld),UID1001,total-vm:1825792kB,non-rss:654388kB,file-rss:0kB,shmem-rss:0kBmysql守护进程开始启动mysql服务/u02/my。
sql/bin/mysqld_safe：第198行：2534nohoop/u02/mysql/bin/mysqld--defaults-file=/u02/conf/my3308.cnf--basedir=/u02/mysql--被杀死。
datadir=/u02/data/3308--plugin-dir=/u02/mysql/lib/plugin--user=mysql--log-error=/u02/log/3308/error.log--open-files-limit=65535--pid-file=/u02/run/3308/mysqld.pid--socket=/u02/run/3308/mysql.sock--port=3308/dev/null>/dev/null2>&12020-08-30T21:37:40.375749Zmysqld_safe号码正在运行进程：02020-08-30T21：37：40.407781Zmysqld_Safemysqld已重新启动。
timestampserveroption(seedocumentationformoredetails).2020-08-30T21:37:40.667059Z0[note]--secure-file-privissettoNULL.与导出到数据相关的导入操作相关are2020-08-30T21:37:40.667112Z0[注意]/u02/mysql/bin/mysqld(mysq)ld5.7.26-log)process2954...2020-08-30T21:37:40.782412Z0[警告]InnoDB:使用innodb_file_format已被弃用，并且该参数可能会在未来版本中删除。
请参阅http://dev.mysql.com/doc/refman/5.7/en/innodb-file-format.html2020-08-30T21:37:40.782684Z0[注意]InnoDB:PUNCHHOLE支持Ale2020-08-30T21:37:40.782729Z0[注意]InnoDB:Mutexesandrw_locksuseGCCatomicbuiltins2020-08-30T21:37:40.782754Z0[注]InnoDB:Useseventmutexes2020-08-30T21:37:40.782772Z0[注]InnoDBB:GCCbuiltin__atomic_thread_fence()使用了fororyblock2020-08-30T21:37:40.782788Z0[note]InnoDB:Compressedtableusezlib1.2.112020-08-30T21:37:40.782841Z0[注意]innodb:从8to1sinceinnodb_buffer_poo修复innodb_buffer_pool_instancesl_sizeislessthan1024MiB2020-08-30T21:37:40.784518Z0[note]InnoDB:Numberofpools:12020-08-30T21:37:40.784865Z0[note]InnoDB对于：cpucrc32使用指令2020-08-30T21:37:40.789314Z0,chunksize=128M2020-08-30T21:37:40.834948Z0[注意]InnoDB：完成缓冲池2020-08-30T21:37:40.843612Z00[注意]InoDB：如果启用混合执行，可以更改页面清理优先级。
从priority()setmanpage。
当年B：日志可以继续。
检查点n57073942292020-08-30T21：37：40.863221Z0[注意]InnoDB：恢复作业：ScanDuplo。
gsequencenumber57073942382020-08-30T21:37:40.863231Z0[Note]InnoDB:数据库未正常关闭！2020-08-30T21:37:40.863239Z0[Note]InnoDB:崩溃返回检索.2020-08-30T21:37:40.901955Z0[Note]InnoDB:LastMySQLbinlogfileposition043848,filenamebinlog.0000252020-08-30T21:37:41.075805Z0[Note]InnoDB:临时位置数据File:"ibtmp1"2020-08-30T21:37:41.075860Z0[Note]InnoDB:为临时表创建共享空间2020-08-30T21:37:41.075952Z0[Note]InnoDB:设置文件'/u02/log/3308/iblog/ibtmp1'sizeto12MB.写入文件已满，请稍候...2020-08-30T21:37:41.254016Z0[注意]InnoDB:file'/u02/log/3308/iblog/ibtmp1'sizeisnow12MB.2020-08-30T21:37:41.255390Z0[Note]InnoDB:找到96个redorollbacksegment。
找到96个redorollback段。
Active.2020-08-30T21:37:41.255421Z0[Note]InnoDB:32RerollBackPart(s)Activee.2020-08-30T21:37:41.256171Z0[Note]InnoDB:待定purgetostart2020-08-30T21:37:41.307237Z0[Note]InnoDB:5.7.26Started;Logsequencenumber57073942382020-08-30T21:37:41.308291Z0[Note]插件联合已禁用。
2020-08-30T21:37:41.310625Z0[注]InnoDB:从/u02/log/3308/iblog/ib_buffer_pool2020-08-30T21:37:41.310785Z0[注]InnoDB:Buf加载缓冲池ferpool(s)loadcompletedat2008315:37:41(/u02/log/3308/iblog/ib_buffer_poolwasempty)2020-08-30T21:37:41.314568Z0[注]重新。
coverafteracrashusing/u02/log/3308/binlog/binlog2020-08-30T21:37:41.314730Z0[note]开始崩溃恢复...2020-08-30T21:37:41.314842Z0[note]崩溃恢复已结束.2020-08-30T21:37:41.346280Z0[Note]找到ca.pem,server-cert.pemandserver-key.pemindata目录。
支持SSL启用.2020-08-30T21:37:41.346337Z0[Note]跳过生成ssl服务器。
tificatesascertificatefilesarepresentindatadirectory.2020-08-30T21:37:41.349079Z0[警告]CAcertificateca.pemisselfsigned.2020-08-30T21:37:41.349341Z0[注意]跳过生成RSAkeypairaskeyfile：37:41.350297Z0[注意]服务器主机名（十进制地址）：'0.0.0.0';端口：33082020-08-30T21:37:41.350399Z0[注]-'0.0.0.0'resolVesto'0.0.0.0';2020-08-30T21:37:41.350475Z0[note]ServersocketcreatedonIP:'0.0.0.0'.2020-08-30T21:37:41.376794Z0[note]Failedtostartslavethreadsforchannel''2020-08-30T21:37:41.397237Z0[注意]事件时间表：Loaded0events2020-08-30T21:37:41。
397480Z0[Note]/u02/mysql/bin/mysqld:Readyforconnection.Version:'5.7.26-log'socket:'/u02/run/3308/mysql.sock'port:3308源自动分配连接会话。
配置mysql参数时终止ERROR2013(HY000):LostconnectiontoMySQLserverduringquerymysql>：确保考虑3个条件1.接收预期的业务连接总数2.会话初始化内存3.Bufferpool大小后面是会话的总内存大小和数据库缓冲池的大小mysql>select(@@innodb_buffer_pool_size+@@innodb_log_）使用它buffer_size+@@key_buffer_size)/1024/1024ASMEMORY_MB+-------------+|Memory_MB|+------------+|584.00000000|+----------+1rowinset(0.00秒)mysql>select(@@read_buffer_size+@@read_rnd_buffer_size+@@sort_buffer_size+@@tmp_table_size+@@join_buffer_size+@@binlog_cache_size)/1024/1024asMB+------------+|MB|+------------+|160.03125000|+----------+1rowinset(0.00秒)mysql总计缓冲池加上会话内存不能超过服务器总内存的80%。
服务器内存为32G，MySQL数据库内存设置不要超过26G，如果不够，可能会出现内存问题，请使用交换分区。

mysql数据库打不开MySQL启动失败的常见原因

MySQL无法启动的两个最常见的原因是系统资源无法访问和参数设置不正确。
下面我们对这些进行分析。
1、无法访问系统资源MySQL无法访问其启动所需的资源（文件、端口等）。
这是MySQL无法启动的常见原因。
由于在Linux上用于启动mysqld进程的mysql用户通常无法登录，因此您可以使用如下命令检查文件权限：sudo-umysqltouch/var/lib/mysql/b检测到问题后，通常可以通过更改相应文件或目录的权限或所有权来修复它。
但是，有些情况下mysql用户有权访问文件或目录，但被拒绝访问，如下例所示。
mysql>systemsudo-umysqltouch/home/mysql/data/amysql>createtablet1(idintprimarykey,nvarchar(10)dat)adirectoryERROR1030(HY000):Goterror168fromstorageengine测试显示mysql用户有权访问此目录，但是文件创建仍然失败。
在这种情况下，对mysqld进程的访问通常会被selinux或apparmor阻止。
Linux。
可以看到创建的表不在mysql的默认目录下。
所以可以看到该策略当前没有该目录的权限。
当然，停止selinux或apparmor。
即使您有权访问系统资源，也可能会被阻止。
占用：mysqld--no-defaults--console--usermysql2020-11-03T03:36:07.519419Z0[系统][MY-010116][服务器]/usr/sbin/mysqld(mysqld8.0.19)startingasprocess211712020-11-03T03:36:07.740347Z1[ERROR][MY-012574][InnoDB]Unabletolock./ibdata1error:11失败的原因是另一个mysqld进程启动并占用了相应的文件。
2、参数设置错误。
参数由于数据配置不正确，MySQL无法启动也是很常见的情况。
首先，您需要检查MySQL启动时调用的参数。
可以通过以下命令查询MySQL启动时参数文件的调用顺序：:$mysqld--verbose--help|grep"Defaultoptions"-A1默认选项按给定顺序从以下文件中读取：/etc/my.cnf/etc/mysql/my.cnf~/.my.cnf如果您知道MySQL参数文件调用顺序，则您可以您可以检查参数文件以查找您怀疑的任何错误。
由于参数文件较难读取，可以使用以下命令：显示mysqld程序调用的参数的命令：$mysqld--print-defaults/usr/sbin/mysqld启动时参数如下：...该命令显示参数后退出，说明不会运行。
请小心。
实际运行mysqld。
该命令与my_print_defaultsmysqld完全等效，只不过后者每行显示一个参数。
接下来开始调试可疑参数。
我个人喜欢添加的参数和顺序是：1.在mysqld后面添加第一个参数--no-defaults。
该参数的作用是告诉mysqld在启动时不要读取任何内容。
参数文件；2.第二个参数是--console。
该参数将错误消息打印到屏幕上。
缺点是所有信息都打印到屏幕上，这使得它看起来很混乱，但这对于调试非常有用。
第三个参数是--log-error-verbosity=3，用于显示详细信息。
log;4.然后在最后添加可信参数。
一次只添加一个参数，然后启动mysqld并使用排除过程逐步找到错误的参数。
看一下这个例子：mysqld--no-defaults--console--log-error-verbosity=3--usermysql--gtid_mode=on2020-11-03T07:14:20.384223Z0[备忘录][MY-010949][服务器]Basedirsetto/usr/.2020-11-03T07:14:20.384254Z0[系统][MY-010116][服务器]/usr/sbin/mysqld(mysqld8.0.19)startingasprocess226172020-11-03T07:14:20.400221Z0[备忘录][MY-012366][InnoDB]LinuxnativeAIO使用...2020-11-03T07:14:21.632851Z0[错误][MY-010912][服务器]GTID_MODE=ON需要ENFORCE_GTID_CONSISTENCY=ON。
2020-11-03T07:14:21.634183Z0[错误][MY-010119][服务器]取消……2020-11-03T07:14:23.026551Z0[System][MY-010910][Server]/usr/sbin/mysqld:Shutdowncomplete(mysqld8.0.19)MySQLCommunityServer-GPL.root@scutech:~#看这个例子，如果同时设置参数GTID_MODE和ENFORCE_GTID_CONSISTENtime,CY仅当两者同时打开时。