服务器宕机怎么办？

解决方法：

对于服务器频繁出现宕机情况就要注意了检查服务器是否存在负载量过大，服务器散热存在问题等等情况。再针对这样的情况一项一项来解决，这样才能保证服务器尽可能长时间正常运行。

对于一般服务器宕机，我们可以采用重启服务器的方式来解决。正常重启服务器可以清除内存碎片，重新优化应用软件，中断无用的端口，缓解CPU压力，加快服务器运行速度等等。

对于服务器租用用户来说，服务器宕机是非常值得重视的问题，如果租用的服务器经常出现宕机情况的话，一定要及时通知服务商，让服务器查明具体情况，问题过于严重甚至可以要求跟换服务器或者更换服务器供应商。

服务器简介：

服务器是一种高性能计算机，作为网络的节点，存储、处理网络上80%的数据、信息，因此也被称为网络的灵魂。

服务器指一个管理资源并为用户提供服务的计算机软件，通常分为文件服务器、数据库服务器和应用程序服务器。运行以上软件的计算机或计算机系统也被称为服务器。

相对于普通PC来说，服务器在稳定性、安全性、性能等方面都要求更高，因此CPU、芯片组、内存、磁盘系统、网络等硬件和普通计算机有所不同，在质量与处理器数据性能上更出色。

“宕机”的拼音读法为：dàng ji。宕机属于计算机的术语，指电脑或者服务器不能正常工作。口语中我们简单地把停掉机器叫做down机，转换为汉字是“宕机”，不过多数人都叫做“当机”/“死机”，虽然不规范但却流行。

down就是up的反义，就是计算机不能正常工作了，包括一切原因而导致出现的死机。

通俗一点来说，宕机我们完全可以理解为服务器或者电脑出现故障，导致了无法正常工作。相信我们在浏览一些不知名的网站，有的时候出现无法访问的问题，那么这种现象都可以叫服务器宕机。

B站回应崩了：部分服务器机房发生故障

周二 ( 7 月 13 日 ) 晚间有消息称，B 站出现服务器宕机事故。消息传来之后，哔哩哔哩股价短线走低，涨幅收窄至 3%。

稍早前，有多位网友反映，B 站网页端和移动端均出现加载失败现象，有网友一开始还以为是手机或者信号的问题。

针对昨晚哔哩哔哩全平台崩溃一事官方现回应称，B 站的部分服务器机房发生故障，造成无法访问。技术团队随即进行了问题排查和修复，现在服务已经陆续恢复正常。

除此之外，官方未对任何服务器方面或技术方面的细节进行讲解。

