Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
# Test to verify that auto-zerofilling happens when a table is
|
2010-09-12 18:40:01 +02:00
|
|
|
# imported from a different Aria instance
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
|
|
|
|
# can't restart in embedded
|
|
|
|
--source include/not_embedded.inc
|
|
|
|
--source include/have_maria.inc
|
|
|
|
|
2011-01-20 18:08:12 +01:00
|
|
|
call mtr.add_suppression("Table 't1' is marked as crashed and should be repaired");
|
|
|
|
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
let $MARIA_LOG=.;
|
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
drop database if exists mysqltest;
|
|
|
|
--enable_warnings
|
|
|
|
create database mysqltest;
|
|
|
|
let $mms_tname=t;
|
|
|
|
|
|
|
|
connect (admin, localhost, root,,mysqltest,,);
|
|
|
|
--enable_reconnect
|
|
|
|
|
|
|
|
connection default;
|
|
|
|
use mysqltest;
|
|
|
|
--enable_reconnect
|
|
|
|
|
2012-03-28 12:22:21 +02:00
|
|
|
# Create some tables for future tests
|
2010-09-12 18:40:01 +02:00
|
|
|
create table t1(a int) engine=aria;
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
insert into t1 values(1);
|
2012-03-28 12:49:07 +02:00
|
|
|
create table t2 (a int) engine=aria;
|
2012-03-28 12:22:21 +02:00
|
|
|
INSERT INTO t2 VALUES (1),(2);
|
2012-03-28 12:49:07 +02:00
|
|
|
create table t3 (a int) engine=aria;
|
2012-03-28 12:22:21 +02:00
|
|
|
INSERT INTO t3 VALUES (1),(2);
|
2012-03-28 12:49:07 +02:00
|
|
|
create table t4 (a int) engine=aria;
|
2012-03-28 12:22:21 +02:00
|
|
|
INSERT INTO t4 VALUES (1),(2);
|
2012-03-30 12:54:33 +02:00
|
|
|
create table t5 (a int) engine=aria;
|
2012-03-30 12:42:52 +02:00
|
|
|
INSERT INTO t5 VALUES (1),(2);
|
2013-05-14 17:32:16 +02:00
|
|
|
create table t6 (a int) engine=aria;
|
|
|
|
INSERT INTO t6 VALUES (1),(2);
|
2012-03-28 12:22:21 +02:00
|
|
|
flush tables;
|
|
|
|
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
# Check that table is not zerofilled, not movable
|
2009-02-12 15:08:56 +01:00
|
|
|
let $MYSQLD_DATADIR= `select @@datadir`;
|
2013-05-14 17:32:16 +02:00
|
|
|
--exec $MARIA_CHK -dv --ignore-control-file $MYSQLD_DATADIR/mysqltest/t1 >$MYSQLTEST_VARDIR/tmp/ariachk.txt
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
perl;
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
2010-09-12 18:40:01 +02:00
|
|
|
my $fname= "$ENV{'MYSQLTEST_VARDIR'}/tmp/ariachk.txt";
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
open(FILE, "<", $fname) or die;
|
|
|
|
my @content= <FILE>;
|
|
|
|
print grep(/Status:.*(zerofilled|movable)/, @content);
|
|
|
|
print "create_rename_lsn has non-magic value\n" if grep(/create_rename \([0-9]+/, @content);
|
|
|
|
close FILE;
|
|
|
|
EOF
|
|
|
|
|
2010-09-12 18:40:01 +02:00
|
|
|
# this will remove control file, so change the uuid of the Aria
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
# instance, thus t1 will appear as imported from elsewhere.
|
|
|
|
|
|
|
|
-- source include/maria_empty_logs.inc
|
|
|
|
|
2010-09-12 18:40:01 +02:00
|
|
|
disable_ps_protocol; # see aria-recover.test
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
replace_regex /Table.*t1/t1/ ;
|
2012-03-29 18:06:08 +02:00
|
|
|
replace_result \\ /;
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
select * from t1;
|
|
|
|
enable_ps_protocol;
|
|
|
|
flush table t1;
|
|
|
|
|
|
|
|
# Check that table is auto-zerofilled, movable
|
2013-05-14 17:32:16 +02:00
|
|
|
--exec $MARIA_CHK -dv --ignore-control-file $MYSQLD_DATADIR/mysqltest/t1 >$MYSQLTEST_VARDIR/tmp/ariachk.txt
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
perl;
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
2010-09-12 18:40:01 +02:00
|
|
|
my $fname= "$ENV{'MYSQLTEST_VARDIR'}/tmp/ariachk.txt";
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
open(FILE, "<", $fname) or die;
|
|
|
|
my @content= <FILE>;
|
|
|
|
print grep(/Status:.*zerofilled/, @content);
|
|
|
|
print "create_rename_lsn has magic value\n" if grep(/create_rename \(0,0x2\)/, @content);
|
|
|
|
close FILE;
|
|
|
|
EOF
|
|
|
|
|
2010-09-12 18:40:01 +02:00
|
|
|
# this will attach t1 to the current Aria instance
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
insert into t1 values(2);
|
|
|
|
flush table t1;
|
|
|
|
|
|
|
|
# Check that table is not zerofilled, not movable
|
2013-05-14 17:32:16 +02:00
|
|
|
--exec $MARIA_CHK -dv --ignore-control-file $MYSQLD_DATADIR/mysqltest/t1 >$MYSQLTEST_VARDIR/tmp/ariachk.txt
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
perl;
|
|
|
|
use strict;
|
|
|
|
use warnings;
|
2010-09-12 18:40:01 +02:00
|
|
|
my $fname= "$ENV{'MYSQLTEST_VARDIR'}/tmp/ariachk.txt";
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
open(FILE, "<", $fname) or die;
|
|
|
|
my @content= <FILE>;
|
|
|
|
print grep(/Status:.*(zerofilled|movable)/, @content);
|
|
|
|
print "create_rename_lsn has non-magic value\n" if grep(/create_rename \([0-9]+/, @content);
|
|
|
|
close FILE;
|
|
|
|
EOF
|
|
|
|
|
2013-05-14 17:32:16 +02:00
|
|
|
--echo #
|
|
|
|
--echo # BUG#44422 "mysql_upgrade destroys Maria tables?"
|
|
|
|
--echo # Check repair and optimize of moved table
|
|
|
|
--echo #
|
|
|
|
|
|
|
|
# Table t2 is regarded as it would be from another server as we removed
|
|
|
|
# the aria control file earlier
|
2012-03-28 12:22:21 +02:00
|
|
|
check table t2;
|
|
|
|
check table t2;
|
|
|
|
repair table t2;
|
2012-03-30 12:42:52 +02:00
|
|
|
check table t2;
|
2012-03-29 18:06:08 +02:00
|
|
|
replace_result \\ /;
|
2012-03-28 12:22:21 +02:00
|
|
|
optimize table t3;
|
2012-03-29 18:06:08 +02:00
|
|
|
replace_result \\ /;
|
2012-03-28 12:22:21 +02:00
|
|
|
analyze table t4;
|
2012-03-30 12:42:52 +02:00
|
|
|
repair table t5;
|
|
|
|
check table t5;
|
|
|
|
repair table t5;
|
|
|
|
check table t5;
|
2012-03-28 12:22:21 +02:00
|
|
|
|
2013-05-14 17:32:16 +02:00
|
|
|
# Check that if we zerofill with aria_chk, we should not get any warnings when
|
|
|
|
# accessing the table
|
|
|
|
--exec $MARIA_CHK --zerofill $MYSQLD_DATADIR/mysqltest/t6 >$MYSQLTEST_VARDIR/tmp/ariachk.txt
|
|
|
|
select * from t6;
|
|
|
|
check table t6;
|
|
|
|
|
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work":
- after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could
be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN
serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which
maria_zerofill() did change were lost (because they didn't go to disk).
- after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed())
they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log
record each time a table is imported.
- Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv.
mysql-test/r/maria-autozerofill.result:
result
mysql-test/t/maria-autozerofill.test:
Test for auto-zerofilling
storage/maria/ha_maria.cc:
The state changes done by auto-zerofilling never reached disk.
storage/maria/ma_check.c:
When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table
is imported into a Maria instance.
storage/maria/ma_create.c:
Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures
that the table gets a unique create_rename_lsn even though multiple tables
are imported by concurrent threads (it advances the log's end LSN).
storage/maria/ma_key_recover.c:
comment
storage/maria/ma_locking.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_loghandler.c:
New type of log record
storage/maria/ma_loghandler.h:
New type of log record
storage/maria/ma_loghandler_lsn.h:
New name for constant as can be used not only by maria_chk but auto-zerofill now too.
storage/maria/ma_open.c:
instead of using translog_get_horizon() for state's LSNs of imported table,
use the LSN of to-be-written LOGREC_IMPORTED_TABLE.
storage/maria/ma_recovery.c:
print content of LOGREC_IMPORTED_TABLE in maria_read_log.
storage/maria/maria_chk.c:
print info about LSNs of the table's state, and UUID, when maria_chk -dvv
storage/maria/maria_pack.c:
new name for constant
storage/maria/unittest/ma_test_recovery.pl:
Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out,
as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
|
|
|
drop database mysqltest;
|