# random restarts

**URL:** https://forums.percona.com/t/random-restarts/4681
**Category:** Percona Server for MySQL 5.6
**Created:** [January 25, 2016, 7:09am UTC](https://forums.percona.com/t/random-restarts/4681 "2016-01-25T07:09:40Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![stormdust](https://avatars.discourse-cdn.com/v4/letter/s/6f9a4e/32.png) [@stormdust](https://forums.percona.com/u/stormdust)
#### Post date: [January 25, 2016, 7:09am UTC](https://forums.percona.com/t/random-restarts/4681/1 "2016-01-25T07:09:40Z")

</div>

Hi guys, i keep getting this random restarts with the error below and can´t figure it out wich table is getting this nor nothing.

Im using 5.6.28 version of percona and currently im using innodb checksum algoritm.  
this seems to be close to this reported bug but cant figure it out.  
[url][MySQL Bugs: #73689: Zero can be a valid InnoDB checksum, but validation will fail later](http://bugs.mysql.com/bug.php?id=73689%5B/url%5D)

My dumps run smoothly every night with mysqldump and with xtrabackup, cant see any corruption anyware. Already run optimize to all tables and restart it with a full dump.

InnoDB: Page directory corruption: infimum not pointed to  
2016-01-25 11:28:07 7f02715d9700 InnoDB: Page dump in ascii and hex (16384 bytes):  
len 16384; hex 00000000 bunch of 0  
InnoDB: End of page dump  
2016-01-25 11:28:07 7f02715d9700 InnoDB: uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 536728786, innodb 1575996416, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 536728786, innodb 1371122432, none 3735928559, page LSN 0 0, low 4 bytes of LSN at page end 0, 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: Page directory corruption: supremum not pointed to  
2016-01-25 11:28:07 7f02715d9700 InnoDB: Page dump in ascii and hex (16384 bytes):  
len 16384; hex 0000000000 bunch of 0  
InnoDB: End of page dump  
2016-01-25 11:28:07 7f02715d9700 InnoDB: uncompressed page, stored checksum in field1 0, calculated checksums for field1: crc32 536728786, innodb 1575996416, none 3735928559, stored checksum in field2 0, calculated checksums for field2: crc32 536728786, innodb 1371122432, none 3735928559, page LSN 0 0, low 4 bytes of LSN at page end 0, 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  
11:28:07 UTC - mysqld got signal 11 ;

key\_buffer\_size=33554432  
read\_buffer\_size=2097152  
max\_used\_connections=46  
max\_threads=102  
thread\_count=18  
connection\_count=17  
It is possible that mysqld could use up to  
key\_buffer\_size + (read\_buffer\_size + sort\_buffer\_size)\*max\_threads = 1914231 K bytes of memory  
Hope that’s ok; if not, decrease some variables in the equation.

i try to change to CRC32 algorithm and crashs randomly at  
2016-01-24 00:57:50 7f5c99285700 InnoDB: Assertion failure in thread 140035683276544 in file btr0pcur.cc line 445  
InnoDB: Failing assertion: page\_is\_comp(next\_page) == page\_is\_comp(page)  
InnoDB: We intentionally generate a memory trap.  
InnoDB: Submit a detailed bug report to [http://bugs.mysql.com](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: [url][http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html[/url]](http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html%5B/url%5D)  
InnoDB: about forcing recovery.  
00:57:50 UTC - mysqld got signal 6 ;

im starting to despair with innodb tables.