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)并发一般