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

I'm having my mysql server crashing the last 3-4 days. The crash log TODAY shows the following:

2013-09-20 09:20:55 1244  InnoDB: Assertion failure in thread 4676 in file btr0cur.cc line 4766
InnoDB: Failing assertion: space_id == page_get_space_id(page)
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Thread 3792 stopped in file ut0ut.cc line 81
InnoDB: Thread 4088 stopped in file os0sync.cc line 475
InnoDB: Thread 4992 stopped in file os0sync.cc line 783
InnoDB: Thread 2896 stopped in file ut0ut.cc line 81
InnoDB: Thread 3724 stopped in file ut0lst.h line 93
InnoDB: Thread 4580 stopped in file ut0lst.h line 93
InnoDB: Thread 3164 stopped in file os0sync.cc line 475
InnoDB: Thread 3364 stopped in file os0sync.cc line 475
InnoDB: Thread 444 stopped in file os0sync.cc line 475
InnoDB: Thread 3964 stopped in file ut0lst.h line 93
InnoDB: Thread 4048 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 3780 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 3480 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 4568 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 4060 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 1380 stopped in file ha_innodb.cc line 2316
2013-09-20 10:34:19 3700 [Note] Plugin 'FEDERATED' is disabled.
2013-09-20 10:34:19 3700 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2013-09-20 10:34:19 12dc InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-09-20 10:34:19 3700 [Note] InnoDB: The InnoDB memory heap is disabled
2013-09-20 10:34:19 3700 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-09-20 10:34:19 3700 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-09-20 10:34:19 3700 [Note] InnoDB: CPU does not support crc32 instructions
2013-09-20 10:34:19 3700 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2013-09-20 10:34:19 3700 [Note] InnoDB: Completed initialization of buffer pool
2013-09-20 10:34:19 3700 [Note] InnoDB: Highest supported file format is Barracuda.
2013-09-20 10:34:20 3700 [Note] InnoDB: Log scan progressed past the checkpoint lsn 4361137083
2013-09-20 10:34:20 3700 [Note] InnoDB: Database was not shutdown normally!
2013-09-20 10:34:20 3700 [Note] InnoDB: Starting crash recovery.
2013-09-20 10:34:20 3700 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-09-20 10:34:20 3700 [Note] InnoDB: Restoring possible half-written data pages 
2013-09-20 10:34:20 3700 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 4361156792
2013-09-20 10:34:21 3700 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
2013-09-20 10:34:21 3700 [Warning] Invalid (old?) table or database name '#sql-564_1361f'
2013-09-20 10:34:21 3700 [Warning] Invalid (old?) table or database name '#sql-c28_63'
2013-09-20 10:34:21 3700 [Note] InnoDB: 128 rollback segment(s) are active.
2013-09-20 10:34:21 3700 [Note] InnoDB: Waiting for purge to start
2013-09-20 10:34:22 3700 [Note] InnoDB: 1.2.10 started; log sequence number 4361156792
2013-09-20 10:34:22 3700 [Note] Server hostname (bind-address): '*'; port: 3306
2013-09-20 10:34:22 3700 [Note] IPv6 is available.
2013-09-20 10:34:22 3700 [Note]   - '::' resolves to '::';
2013-09-20 10:34:22 3700 [Note] Server socket created on IP: '::'.
2013-09-20 10:34:22 3700 [Note] Event Scheduler: Loaded 0 events
2013-09-20 10:34:22 3700 [Note] C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqld: ready for connections.
Version: '5.6.10-log'  socket: ''  port: 3306  MySQL Community Server (GPL)

while on the previous days i have had more crashes which look like this:

Version: '5.6.10-log'  socket: ''  port: 3306  MySQL Community Server (GPL)
2013-09-18 09:05:47 1096 [Warning] Host name 'unassigned.psychz.net' could not be resolved: No such host is known. 
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 80044.
InnoDB: You may have to recover from a backup.
2013-09-18 10:03:57 7dc InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 00000000000000000...
InnoDB: End of page dump
2013-09-18 10:03:57 7dc InnoDB: uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 71317206, innodb 2798848053, none 3735928559, stored checksum in field2 4275117012, calculated checksums for field2: crc32 71317206, innodb 1371122432, none 3735928559, page LSN 0 0, low 4 bytes of LSN at page end 1766966405, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 80044.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 80044.
InnoDB: You may have to recover from a backup.
2013-09-18 10:03:57 7dc InnoDB: Page dump in ascii and hex (16384 bytes):
 len 16384; hex 000
