Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-8143

InnoDB: Database page corruption on disk or a failed file read

        Details

          Description

          t3.test
          
--source include/have_file_key_management_plugin.inc
--source include/have_innodb.inc

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB ENCRYPTION_KEY_ID=2 ENCRYPTED=YES;
INSERT INTO t1 VALUES (1),(2);

--echo # Restarting server...
--source include/restart_mysqld.inc

SELECT * FROM t1;

DROP TABLE t1;

          Note: ENCRYPTION_KEY_ID seems important there.

          test3.opt
          --innodb-encrypt-tables=ON --innodb-encrypt-log=ON

          InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3.
InnoDB: You may have to recover from a backup.
2015-05-12 02:14:58 7f427ad19700 InnoDB: Page dump in ascii and hex (16384 bytes):
...
InnoDB: End of page dump
2015-05-12 02:14:58 7f427ad19700 InnoDB: uncompressed page, stored checksum in field1 3155544538, calculated checksums for field1: crc32 1153903700, innodb 3661542435, none 3735928559, stored checksum in field2 2019848762, calculated checksums for field2: crc32 1153903700, innodb 2019848762, none 3735928559, page LSN 0 1632949, low 4 bytes of LSN at page end 1632949, page number (if stored to page already) 3, space id (if created with >= MySQL-4.1.1 and stored already) 4
InnoDB: page type 1170145280 meaning PAGE TYPE CORRUPTED
InnoDB: Page may be an index page where index id is 2531656440215341738
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 3.
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: Error: Unable to read tablespace 4 page no 3 into the buffer pool after 100 attempts
InnoDB: The most probable cause of this error may be that the table has been corrupted.
InnoDB: You can try to fix this problem by using innodb_force_recovery.
InnoDB: Please see reference manual for more details.
InnoDB: Aborting...
2015-05-12 02:15:03 7f427ad19700  InnoDB: Assertion failure in thread 139923505125120 in file buf0buf.cc line 2792
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.
150512  2:15:03 [ERROR] mysqld got signal 6 ;
          Stack trace from 10.1 commit 58e8db2eb3
          #5  0x00007f42789473e0 in *__GI_abort () at abort.c:92
