网站宕机 服务器宕机 数据库宕机 宕机怎么办

最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行 *** 作，避免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。

1.检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。

2.对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。

在my.cnf中[mysqld]下加上以下配置，采用强制恢复机制，看是否能够启动

[mysqld]

innodb_force_recovery=1

如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：

当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。

innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B树和其它数据库结构的更多破坏。

innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)

即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。

innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)

阻止主线程运行，如果崩溃可能在净化 *** 作过程中发生，这将阻止它。

innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)

恢复后不运行事务回滚。

innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)

也阻止插入缓冲合并 *** 作。如果你可能会导致一个崩溃。最好不要做这些 *** 作，不要计算表统计表。

innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)

启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的。

innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)

不要在恢复连接中做日志前滚。

数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery被设置为大于0的值时，InnoDB阻止用户执行INSERT, UPDATE或DELETE *** 作.

即使强制恢复被使用，你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程，然后设置innodb_force_recovery为3，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。

关于上面进行逻辑备份也可能会遇到问题，可能会备份失败，如果出错，建议先按库一个一个的备份，到哪个库出错后，再按照当前库的表一个一个备份，表出错根据表中主键一点一点备份，最终将大部分数据导出。如果你的数据不重要，可以容忍丢失，那么可以当我说的都是废话了。

3.如果还是不可以启动，那么恭喜你，你遇到挑战了。

查看错误日志，看没有提示因为某个表的原因而导致启动不了，可以先把损坏的表的ibd文件先从数据目录mv走，再试着启动，在数据已经恢复后，我把当时错误的文件拿到本地，做了测试，把几个报错的ibd文件mv走后，数据库就可以正常启动了，但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢，曾想过用在线表空间传输，但是.cfg文件却没有，这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复，关于这个工具的介绍与 *** 作，网上一大堆，我就不详细说明了。

创建数据库

选择开始菜单中→程序→【Management SQL Server 2008】→【SQL Server Management Studio】命令，打开【SQL Server Management Studio】窗口，并使用Windows或 SQL Server身份验证建立连接。

在【对象资源管理器】窗口中展开服务器，然后选择【数据库】节点

右键单击【数据库】节点，从d出来的快捷菜单中选择【新建数据库】命令。

执行上述 *** 作后，会d出【新建数据库】对话框。在对话框、左侧有3个选项，分别是【常规】、【选项】和【文件组】。完成这三个选项中的设置会后，就完成了数据库的创建工作，

在【数据库名称】文本框中输入要新建数据库的名称。例如，这里以“新建的数据库”。

在【所有者】文本框中输入新建数据库的所有者，如sa。根据数据库的使用情况，选择启用或者禁用【使用全文索引】复选框。

在【数据库文件】列表中包括两行，一行是数据库文件，而另一行是日记文件。通过单击下面的【添加】、【删除】按钮添加或删除数据库文件。

切换到【选项页】、在这里可以设置数据库的排序规则、恢复模式、兼容级别和其他属性。

切换到【文件组】页，在这里可以添加或删除文件组。

完成以上 *** 作后，单击【确定】按钮关闭【新建数据库】对话框。至此“新建的数据”数据库创建成功。新建的数据库可以再【对象资源管理器】窗口看到。

原因很多，内部原因外部原因都有可能。

外部原因：比如服务器宕机，系统错误，温度过高宕机（比如机房空调坏了），临时断电，内存错误等等这些都有可能，电压不足等等。

内部原因：比较常见的有undo文件损坏，数据文件错误（遇到过一次，最后用补0的方法扩大了数据文件才好，不过现在用asm存储，这个应该不怎么可能了），时间调整错误（向后调，改动时间过长，比如00:00改为01:00，那么就两个情况都占，未必一定宕机，不过可能性很大），核心进程错误（这个比较少见，不过真的有，有时是有人误杀了），程序错误导致（见过一个因为某程序错误，导致锁表，而后锁表导致某进程一直占用内存，后来的进程根本进不了该表，然后越滚越大最后宕机，还是后来查出来的，相当于蝴蝶扇翅膀变成飓风，所以有错误要及时发现才行），存储错误，io争用（持续时间长）等等。

这么说吧，很多的ora错误都可能引起宕机（并不是全部ora错误都会引起宕机），真要说的话要很长时间，如果想不宕机那么就要有监测检查制度，早发现早解决，也就不会有什么问题了。

---