InnoDB: End of page dump
2013-09-18 10:03:58 7dc InnoDB: uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 71317206, innodb 2798848053, none 3735928559, stored checksum in field2 4275117012, calculated checksums for field2: crc32 71317206, innodb 1371122432, none 3735928559, page LSN 0 0, low 4 bytes of LSN at page end 1766966405, page number (if stored to page already) 0, space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be a freshly allocated page
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 80044.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
2013-09-18 10:03:58 7dc  InnoDB: Assertion failure in thread 2012 in file buf0buf.cc line 4057
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
InnoDB: Thread 1528 stopped in file os0sync.cc line 475
InnoDB: Thread 1532 stopped in file os0sync.cc line 783
InnoDB: Thread 1548 stopped in file ut0ut.cc line 81
InnoDB: Thread 1540 stopped in file ut0ut.cc line 81
InnoDB: Thread 1556 stopped in file os0sync.cc line 475
InnoDB: Thread 1536 stopped in file os0sync.cc line 475
InnoDB: Thread 1560 stopped in file os0sync.cc line 475
InnoDB: Thread 2380 stopped in file ut0lst.h line 93
InnoDB: Thread 544 stopped in file ut0lst.h line 93
InnoDB: Thread 2996 stopped in file ut0lst.h line 93
InnoDB: Thread 632 stopped in file ut0lst.h line 93
InnoDB: Thread 2884 stopped in file ha_innodb.cc line 4007
InnoDB: Thread 2248 stopped in file ha_innodb.cc line 4007
2013-09-18 10:19:39 1380 [Note] Plugin 'FEDERATED' is disabled.
2013-09-18 10:19:39 1380 [Warning] option 'innodb-autoextend-increment': unsigned value 67108864 adjusted to 1000
2013-09-18 10:19:39 b4c InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
2013-09-18 10:19:39 1380 [Note] InnoDB: The InnoDB memory heap is disabled
2013-09-18 10:19:39 1380 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2013-09-18 10:19:39 1380 [Note] InnoDB: Compressed tables use zlib 1.2.3
2013-09-18 10:19:39 1380 [Note] InnoDB: CPU does not support crc32 instructions
2013-09-18 10:19:39 1380 [Note] InnoDB: Initializing buffer pool, size = 2.0G
2013-09-18 10:19:39 1380 [Note] InnoDB: Completed initialization of buffer pool
2013-09-18 10:19:40 1380 [Note] InnoDB: Highest supported file format is Barracuda.
2013-09-18 10:19:40 1380 [Note] InnoDB: Log scan progressed past the checkpoint lsn 1770390822
2013-09-18 10:19:40 1380 [Note] InnoDB: Database was not shutdown normally!
2013-09-18 10:19:40 1380 [Note] InnoDB: Starting crash recovery.
2013-09-18 10:19:40 1380 [Note] InnoDB: Reading tablespace information from the .ibd files...
2013-09-18 10:19:40 1380 [Note] InnoDB: Restoring possible half-written data pages 
2013-09-18 10:19:40 1380 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 1770395124
2013-09-18 10:19:41 1380 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
2013-09-18 10:19:42 1380 [Note] InnoDB: 128 rollback segment(s) are active.
2013-09-18 10:19:42 1380 [Note] InnoDB: Waiting for purge to start
2013-09-18 10:19:42 1380 [Note] InnoDB: 1.2.10 started; log sequence number 1770395124
2013-09-18 10:19:42 1380 [Note] Server hostname (bind-address): '*'; port: 3306
2013-09-18 10:19:42 1380 [Note] IPv6 is available.
2013-09-18 10:19:42 1380 [Note]   - '::' resolves to '::';
2013-09-18 10:19:42 1380 [Note] Server socket created on IP: '::'.
2013-09-18 10:19:43 1380 [Note] Event Scheduler: Loaded 0 events
2013-09-18 10:19:43 1380 [Note] C:\Program Files\MySQL\MySQL Server 5.6\bin\mysqld: ready for connections.
Version: '5.6.10-log'  socket: ''  port: 3306  MySQL Community Server (GPL)

i belive some of the errors were due to a corrupted table which i truncated.

I was wondering if there are some more reasons for the assertion failures and what can I do to avoid such things.

Also those hostnames "unassigned.psychz.net" which are unresolved, why exactly do they appear in the log? what does it mean ? only 1 particular IP can connect to the mysql server ( firewall ) so i don't understand why that message is there.

Thank you in advance any input.

share|improve this question

1 Answer 1

I am looking into mysql connection attempts from unassigned.psychz.net

It is beginning to look as if these are hacking attempts

share|improve this answer
    
We had a similar situation. Any hints on what you did afterwards? –  Remy Dec 11 '13 at 8:37

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.