Fix bug 1548597 / 76142 (InnoDB tablespace import fails when importin… #615
Conversation
|
@kbauskar, if you happen to be familiar with transportable tablespaces, your second opinion would be very appreciated. Specifically, this fix makes no attempt to re-write imported tablespace flags with the actual data directory flag value, but leaves it mismatched as-is. Based on my understanding of code (see fil_open_single_file_tablespace), this is correct design, but maybe I understood it wrong. |
| --echo # | ||
|
|
||
| --let $MYSQLD_DATADIR = `SELECT @@datadir` | ||
|
|
There was a problem hiding this comment.
Add
--let $CURRENT_DB =
SELECT DATABASE()
and then use ".../$CURRENT_DB/..." in --copy-file / --move_file paths instead of ".../test/..."
|
LGTM with minor MTR test comments |
|
|
||
| if (m_flags != m_table->flags) { | ||
| if (relevant_flags != relevant_table_flags) { |
There was a problem hiding this comment.
I would expect a warning if flag mis-match on data-dir part so that user know we incompatibility we are trying allowing.
There was a problem hiding this comment.
I am not sure - because the user has no means of actually fixing this warning short of hex editor. A warning that's unfixable would be error log spam
|
LGTM. I am not sure what motivated this but may be it would create issues with 5.8 once all this information is moved to data-dictionary. Can be ignore for now though. |
|
Please see my inline comment re. warning. As for 5.8, we would adjust the fix as needed during the porting process. |
|
LGTM. |
…g table w/ different data directory) Importing a transportable tablespace will fail if its table definition has data directory specified while the donor table did not have one, and vice versa. Fix by relaxing the checks in fil_node_open_file() and row_import::match_schema() to allow this particular mismatch while still requiring that the rest of the flags match. Do not actually patch the tablespace header with the new flag value as InnoDB is already making assumptions elsewhere that the data directory flag bits may mismatch. Also fix tablespace import diagnostics that in the case of flags mismatch printed number of columns, not flags. Add a testcase.
laurynas-biveinis
force-pushed
the
bug1548597-5.6
branch
from
9059552
to
ee75a7f
Compare
|
MTR comments addressed, http://jenkins.percona.com/job/percona-server-5.6-param/1207/ |
Summary: If table definition (frm) has changed during myrocks_hotbackup, destination instance may get inconsistent -- having new frm file, but MyRocks sst files are based on snapshots, and their data might be older -- based on old frm file. To prevent such inconsistencies, myrocks_hotbackup checks frm file midification timestamp, and aborts if it is newer than backup starting time. Closes facebook/mysql-5.6#615 Test Plan: xbstream.test Differential Revision: D4946487 Pulled By: yoshinorim fbshipit-source-id: 572a9cc025e
Summary: If table definition (frm) has changed during myrocks_hotbackup, destination instance may get inconsistent -- having new frm file, but MyRocks sst files are based on snapshots, and their data might be older -- based on old frm file. To prevent such inconsistencies, myrocks_hotbackup checks frm file midification timestamp, and aborts if it is newer than backup starting time. Closes facebook/mysql-5.6#615 Test Plan: xbstream.test Differential Revision: D4946487 Pulled By: yoshinorim fbshipit-source-id: 572a9cc025e
…#615) Summary: If table definition (frm) has changed during myrocks_hotbackup, destination instance may get inconsistent -- having new frm file, but MyRocks sst files are based on snapshots, and their data might be older -- based on old frm file. To prevent such inconsistencies, myrocks_hotbackup checks frm file midification timestamp, and aborts if it is newer than backup starting time. Closes facebook/mysql-5.6#615 Differential Revision: D4946487 (facebook/mysql-5.6@f5f79fe) Pulled By: yoshinorim fbshipit-source-id: 1c789be62e0
…#615) Summary: If table definition (frm) has changed during myrocks_hotbackup, destination instance may get inconsistent -- having new frm file, but MyRocks sst files are based on snapshots, and their data might be older -- based on old frm file. To prevent such inconsistencies, myrocks_hotbackup checks frm file midification timestamp, and aborts if it is newer than backup starting time. Closes facebook/mysql-5.6#615 Differential Revision: D4946487 Pulled By: yoshinorim
…#615) Summary: If table definition (frm) has changed during myrocks_hotbackup, destination instance may get inconsistent -- having new frm file, but MyRocks sst files are based on snapshots, and their data might be older -- based on old frm file. To prevent such inconsistencies, myrocks_hotbackup checks frm file midification timestamp, and aborts if it is newer than backup starting time. Closes facebook/mysql-5.6#615 Differential Revision: D4946487 Pulled By: yoshinorim
…g table w/ different data directory)
Importing a transportable tablespace will fail if its table definition
has data directory specified while the donor table did not have one,
and vice versa. Fix by relaxing the checks in fil_node_open_file() and
row_import::match_schema() to allow this particular mismatch while
still requiring that the rest of the flags match. Do not actually
patch the tablespace header with the new flag value as InnoDB is
already making assumptions elsewhere that the data directory flag bits
may mismatch. Also fix tablespace import diagnostics that in the case
of flags mismatch printed number of columns, not flags. Add a
testcase.
http://jenkins.percona.com/job/percona-server-5.6-param/1189/