免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
12下一页
最近访问板块 发新帖
查看: 2681 | 回复: 10

紧急求助 [复制链接]

论坛徽章:
0
发表于 2012-05-08 18:07 |显示全部楼层
现在有一台数据库宕机了,现在无法启动,通过‘service mysqld start’ ,启动日志如下:
20508 17:33:18 mysqld_safe Starting mysqld daemon with databases from /Databases/mysql/
120508 17:33:18 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
120508 17:33:18 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
120508 17:33:18 [Warning] '--log-long-format' is deprecated and will be removed in a future release. Please use '--log-short-format' instead.
120508 17:33:18 [Warning] --myisam_max_extra_sort_file_size is deprecated and does nothing in this version.  It will be removed in a future release.
120508 17:33:18 [Note] Plugin 'FEDERATED' is disabled.
120508 17:33:18  InnoDB: Initializing buffer pool, size = 9.0G
120508 17:33:18  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 145 4107726386
120508 17:33:19  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 145 4112969216
InnoDB: Doing recovery: scanned up to log sequence number 145 4118212096
InnoDB: Doing recovery: scanned up to log sequence number 145 4123454976
InnoDB: Doing recovery: scanned up to log sequence number 145 4128697856
InnoDB: Doing recovery: scanned up to log sequence number 145 4133940736
InnoDB: Doing recovery: scanned up to log sequence number 145 4139183616
InnoDB: Doing recovery: scanned up to log sequence number 145 4144426496
InnoDB: Doing recovery: scanned up to log sequence number 145 4149669376
InnoDB: Doing recovery: scanned up to log sequence number 145 4154912256
InnoDB: Doing recovery: scanned up to log sequence number 145 4160155136
InnoDB: Doing recovery: scanned up to log sequence number 145 4165398016
InnoDB: Doing recovery: scanned up to log sequence number 145 4170640896
InnoDB: Doing recovery: scanned up to log sequence number 145 4175883776
InnoDB: Doing recovery: scanned up to log sequence number 145 4181126656
InnoDB: Doing recovery: scanned up to log sequence number 145 4186369536
InnoDB: Doing recovery: scanned up to log sequence number 145 4191612416
InnoDB: Doing recovery: scanned up to log sequence number 145 4196855296
InnoDB: Doing recovery: scanned up to log sequence number 145 4202098176
InnoDB: Doing recovery: scanned up to log sequence number 145 4207341056
InnoDB: Doing recovery: scanned up to log sequence number 145 4212583936
InnoDB: Doing recovery: scanned up to log sequence number 145 4217826816
InnoDB: Doing recovery: scanned up to log sequence number 145 4223069696
InnoDB: Doing recovery: scanned up to log sequence number 145 4228312576
InnoDB: Doing recovery: scanned up to log sequence number 145 4233555456
InnoDB: Doing recovery: scanned up to log sequence number 145 4238798336
InnoDB: Doing recovery: scanned up to log sequence number 145 4238798336
InnoDB: Doing recovery: scanned up to log sequence number 145 4244041216
InnoDB: Doing recovery: scanned up to log sequence number 145 4249284096
InnoDB: Doing recovery: scanned up to log sequence number 145 4254526976
InnoDB: Doing recovery: scanned up to log sequence number 145 4259769856
InnoDB: Doing recovery: scanned up to log sequence number 145 4265012736
InnoDB: Doing recovery: scanned up to log sequence number 145 4270255616
InnoDB: Doing recovery: scanned up to log sequence number 145 4275498496
InnoDB: Doing recovery: scanned up to log sequence number 145 4280741376
InnoDB: Doing recovery: scanned up to log sequence number 145 4285984256
InnoDB: Doing recovery: scanned up to log sequence number 145 4291227136
InnoDB: Doing recovery: scanned up to log sequence number 146 1502720
InnoDB: Doing recovery: scanned up to log sequence number 146 6745600
InnoDB: Doing recovery: scanned up to log sequence number 146 11988480
InnoDB: Doing recovery: scanned up to log sequence number 146 17231360
InnoDB: Doing recovery: scanned up to log sequence number 146 22474240
InnoDB: Doing recovery: scanned up to log sequence number 146 27717120
InnoDB: Doing recovery: scanned up to log sequence number 146 32960000
InnoDB: Doing recovery: scanned up to log sequence number 146 38202880
InnoDB: Doing recovery: scanned up to log sequence number 146 43445760
InnoDB: Doing recovery: scanned up to log sequence number 146 48684557
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 167436 row operations to undo
InnoDB: Trx id counter is 0 1655435264
120508 17:33:42  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

到了这里,启动失败:
[root@Hawx-02 mysql]# /etc/init.d/mysqld start
Starting MySQL................................................................................................................................................................................................................................................................................[failed].............

请教大家了,我该怎么做???

论坛徽章:
9
每日论坛发贴之星
日期:2016-01-04 06:20:00数据库技术版块每日发帖之星
日期:2016-01-04 06:20:00每日论坛发贴之星
日期:2016-01-04 06:20:00数据库技术版块每日发帖之星
日期:2016-01-04 06:20:00IT运维版块每日发帖之星
日期:2016-01-04 06:20:00IT运维版块每日发帖之星
日期:2016-01-04 06:20:00综合交流区版块每日发帖之星
日期:2016-01-04 06:20:00综合交流区版块每日发帖之星
日期:2016-01-04 06:20:00数据库技术版块每周发帖之星
日期:2016-03-07 16:30:25
发表于 2012-05-08 18:15 |显示全部楼层
回复 1# oulinhl

用service 启动脚本的话,默认有900s的超时。
而你的innodb由于非正常shutdown,需要recovery数据,超过了900s。

解决办法:
vi /etc/init.d/mysqld

找到这一行: service_startup_timeout=900
修改成一个大点的时间就可以了
   

论坛徽章:
0
发表于 2012-05-08 18:24 |显示全部楼层
回复 2# cenalulu

好的,非常感谢,我去试试!

   

论坛徽章:
0
发表于 2012-05-08 18:26 |显示全部楼层
回复 2# cenalulu


另外‘InnoDB: Progress in percents: 0 1 2 3 4 5’这里面的数据是进度,是不是表示已经恢复了%5


   

论坛徽章:
0
发表于 2012-05-08 19:50 |显示全部楼层
回复 4# oulinhl


    是的!

论坛徽章:
0
发表于 2012-05-08 21:03 |显示全部楼层
回复 2# cenalulu


    又扫盲了~~

论坛徽章:
0
发表于 2012-05-09 09:01 |显示全部楼层
学习了。。。

论坛徽章:
0
发表于 2012-05-09 09:16 |显示全部楼层
回复 2# cenalulu

按照你所说我去执行了,结果成功了,可以正常启起来,但是当我再执行stop时,速度会非常慢,请问是什么原因呢??


   

论坛徽章:
0
发表于 2012-05-09 09:38 |显示全部楼层
stop之前,mysql会把一些脏页刷到磁盘,需要的时间根据脏页数量多小而定。

论坛徽章:
0
发表于 2012-05-09 09:58 |显示全部楼层
这个很不错
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP