本文主要目的是记录拿到一台陌生机器的时候故障处理的思路，不想看思路的可以直接跳到最后看修复命令(^_−)~

  周末一个小伙伴聊天说Cacti页面打开有故障，初步了解服务器经历了异常断电。

  根据页面错误提示，数据库引起的故障，沟通后得知简单的MySQL服务重启没有效果，于是决定饭后远程登录进行排查。

  登录CactiEZ主机，由于不太清楚这台机器之前的情况，先简单看下版本发现是CentOS 6（这步操作是为了了解系统的命令风格）。

cat /etc/system-release

  然后查看下系统日志，大致了解发生了啥：

tail -100 /var/log/messages

  从图中最后显示来看，凌晨的时候Cacti那会儿连不上数据库了。

  根据上面messages的内容，确认一下套接字文件发现目前正常（毕竟小伙伴刚刚成功重启过数据库了），尝试连接数据库也没问题：

ls -shal /var/lib/mysql/mysql.sock
mysql -uroot -p

  那就看看mysql现在内部发生过什么错误吧，毕竟页面打开也提示和host表有关系。查看数据库日志存放位置：

show variables like 'log_%';

  定位到日志路径后，查看日志（注意我们会习惯性查看日志文件大小，生产环境一定不要在不了解文件大小情况下直接打开文件，避免出现大文件读取吃掉内存的意外）：

ls -shal /var/log/mysqld.log
tail -100 /var/log/mysqld.log

  查看日志内容，发现果然经过服务器重启连接问题已经解决，但那张叫做host的表还是损坏状态：

  登录数据库，定位到host表的位置：

show databases;
use cacti;
show tables;

  发现cacti数据库里确实有个叫host的表。我们可以尝试查看host表现在的样子，但这里就跟不要盲目打开大文件是一个道理，生产环境数据库里查询时不要在不清楚表的容量的情况下盲目执行查询，避免出现大量查询影响数据库。怎么办呢，可以定位查看表的容量，如果容量较小，可以直接查询，如果容量较大，则需要根据表的结构尝试查询几条数据。我们先看看host表的大小：

use information_schema;
select concat(round(sum(DATA_LENGTH/1024/1024),2),'MB') as data from TABLES\
where table_schema='cacti' and table_name='host';

  发现容量只有10K，可以直接打开。这里补充说明一下，万一表的容量很大，需要先查询表的结构：

desc host;

  这里我们可以直接查询表内容：

use cacti;
select * from host;

  发现host表已经无法打开了。那么我们需要考虑进行修复了，在修复之前，先备份一下数据库。直接备份发现由于表host损坏，会影响备份，dump出来的数据库大小异常（在之前查看表大小的时候我们也顺便查看了cacti库的大小应该是6M以上），故添加参数跳过host表进行备份：

mysqldump -u root -p cacti --ignore-table=cacti.host > cacti_20190413.sql

  备份出来的文件大小和我们预计的一样，做完了备份我们现在准备修复数据库。直接修复，会发现报错了，：

  这是因为现在系统还正在占用读写我们要修复的表，很简单，关闭httpd服务即可防止修复过程中应用层对数据库的读写：

service httpd stop
mysqlcheck -u root -p cacti --auto-repair

  可以看到修复过程没有异常，修复完毕，登录数据库，可以正常执行对host表的查询：

  启动httpd服务，登录CactiEZ的网页，发现已经可以正常使用：

service httpd start

  题外话，CactiEZ是一个中文版的Cacti整合，自身作为一个操作系统，省去了网络工程师们安装部署的烦恼。需要快速构建网络设备的监控环境的话还是十分推荐的。