最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行 *** 作，避免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。
1检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在mycnf中[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工具进行数据恢复，关于这个工具的介绍与 *** 作，网上一大堆，我就不详细说明了。

原因很多，内部原因外部原因都有可能。
外部原因：比如服务器宕机，系统错误，温度过高宕机（比如机房空调坏了），临时断电，内存错误等等这些都有可能，电压不足等等。
内部原因：比较常见的有undo文件损坏，数据文件错误（遇到过一次，最后用补0的方法扩大了数据文件才好，不过现在用asm存储，这个应该不怎么可能了），时间调整错误（向后调，改动时间过长，比如00:00改为01:00，那么就两个情况都占，未必一定宕机，不过可能性很大），核心进程错误（这个比较少见，不过真的有，有时是有人误杀了），程序错误导致（见过一个因为某程序错误，导致锁表，而后锁表导致某进程一直占用内存，后来的进程根本进不了该表，然后越滚越大最后宕机，还是后来查出来的，相当于蝴蝶扇翅膀变成飓风，所以有错误要及时发现才行），存储错误，io争用（持续时间长）等等。
这么说吧，很多的ora错误都可能引起宕机（并不是全部ora错误都会引起宕机），真要说的话要很长时间，如果想不宕机那么就要有监测检查制度，早发现早解决，也就不会有什么问题了。

位于美国加州中部的萨克拉门托（Sacramento）有三个身份：1850年代的淘金人口集散地、如今的加州州府和Twitter的数据中心。 7月26日上午8点20分，这个数据中心停止了工作。当你输入Twitter网址时，你会看到页面显示“Twitter目前因某些原因宕机，预计稍后恢复”的提示。这种状况持续了两个多小时，直到10点25分，Twitter才恢复正常。部分用户怀疑这和7月27日开幕的伦敦奥运会有关。
尽管Twitter的运营团队通过后台的流量图看到了即将到来的奥运会热潮对各项指标的拉升—这种可预期的、能带来大流量的事件，Twitter一般都会提前做准备，然而意外还是发生了。
在Twitter的预案里，如果这里发生了洪水、地震或者其他任何有可能导致服务器停止工作的问题，距离萨克拉门托965公里的另一个数据中心就会开始工作，它位于托管服务商Raging Wire旗下的一处建筑内，当然，情况也可能相反：Raging Wire这边出了问题，萨克拉门托开始工作。
无论哪一种情况，Twitter希望保证的是用户的不间断使用体验，即便是远在大洋彼岸的用户，也可以正常地把自己的消息Tweet出去，而不会感受到服务中断。
对于互联网公司而言，在线就是生命。Facebook早期迅速积累用户并不是由于它来自哈佛大学的好名声，而是它几乎从不宕机。这与当时强劲的竞争对手MySpace形成了鲜明对 照。
但在7月26日这一天，Twitter两个数据中心同时发生故障，全球用户的Twitter服务中止。Twitter提供的解释是由于“基础设施元件中的级联式漏洞”，但没有公布更详细的信息。在Twitter的成长史上几乎每年都会有多次重大宕机事故，宕机时网站就会显示出一幅有趣的：几只小鸟用线艰难地拉起一头搁浅的鲸鱼。
这是Twitter在两个月之内的第二次重大宕机故障。此前一次是6月21日，Twitter停止服务将近两个多小时。
Twitter负责工程技术的副总裁拉瓦德（Mazen Rawashdeh）事后解释说，Twitter在数据中心有两套能互相备份的数据系统同时出现了故障，这是基础设施上的“巧合事件”。通常情况下，如果一个系统出现故障，那么另一个将被紧急启用。而两套系统同时出现问题则比较少见，为避免类似故障重演，Twitter称计划对基础设施大幅投资。
数据中心问题一直困扰着Twitter。截至3月，Twitter已有14亿活跃用户，每天会发出34亿条Tweet。随着用户量和信息读写量的增长，Twitter迫切需要一个能自我完全掌控的数据中心。
Twitter早期租用第三方的数据服务，之后计划转向租用位于犹他州盐湖城的定制化数据中心，然而在去年该数据中心却出现了漏雨、电力不足等问题，于是Twitter不得不改变其计划，另谋他处。
在同一天，悲催的不仅仅是Twitter。谷歌的即时通讯服务Gtalk也在早上6点40分发生故障，并迟迟没有被修复。有用户报告，微软旗下面对企业客户的云服务工具Windows Azure在西欧地区也发生了宕机问题。
在宕机这段时间内，Gtalk用户发现虽然能够登录，但无法像以往一样正常发送信息以及进行语音、视频聊天。他们持续接到谷歌通过网页更新的问题修复状态通知，时间单位大约为半小时，而这一状态持续了近5个小时，算是谷歌史上罕见的长时间故障。习惯线上沟通的用户们不得不转向其他工具，有人说，接连两起宕机事件让他们有一种“全球停电”的感觉。
谷歌的数据中心分布全球且多达20多个，目前无法得知是哪一块数据中心发生了故障以致Gtalk瘫痪，谷歌至今也未解释具体原 因。
世界正在变成一个由数据洪流组成的存在，而整个世界也因几个重要信息节点而相互连接在一起。但即使是像谷歌这样著名的互联网公司也无法保证自己所有的服务全年都不出问题。
据谷歌称，其最受欢迎的服务Gmail电子邮件服务2010年全年宕机时间为7分钟，这已经是业内最短时间。根据Radicati Group的数据，电子邮件系统平均宕机时间为每月38小时。对比起来，Gmail可谓优秀。
一般造成系统不稳定甚至宕机的原因是多样的，开发安卓手机管理工具豌豆荚的豌豆实验室技术总监高磊对《第一财经周刊》介绍，在用户使用网站服务时，从用户输入信息，网络传送信息给网站服务器，网站服务器按照程序对用户要求进行处理，将结果返还用户，整个过程中其中一个环节出现问题就会导致网站的服务受到影响，甚至发生宕机而不可用。
引发问题的潜在因素多种多样，包括网站自身程序、服务器的 *** 作系统、硬件设备、机房与网络运营商等基础设施。
如果网站自身程序有Bug，可能会导致使用变慢，或部分功能失效；服务器的 *** 作系统也会出现漏洞，比如装有Linux部分版本的服务器就在本月因为闰秒问题而宕机；服务器硬件本身损坏，比如硬盘或内存都存在一定物理故障的机率。
而在基础设施上，机房停电或进水、遭到雷击等也会造成设备停止运行。最基础的问题是过热，因此大型数据中心旁边一般都有冷却装置。
6月底，美国一场风暴袭击了弗吉尼亚北部，大面积电力供应中断。而恰巧亚马逊在这里安置了US-East-1数据中心，因为停电，整个数据中心瘫痪。
亚马逊是业界领先的云服务提供商，其提供给网站以数据服务的云服务Amazon Web Services也因此一度中断服务。之后连锁反应便产生，使用其服务的Instagram、Pinterest、Quora、Netflix等知名网站也停止了服务，进而影响到各自的生态系统。
为避免风险，一些网络公司选择不把鸡蛋放在一个篮子里，设置多个数据中心，或者在使用云服务时同时选择多家供应商，当然，这也会增加成本。
据新浪微博技术总监杨卫华对《第一财经周刊》介绍，是否能稳定登录，响应的速度怎样，都会对用户的体验造成直接影响。新浪微博采用了分布式的架构，这意味着它没有把所有的服务器都放在新浪所在的北京，而是在国内多个主要城市都设置了数据中心，在突发事件发生后的流量处理和响应速度等各方面来保证用户体验。
你在宕机时体验到多少焦虑，稳定对于互联网公司就有多重要。
当越来越多的人被接入同一个网络─比如被称为“世界的脉搏”的Twitter，数据中心瘫痪的风险等级也相应增加。这些数据就存储在像加州萨克拉门托的大房子里，一旦宕机，空白也从这里开始。

宕机一般情况下指的就是计算机主机出现意外故障而死机；
其次就是一些服务器故障，包括服务器主机，数据库死锁或者DNS故障都可以称为宕机，一切服务器的某些服务挂掉了。
对于普通电脑出现故障，很少有人会宕机，但由于服务器都是365天不关机不间断工作的，所以对于服务器出现宕机是十分常见的事情。
可以说宕机只是服务器的其中一种状态，这个词主要在运维和开发人员中使用比较频繁，因为服务器宕机会给用户的正常使用带来影响，影响企业网站的正常使用和宣传。

可以简单的理解为死机服务器是硬件设备而且是全年二十四小时不间断运行的通常负载量也较大所以时间一长就容易出现宕机的情况只要不是太频繁就是完全正常的一般常用服务器的人都知道每隔一段时间定期手动重启下机器对机器的性能有很大帮助而且可以避免宕机的情况毕竟服务器也是硬件长期运行中间也应该有个喘气的过程

---