cPanelCon 2015: InnoDB Alchemy

InnoDB AlchemyRyan Robson

#cpgethightech #cpanelconf

A Quick Refresher• InnoDB is the default engine as of MySQL

5.5.5+• Non-portable file structure• Crash recovery functionality using redo logs• Uses the data dictionary to maintain table

definitions, structures, and indexes.• Physical file structure made up of tablespaces,

pages, extents, segments, and inodes.• Principles of ACID compliance

Ryan Robson

Brainchild of Michael “Monty” Widenius - founder of MySQL.


Dat

a D

icti

onar

yTable

id

flags

columns

indexes

appr. rows

Columnsnames

lengths

data types

Indexes

id

fields

unique?

location

Constraints

What does the data dictionary contain?Tables• IDs• Structural

Metadata

Columns• Names• Attributes

Indexes• IDs• Types

Where is the data dictionary stored?

ibdata1

Stores the system tablespace, which contains the data dictionary

Composed internally of "system tables" that store metadata on table structures.Stored by default in the data directory, which defaults to /var/lib/mysql


Removing this is essentially the same as removing access to all of your InnoDB tables. That's the only reason that this can appear to "fix" a crashed MySQL environment.

ibdata1

Can be removed for re-creation fairly safely, and can be necessary in some recovery/repair situations.

ib_logfileX

In the Data Directory


Data Dictionar

y•Exists•Stored Correctly

File System

•Exists•Accessible

Error: Trying to open a table, but could not open the tablespace file './database/table.ibd'!

Unrecognized Table


Data Dictionar


File System


Unrecognized Table

Error: Can't open table from data dictionary though .frm file exists


Data Dictionar


File System


Functional Ta-ble


Deciphering the Error Logs

Error Types

Data Dictionary

Checksum Mismatch

Unable to open/read/write/access fileAssertion failure

Signal 6/Signal 11

Page checksum 863794368, prior-to-4.0.14-form checksumstored checksum 1169627998, prior-to-4.0.14-form stored checksum 2838245694

ExamplesCan't open table from data dictionary though frm file exists

Error: trying to open a table, but could not open the tablespace file './horde/horde_cache.ibd'!

Assertion failure in thread 3067665264 in file buf0buf.cc line 2641

20:13:06 UTC - mysqld got signal 6 ;


Data Dictionary ErrorsWhy do they occur? What are your options?

Deleted or moved ibdata1 file

Migrated from another environment

Copies are made, but extensions are left intact

Files are backed up directly, then restored

Restore from a backup

Recover an ibdata1 file

Try to establish a copy of the data from a dump or table copyRecover the CREATE TABLE statement. re-create the table.


Alchemy SolutionsWARNINGBefore attempting any alternative recovery solutions, always make sure to back up your MySQL data in whatever way possible:

Perform MySQL dumps (when possible):mysqldump –AER > /root/dump.sql

Make a copy of the MySQL data directory (or at least the ibdata* and ib_log* files):

cp –Rp /var/lib/mysql /var/lib/mysql.bak


Alchemy SolutionsHex Editing

Name Byte Length Offset DescriptionFIL_PAGE_SPACE_OR_CHKSUM 4 0 Checksum (Space ID in older MySQL versions)

FIL_PAGE_OFFSET 4 4 Page NumberFIL_PAGE_PREV 4 8 Previous Page (in key order)FIL_PAGE_NEXT 4 12 Next Page (in key order)FIL_PAGE_LSN 8 16 LSN of page’s latest log recordFIL_PAGE_TYPE 2 24 Page Type

FIL_PAGE_FILE_FLUSH_LSN 8 26 Flushed-up-to LSN (only in space ID 0, page 0)FIL_PAGE_ARCH_LOG_NO_OR_SPACE_ID 4 34 Space ID

InnoDB data is frequently stored in predictable, usable patterns at the byte level, in a page-by-page format, each page representing a 16384-byte block of data. Using this, you can directly modify a number of values in files stored by InnoDB to affect their behavior.

storage/innobase/include/fil0fil.h


Alchemy SolutionsData dictionary example scenario:Space ID conflict shows in the error log ( /var/lib/mysql/`hostname`.err ):Error: tablespace id in file ‘dictionary.ibd' is 12, but in the InnoDB data dictionary it is 6.

-bash-4.1# xxd -ps -s 34 -l 4 dictionary.ibd0000000c-bash-4.1# xxd -ps -s 38 -l 4 dictionary.ibd0000000c-bash-4.1# echo $((0x0c))12

Hex value stored in two primary locations in the .ibd file:


