mariadb/mysql-test/suite/maria/maria-recovery3.result

117 lines
3.7 KiB
Text
Raw Normal View History

2011-04-25 17:22:25 +02:00
set global aria_log_file_size=4294959104;
drop database if exists mysqltest;
create database mysqltest;
use mysqltest;
* shut down mysqld, removed logs, restarted it
* TEST of Checkpoint between writing the commit log record and committing in trnman
2010-09-12 18:40:01 +02:00
create table t1(a int primary key) engine=aria;
insert into t1 values(1);
flush table t1;
* copied t1 for comparison
set session debug_dbug="+d,maria_sleep_in_commit";
insert into t1 values(2);
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=1000;
delete from t1 where a=2;
SET SESSION debug_dbug="+d,maria_flush_whole_log,maria_crash";
* crashing mysqld intentionally
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=1;
ERROR HY000: Lost connection to MySQL server during query
* recovery happens
check table t1 extended;
Table Op Msg_type Msg_text
mysqltest.t1 check status OK
* testing that checksum after recovery is as expected
Checksum-check
ok
use mysqltest;
drop table t1;
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
* TEST of logging of BLOBs
CREATE TABLE `t1` (
`blob` blob,
`blob_key` blob
2010-09-12 18:40:01 +02:00
) ENGINE=aria ROW_FORMAT=page
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
;
* copied t1 for feeding_recovery
* compared t1 to old version
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=0;
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
INSERT INTO `t1` VALUES (NULL,repeat('A',5198));
INSERT INTO `t1` VALUES (NULL,repeat('B',65535));
INSERT INTO `t1` VALUES (repeat('K',5198),repeat('L',2325));
INSERT INTO `t1` VALUES (repeat('C',65535),NULL);
INSERT INTO `t1` VALUES (NULL,repeat('D',65535));
INSERT INTO `t1` VALUES (repeat('E',65535),repeat('F',16111));
INSERT INTO `t1` VALUES (repeat('G',65535),repeat('H',65535));
INSERT INTO `t1` VALUES (repeat('I',5198),repeat('J',65535));
check table t1 extended;
Table Op Msg_type Msg_text
mysqltest.t1 check status OK
flush table t1;
* copied t1 for comparison
* compared t1 to old version
SET SESSION debug_dbug="+d,maria_flush_whole_log,maria_crash";
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
* crashing mysqld intentionally
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=1;
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
ERROR HY000: Lost connection to MySQL server during query
* copied t1 back for feeding_recovery
* recovery happens
check table t1 extended;
Table Op Msg_type Msg_text
mysqltest.t1 check status OK
* testing that checksum after recovery is as expected
Checksum-check
ok
* compared t1 to old version
use mysqltest;
drop table t1;
2010-09-12 18:40:01 +02:00
create table t1 engine=aria select 1;
* copied t1 for feeding_recovery
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=0;
insert into t1 values(2);
truncate table t1;
flush table t1;
* copied t1 for comparison
truncate table t1;
SET SESSION debug_dbug="+d,maria_flush_whole_log,maria_crash_create_table";
* crashing mysqld intentionally
truncate table t1;
ERROR HY000: Lost connection to MySQL server during query
* recovery happens
check table t1 extended;
Table Op Msg_type Msg_text
Fixed several errors in Aria discovered by test case for lp:727869 ma_pagecache.c:2103: find_block: Assertion `block->rlocks == 0 - Fixed assert in transaction log handler when aria_check was run on block-record table that was much bigger than expected. - Fixed warnings about wrong mutex order between bitmap and intern_lock - Fixed error in bitmap that could cause two rows to use same block for a block record. - Fixed wrong test that could cause error if last page for a bitmap was used by a blob. - Fixed several bugs in pagecache for the case where pagecase had very few blocks and there was a lot of threads competing to get the blocks (very unlikely case). mysql-test/suite/maria/r/maria-recovery3.result: Updated results sql/mysqld.cc: Allow mi_check() to send information messages for log file storage/maria/ma_bitmap.c: Fixed problem with wrong mutex order when bitmap was the first page that was flushed out of page cache - Fixed by introducing _ma_bitmap_mark_file_changed() that marks file changed without a bitmap lock. - Fixed one case in _ma_change_bitmap_page() where we didn't mark the bitmap changed. This could cause to rows to reuse same block if this was the only change to the bitmap. - Split _ma_bitmap_get_page_bits() in two parts to not take a bitmap lock when we already have it - Fixed bug in _ma_bitmap_set_full_page_bits() that caused an error if last page for a bitmap was used by a blob storage/maria/ma_check.c: Better handling of wrong file length. Fixed bug when we tried to write to transaction log when it was not opened (happened when block record file was bigger than expected) storage/maria/ma_pagecache.c: Fixed several bugs in pagecache for the case where pagecase had very few blocks and there was a lot of threads competing to get the blocks: - In link_block() mark a block given to another thread with PCBLOCK_REASSIGNED to ensure that no other threads can start re-using the block before the thread that requsted a block. - In free_block(), don't reset status for a block that is in re-assign by link_block() (we don't want to loose the PCBLOCK_REASSIGNED flag). - Added call to wait_for_flush() when we got a new block in find_block() to ensure that we don't use a block that is beeing flushed by another thread. - Moved setting of hits_left and last_hit_time in find_block() to where we assign the block. Code cleanup and making code uniform: - Changed a lot of KEYCACHE_DBUG_PRINT to use DBUG_PRINT - Streamlined all reporting of 'signal' and 'wait' between threads to be identical. - Use thread name instead of thread number (for each match against --debug) - Added more DBUG_ENTER, DBUG_PRINT and DBUG_ASSERT() - Added more comments storage/myisam/ha_myisam.cc: Only print information about that we make a backup if we are really making a backup. storage/myisam/mi_check.c: Inform mysqld that we are creating a backup of the data file (for inclusion in error log).
2011-06-24 11:08:45 +02:00
mysqltest.t1 check warning Size of indexfile is: 372 Expected: 8192
mysqltest.t1 check status OK
* testing that checksum after recovery is as expected
Checksum-check
ok
use mysqltest;
truncate table t1;
check table t1 extended;
Table Op Msg_type Msg_text
mysqltest.t1 check status OK
drop table t1;
CREATE TABLE t1 ( word VARCHAR(255) PRIMARY KEY ) ENGINE=Aria;
LOAD DATA INFILE '../../std_data/bug887051.txt' INTO TABLE t1;
SET AUTOCOMMIT=0;
DELETE FROM t1;
LOAD DATA INFILE '../../std_data/bug887051.txt' INTO TABLE t1 IGNORE 1 LINES;
COMMIT;
2012-01-13 15:50:02 +01:00
SET SESSION debug_dbug="+d,maria_flush_whole_log,maria_crash";
* crashing mysqld intentionally
set global aria_checkpoint_interval=1;
ERROR HY000: Lost connection to MySQL server during query
* recovery happens
check table t1 extended;
Table Op Msg_type Msg_text
mysqltest.t1 check status OK
* testing that checksum after recovery is as expected
Checksum-check
failure
use mysqltest;
select * from t1;
word
saved2
drop table t1;
drop database mysqltest_for_feeding_recovery;
drop database mysqltest_for_comparison;
drop database mysqltest;