検証中のサーバが突然ビ──────────

と悲鳴をあげてフロアにいた全員がびくっとなった。
多分HDDかRAIDの故障。
MySQLで6億件レストア中でどう考えてもそれが原因?
ソフトウェア->ハードウェアに故障が伝染?そんなことあるのなぁさっぱりわからない。
エンジニアがバイオスを立ち上げてみたり、何度も何度も再起動するうちに普通に起動した。

そしてMySQLを起動。

。。。。。。。。。。

起動せず。
tail -fでMySQLエラーログをみてみる。リカバリをなんかやっているようだ。さらに知らない間にmysqld_safeプロセスが起動している。
[code lang=”SQL” highlight=”18-20,30″]
130719 19:43:13 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 147898558920
130719 19:43:13 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 147903801344
InnoDB: Doing recovery: scanned up to log sequence number 147909044224
InnoDB: Doing recovery: scanned up to log sequence number 147914287104
InnoDB: Doing recovery: scanned up to log sequence number 147919529984
InnoDB: Doing recovery: scanned up to log sequence number 147924772864
InnoDB: Doing recovery: scanned up to log sequence number 147930015744
.
.
.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong…
stack_bottom = 0 thread_stack 0x30000
/usr/libexec/mysqld(my_print_stacktrace+0x2e)[0x787fbe]
/usr/libexec/mysqld(handle_fatal_signal+0x493)[0x671673]
/lib64/libpthread.so.0(+0xf500)[0x7fc9e091b500]
/lib64/libc.so.6(gsignal+0x35)[0x7fc9dedb98a5]
/lib64/libc.so.6(abort+0x175)[0x7fc9dedbb085]
/usr/libexec/mysqld[0x80fc99]
/lib64/libpthread.so.0(+0x7851)[0x7fc9e0913851]
/lib64/libc.so.6(clone+0x6d)[0x7fc9dee6f90d]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
[/code]
ハイライトされている文章がでてきたらもうクラッシュ確定。