Alchemy SolutionsData dictionary example scenario:Writing the new space ID to the appropriate byte locations in the tablespace file (.ibd file):-bash-4.1# cd /var/lib/mysql/roundcube-bash-4.1# printf ‘\x00\x00\x00\x06’ | dd of=dictionary.ibd bs=1 seek=34 count=4 conv=notrunc-bash-4.1# printf ‘\x00\x00\x00\x06’ | dd of=dictionary.ibd bs=1 seek=38 count=4 conv=notrunc

The stored space ID within this tablespace file is now “6”, in the primary two locations.

Once the table is successfully loaded back into MySQL, be sure to make a dump, drop the table, and re-import that dump to make sure everything has properly and “organically” been added back into the data dictionary and MySQL metadata.


Page Corruption ErrorsWhy do they occur? What are your options?

Power failure / Physical failure

Hardware failure

Driver / Kernel bug

File system write errors

No built-in mechanism to “repair” a corrupted page

MySQL may be offline

Logged information can be ambiguous or unspecific

Backups may not be available


mysql> SELECT COUNT(1) FROM customer_corrupt;ERROR 2006 (HY000): MySQL server has gone awayNo connection. Trying to reconnect...Connection id: 1Current database: testdb

+----------+| COUNT(1) |+----------+| 599 |+----------+1 row in set (0.00 sec)

You might see something like..


Alchemy SolutionsPage corruption example scenario:140911 13:21:36 InnoDB: Page checksum 4116551042, prior-to-4.0.14-form

checksum 351785139InnoDB: stored checksum 4003879582, prior-to-4.0.14-form stored checksum 2163901611InnoDB: Page lsn 3886914220 2890537894, low 4 bytes of lsn at page end 12867924InnoDB: Page number (if stored to page already) 2948225628,InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 3390548810…140911 13:21:36 InnoDB: Error: space id and page n:o stored in the pageInnoDB: read in are 3390548810:2948225628, should be 236:8!InnoDB: Database page corruption on disk or a failedInnoDB: file read of page 8.40

4116551042351785139

40038795822163901611

29482256283390548810

3390548810:2948225628 236:8

Space ID (and potentially page ID) hex edit method can potentially be applied here as well, however the checksum will still need to be adjusted.



Name Byte Length Offset DescriptionFIL_PAGE_SPACE_OR_CHKSUM 4 0 Checksum (Space ID in older MySQL versions)

FIL_PAGE_OFFSET 4 4 Page NumberFIL_PAGE_PREV 4 8 Previous Page (in key order)

… … … …

So we know how to correct that space ID, and we can probably translate that over to changing the page number (referred to as “page offset” in the source) as well. How about changing the checksum?

The thing about doing any kind of manual changes to the physical InnoDB files is that this method will ALWAYS produce a checksum mismatch, because any byte changes in the file will of course affect the calculated checksum. So not only can updating the checksum alone be one way to try getting back some quick access to your table in a serious recovery scenario, but it is in fact a required final step to doing any byte manipulation with InnoDB.





FIL Trailer (8)Name Byte Length Offset Description

FIL_PAGE_END_LSN 8 16376 Low 4 bytes: Checksum, Last 4 bytes: FIL_PAGE_LSN

In order to do this properly, we’ll need to be aware of one other location in which the checksum for each page is stored – the trailer. This is an 8-byte set of values that are stored at the end of each 16384-byte page, meaning that It begins at byte offset 16376 of a page, and ends with the byte at offset 16383.

The checksum stored here is a little different, as it is considered the old-style (pre-4.0) checksum. This is stored here simply as a secondary means of verification, along with the primary, “new-style” checksum at the beginning of the page.



InnoDB: Page checksum 4116551042, prior-to-4.0.14-form checksum 351785139InnoDB: stored checksum 4003879582, prior-to-4.0.14-form stored checksum 2163901611# printf '%X\n' 4116551042; printf '%X\n' 351785139F55D9582 Primary calculated checksum14F7D0B3 “Old-style” calculated checksum# expr 16384 \* 8 Example Page 8131072 Starting byte offset for Page 8

Writing the primary calculated checksum over the stored value of page 6:# printf ‘\xF5\x5D\x95\x82’ | dd of=table.ibd bs=1 seek=98304 count=4 conv=notrunc


The Future• MariaDB defaulting with XtraDB• Aria being developed to eventually be a combination of

MyISAM and InnoDB’s key features• InnoDB features being developed to allow more flexibility

and fewer limitations on the way that the file system can be utilized, or that tablespace files can be imported.

• Data dictionary being revamped.


Online CoursesA 3-unit advanced course on InnoDB is currently being developed for our cPanel University learning environment. The first one, which is based on last year’s InnoDB Anatomy presentation, is available online now for preview access by using the group code: cPanelConf2015

Questions?#cpanelconf

Contact

#cpanelconf

Email: [email protected]: cPanelRyan

LinkedIn: https://www.linkedin.com/in/robworks

Technology

cPanelCon 2015: InnoDB Alchemy