Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a MySQL server that has been running flawlessly for 230 days. Then earlier today, MySQL just seemed to restart itself out of nowhere.

The mysql error log has only this:

131126 17:04:40 InnoDB: The InnoDB memory heap is disabled
131126 17:04:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins
131126 17:04:40 InnoDB: Compressed tables use zlib 1.2.3.4
131126 17:04:40 InnoDB: Initializing buffer pool, size = 500.0M
131126 17:04:40 InnoDB: Completed initialization of buffer pool
131126 17:04:40 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 1094802773598
131126 17:04:40  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 1094808016384
...
InnoDB: 1 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 3 row operations to undo
InnoDB: Trx id counter is 135CA8E00
131126 17:10:58  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 44 45 4$
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 709588816, file name /var/log/mysql/mysql-bin.000808
InnoDB: Starting in background the rollback of uncommitted transactions
131126 17:11:25  InnoDB: Rolling back trx with id 135CA8B20, 3 rows to undo
131126 17:11:25  InnoDB: Waiting for the background threads to start
InnoDB: Rolling back of trx id 135CA8B20 completed
131126 17:11:25  InnoDB: Rollback of non-prepared transactions completed
131126 17:11:26 InnoDB: 1.1.8 started; log sequence number 1095025187164
131126 17:11:26 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
131126 17:11:40 [Note] Starting crash recovery...
131126 17:11:40 [Note] Crash recovery finished.
131126 17:11:42 [Note] Event Scheduler: Loaded 0 events
131126 17:11:42 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.29-0ubuntu0.12.04.2-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

The server wasn't under any kind of stress that we can see. We use ServerDensity and have been looking through history and can't find anything out of the ordinary.

What might cause MySQL to restart itself like this? What log files should I check to get a clue?

Edit

  • I couldn't find anything relevant in dmesg or syslog
share|improve this question
2  
Bad memory or possible disk issues. –  Frank Thornton Nov 26 '13 at 18:15
1  
Looks like MySQL crashed. You might be able to find something using dmesg –  lsmooth Nov 26 '13 at 18:17
1  
@Zoredache the point I'm trying to determine is if this is just a one-off bug or if it's a sign of something bad to come. "It's probably just a bug" isn't very comforting. –  Christopher Nadeau Nov 26 '13 at 18:26
2  
You might want to check syslog for that time window and see if you find something relevant there –  APZ Nov 26 '13 at 18:30
1  
Since there is nothing in the logs accept in your mysqld's error log, this sure looks like a bug. Disk issues would be apparent in dmesg and if you had broken memory, you would most likely have other issues than just mysql crashing. I'd mysqlcheck all databases and tables if you haven't done so and move on. If you really want to get to the bottom of this you could enable core dumps in case mysql crashes again and check those out. –  lsmooth Nov 27 '13 at 23:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.