[Linux]运维面试(一) - 好文

1.误操作drop语句导致数据库数据被破坏,请写出恢复思想及实际大体步骤?
#所有数据的恢复都在于备份,如果没有备份,那就恢复不了.误操作后要恢复时需使用增量恢复的方法进行恢复,具体的步骤如下:
(1)查看备份与binlog文件 (2)刷新并备份binlog文件删除线格式 #mysqladmin -uroot -p123456 -S
/data/mysql.sockflush-logs (-S, --socket=name 指定soc**ket文件。)
(3)将binlog文件恢复成sql语句 #mysqlbinlog –no-defaults mysql-bin.000061
mysql-bin.000062 >bin.sql (4)将其中误操作的语句删除（就是drop的动作） (5)解压全备文件，恢复全备文件 #gzip -d
mysql_backup_2016-10-12.sql.gz #mysql -uroot -pmysql123 -S/data/3306/mysql.sock
< mysql_backup_2016-10-12.sql (如果有对表的操作，恢复数据时需要接表名) (6)恢复误操作前的binlog文件记录的sql语句
#mysql -uroot -pmysql123 -S/data/3306/mysql.sock < bin.sql
(最后登陆数据库，查看数据是否恢复成功，如果有确定的误操作时间，就直接恢复这段时间的数据即可。)*
2.列举一个实际生产的例子，网站访问速度慢是因为数据库访问慢导致的
(1)情况描述: #有一天同事反应,网站的访问速度慢.甚至出现打不开网页的情况.刷新等待好长时间又可以打开了 (2)解决措施 #登录数据库执行show
full processlist(查看有哪些线程在运行),查看有很多相同的SQL查询且针对一张表,确定网站打不开就是这个原因,解决方法是禁止此IP的访问
#建议:(1)为了避免此类问题的发生.可以安装中间件实现读写分离 (2)安装数据缓存服务器,尽量将大部分读的请求不直接对接数据库
3.通过kill -9 野蛮粗鲁的杀死数据库导致数据库启动故障,给出排错方法或是经验
(1)查看MySQL启动日志(查看log,发现mysql系统表丢失了，因为数据库数据都是测试数据，重建数据库不影响。)
(2)执行创建表的初始化脚本：(进入数据库目录# ./scripts/mysql_install_db --user=mysql
--datadir=/var/lib/mysql) (3)再次执行启动脚本：
4.IDC机房宽带突然从平时100M增加到400M,请分析原因并给出解决方法
(1)可能遭受DDOS攻击(写一个预防DDOS的脚本) (2)内部的服务器中毒,大量外发流量(内部运维规范、制度)
(3)网站的元素被盗连,在门户页面被推广导致大量流量产生(网站的基本优化) (4)合作公司来抓数据来了
5.正在工作的Linux系统,发现文件系统只读了,分析原因如何解决
(1)检查 /etc/fstab 配置，查看是否对磁盘进行了挂载。 (2)检查当前实际挂载的磁盘状态是否正确。 (3)对于 Ubuntu 或者 Debian
系统，检查磁盘挂载参数 barrier 的设置情况。 (4)通过 fsck 等工具检查文件系统状态。
6.磁盘报错"No sapce left on device",但是df -h后发现磁盘空间没有满,为什么
(1)df -h查看没有满,但df -i查看满了 (2)解决方法:
#删除/backup目录中的部分文件，释放出/backup分区的一部分inode，特别要留意那些spool出来的文件，这种文件一般会占用比较多的节点，因为比较小而且零碎，同时要多留意日志文件信息等
#用软连接将空闲分区/opt中的newcache目录连接到/data/cache，使用/opt分区的inode来缓解/backup分区inode不足的问题
ln-s /opt/newcache /data/cache #更换服务器，用高配置的服务器替换低配置的服务器
7.发现磁盘空间满了,删除了一部分Nginx access日志,可发现磁盘空间还是满的,为什么
(1)未释放磁盘空间原因：
在Linux或者Unix系统中，通过rm或者文件管理器删除文件将会从文件系统的目录结构上解除链接(unlink).然而如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。而我删除的是nginx的log文件删除的时候文件应该正在被使用
(2)解决方法重启nginx服务，或者用>/opt/nginx/logs/nginx.log清空日志文件，而不是直接删除。
8.一个tomcat启动脚本,手动执行ok,但放到计划任务里执行不成功,为什么
(1)计划任务的格式错误 (2)环境变量引起的不成功
9.描述MySQL主从复制原理
(1)从库生成两个线程，一个I/O线程，一个SQL线程； (2)i/o线程去请求主库的binlog，并将得到的binlog日志写到relay
log（中继日志）文件中； (3)主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog； (4)SQL 线程，会读取relay
log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
10.Apache服务的常用工作模式及对应的特点
worker模式： (1)线程模式 (2)占用资源少 (3)稳定性略差 (4) 并发大 prefork模式： (1)进程模式 (2)占用资源多 (3)稳定
(4)并发一般

热门工具换一换