#6  0x00007f4271e38f42 in buf_page_get_gen (space=4, zip_size=0, offset=3, rw_latch=2, guess=0x0, mode=10, file=0x7f42720a61f0 "10.1/storage/innobase/btr/btr0btr.cc", line=736, mtr=0x7f427ad159c0) at 10.1/storage/innobase/buf/buf0buf.cc:2792
#7  0x00007f4271df7834 in btr_block_get_func (space=4, zip_size=0, page_no=3, mode=2, file=0x7f42720a61f0 "10.1/storage/innobase/btr/btr0btr.cc", line=736, index=0x7f426312d978, mtr=0x7f427ad159c0) at 10.1/storage/innobase/include/btr0btr.ic:60
#8  0x00007f4271df85de in btr_root_block_get (index=0x7f426312d978, mode=2, mtr=0x7f427ad159c0) at 10.1/storage/innobase/btr/btr0btr.cc:736
#9  0x00007f4271df8718 in btr_root_get (index=0x7f426312d978, mtr=0x7f427ad159c0) at 10.1/storage/innobase/btr/btr0btr.cc:763
#10 0x00007f4271df9505 in btr_get_size_and_reserved (index=0x7f426312d978, flag=2, used=0x7f427ad15988, mtr=0x7f427ad159c0) at 10.1/storage/innobase/btr/btr0btr.cc:1256
#11 0x00007f4271df9402 in btr_get_size (index=0x7f426312d978, flag=2, mtr=0x7f427ad159c0) at 10.1/storage/innobase/btr/btr0btr.cc:1220
#12 0x00007f4271e91506 in dict_stats_update_transient_for_index (index=0x7f426312d978) at 10.1/storage/innobase/dict/dict0stats.cc:889
#13 0x00007f4271e9173b in dict_stats_update_transient (table=0x7f426312d378) at 10.1/storage/innobase/dict/dict0stats.cc:965
#14 0x00007f4271e96029 in dict_stats_update (table=0x7f426312d378, stats_upd_option=DICT_STATS_RECALC_TRANSIENT) at 10.1/storage/innobase/dict/dict0stats.cc:3387
#15 0x00007f4271efa3da in dict_stats_init (table=0x7f426312d378) at 10.1/storage/innobase/include/dict0stats.ic:174
#16 0x00007f4271f00b3e in ha_innodb::open (this=0x7f426307d088, name=0x7f426306bf60 "./test/t1", mode=2, test_if_locked=18) at 10.1/storage/innobase/handler/ha_innodb.cc:5581
#17 0x00007f427b4a4334 in handler::ha_open (this=0x7f426307d088, table_arg=0x7f426309ea70, name=0x7f426306bf60 "./test/t1", mode=2, test_if_locked=18) at 10.1/sql/handler.cc:2516
#18 0x00007f427b35be49 in open_table_from_share (thd=0x7f426bcd4070, share=0x7f426306ba88, alias=0x7f42630e4260 "t1", db_stat=39, prgflag=44, ha_open_flags=18, outparam=0x7f426309ea70, is_create_table=false) at 10.1/sql/table.cc:2920
#19 0x00007f427b209d05 in open_table (thd=0x7f426bcd4070, table_list=0x7f42630e4268, ot_ctx=0x7f427ad16f90) at 10.1/sql/sql_base.cc:2550
#20 0x00007f427b20c53a in open_and_process_table (thd=0x7f426bcd4070, lex=0x7f426bcd7d28, tables=0x7f42630e4268, counter=0x7f427ad17034, flags=0, prelocking_strategy=0x7f427ad170a0, has_prelocking_list=false, ot_ctx=0x7f427ad16f90) at 10.1/sql/sql_base.cc:4016
#21 0x00007f427b20d71c in open_tables (thd=0x7f426bcd4070, options=..., start=0x7f427ad17018, counter=0x7f427ad17034, flags=0, prelocking_strategy=0x7f427ad170a0) at 10.1/sql/sql_base.cc:4541
#22 0x00007f427b20e904 in open_and_lock_tables (thd=0x7f426bcd4070, options=..., tables=0x7f42630e4268, derived=true, flags=0, prelocking_strategy=0x7f427ad170a0) at 10.1/sql/sql_base.cc:5199
#23 0x00007f427b2022ff in open_and_lock_tables (thd=0x7f426bcd4070, tables=0x7f42630e4268, derived=true, flags=0) at 10.1/sql/sql_base.h:530
#24 0x00007f427b27a96b in execute_sqlcom_select (thd=0x7f426bcd4070, all_tables=0x7f42630e4268) at 10.1/sql/sql_parse.cc:5703
#25 0x00007f427b271189 in mysql_execute_command (thd=0x7f426bcd4070) at 10.1/sql/sql_parse.cc:2926
#26 0x00007f427b27e3fe in mysql_parse (thd=0x7f426bcd4070, rawbuf=0x7f42630e4088 "SELECT * FROM t1", length=16, parser_state=0x7f427ad181b0) at 10.1/sql/sql_parse.cc:7165
#27 0x00007f427b26d40e in dispatch_command (command=COM_QUERY, thd=0x7f426bcd4070, packet=0x7f42713d8071 "SELECT * FROM t1", packet_length=16) at 10.1/sql/sql_parse.cc:1462
#28 0x00007f427b26c1de in do_command (thd=0x7f426bcd4070) at 10.1/sql/sql_parse.cc:1090
#29 0x00007f427b39d767 in do_handle_one_connection (thd_arg=0x7f426bcd4070) at 10.1/sql/sql_connect.cc:1347
#30 0x00007f427b39d4ac in handle_one_connection (arg=0x7f426bcd4070) at 10.1/sql/sql_connect.cc:1258
#31 0x00007f427b956472 in pfs_spawn_thread (arg=0x7f42780244f0) at 10.1/storage/perfschema/pfs.cc:1860
#32 0x00007f427a958b50 in start_thread (arg=<optimized out>) at pthread_create.c:304
#33 0x00007f42789ed95d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

            Gliffy Diagrams

              Attachments

                Activity

                Hide
                Permalink
                jplindst Jan Lindström added a comment -

                commit f8cacd03a79e56746434f7c12e2ed8dd6a534b8e
                Author: Jan Lindström <jan.lindstrom@mariadb.com>
                Date: Wed May 13 11:41:22 2015 +0300

                MDEV-8143: InnoDB: Database page corruption on disk or a failed file read

                Analysis: Problem was that we did create crypt data for encrypted table but
                this new crypt data was not written to page 0. Instead a default crypt data
                was written to page 0 at table creation.

                Fixed by explicitly writing new crypt data to page 0 after successfull
                table creation.

                Show
                jplindst Jan Lindström added a comment - commit f8cacd03a79e56746434f7c12e2ed8dd6a534b8e Author: Jan Lindström <jan.lindstrom@mariadb.com> Date: Wed May 13 11:41:22 2015 +0300 MDEV-8143 : InnoDB: Database page corruption on disk or a failed file read Analysis: Problem was that we did create crypt data for encrypted table but this new crypt data was not written to page 0. Instead a default crypt data was written to page 0 at table creation. Fixed by explicitly writing new crypt data to page 0 after successfull table creation.

                  People

                  • Assignee:
                    jplindst Jan Lindström
                    Reporter:
                    elenst Elena Stepanova
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    3 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: