15.6.1.3 InnoDB テーブルのインポート

このセクションでは、file-per-table テーブルスペースに存在するテーブル、パーティションテーブルまたは個々のテーブルパーティションのインポートを許可するトランスポータブルテーブルスペース機能を使用してテーブルをインポートする方法について説明します。テーブルをインポートする理由は多数あります:

本番以外の MySQL サーバーインスタンスでレポートを実行して、本番サーバーに余分な負荷をかけないようにします。
新しいレプリカサーバーにデータをコピーします。
バックアップされたテーブルスペースファイルからテーブルをリストアします。
ダンプファイルをインポートするよりも高速にデータを移動できるため、データを再挿入してインデックスを再構築する必要があります。
ストレージ要件に適したストレージメディアを備えたサーバーにデータを移動する場合。たとえば、ビジー状態のテーブルを SSD デバイスに移動したり、大容量のテーブルを大容量 HDD デバイスに移動したりできます。

トランスポータブルテーブルスペース機能については、このセクションの次のトピックで説明します:

前提条件

innodb_file_per_table 変数は、デフォルトで有効になっている必要があります。
テーブルスペースのページサイズは、宛先 MySQL サーバーインスタンスのページサイズと一致する必要があります。 InnoDB のページサイズは、MySQL サーバーインスタンスの初期化時に構成される innodb_page_size 変数によって定義されます。
テーブルが外部キー関係にある場合は、DISCARD TABLESPACE を実行する前に foreign_key_checks を無効にする必要があります。また、ALTER TABLE ... IMPORT TABLESPACE ではインポートされたデータに外部キー制約が強制されないため、すべての外部キー関連テーブルを同じ論理的な時点でエクスポートする必要があります。これを行うには、関連するテーブルの更新を停止し、すべてのトランザクションをコミットし、テーブルの共有ロックを取得して、エクスポート操作を実行します。
別の MySQL サーバーインスタンスからテーブルをインポートする場合、両方の MySQL サーバーインスタンスのステータスは GA (General Availability) であり、同じバージョンである必要があります。それ以外の場合は、インポート先と同じ MySQL サーバーインスタンスにテーブルを作成する必要があります。
CREATE TABLE ステートメントで DATA DIRECTORY 句を指定して外部ディレクトリにテーブルを作成した場合は、宛先インスタンスで置換するテーブルを同じ DATA DIRECTORY 句で定義する必要があります。句が一致しない場合は、スキーマの不一致エラーが報告されます。ソーステーブルが DATA DIRECTORY 句で定義されているかどうかを確認するには、SHOW CREATE TABLE を使用してテーブル定義を表示します。 DATA DIRECTORY 句の使用の詳細は、セクション15.6.1.2「外部でのテーブルの作成」を参照してください。
ROW_FORMAT オプションがテーブル定義で明示的に定義されていない場合、または ROW_FORMAT=DEFAULT が使用されている場合、innodb_default_row_format 設定はソースインスタンスと宛先インスタンスで同じである必要があります。そうしないと、インポート操作を試行したときにスキーマの不一致エラーが報告されます。 SHOW CREATE TABLE を使用してテーブル定義を確認します。 SHOW VARIABLES を使用して、innodb_default_row_format 設定を確認します。関連情報については、テーブルの行形式の定義を参照してください。

テーブルのインポート

この例では、file-per-table テーブルスペースに存在する通常の非パーティションテーブルをインポートする方法を示します。

宛先インスタンスで、インポートするテーブルと同じ定義でテーブルを作成します。 (テーブル定義は、SHOW CREATE TABLE 構文を使用して取得できます。) テーブル定義が一致しない場合は、インポート操作を試行するとスキーマの不一致エラーが報告されます。
```
mysql> USE test;
mysql> CREATE TABLE t1 (c1 INT) ENGINE=INNODB;
```
宛先インスタンスで、作成したテーブルのテーブルスペースを破棄します。 (インポートする前に、受信側のテーブルのテーブルスペースを破棄する必要があります。)
```
mysql> ALTER TABLE t1 DISCARD TABLESPACE;
```
ソースインスタンスで、FLUSH TABLES ... FOR EXPORT を実行して、インポートするテーブルを静止します。テーブルが静止している場合、テーブルでは読取り専用トランザクションのみが許可されます。
```
mysql> USE test;
mysql> FLUSH TABLES t1 FOR EXPORT;
```
FLUSH TABLES ... FOR EXPORT は、サーバーの実行中にバイナリテーブルのコピーを作成できるように、指定されたテーブルへの変更がディスクにフラッシュされていることを確認します。 FLUSH TABLES ... FOR EXPORT を実行すると、InnoDB によって、テーブルのスキーマディレクトリに .cfg メタデータファイルが生成されます。 .cfg ファイルには、インポート操作中のスキーマ検証に使用されるメタデータが含まれています。
.ibd ファイルおよび .cfg メタデータファイルをソースインスタンスから宛先インスタンスにコピーします。例:
```
shell> scp /path/to/datadir/test/t1.{ibd,cfg} destination-server:/path/to/datadir/test
```
.ibd ファイルおよび .cfg ファイルは、次の手順で示すように、共有ロックを解放する前にコピーする必要があります。
注記
暗号化されたテーブルスペースからテーブルをインポートする場合、InnoDB は .cfg メタデータファイルに加えて .cfp ファイルを生成します。 .cfp ファイルは、.cfg ファイルとともに宛先インスタンスにコピーする必要があります。 .cfp ファイルには、転送キーと暗号化されたテーブルスペースキーが含まれます。インポート時に、InnoDB は転送キーを使用してテーブルスペースキーを復号化します。関連情報については、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
ソースインスタンスで、UNLOCK TABLES を使用して、FLUSH TABLES ... FOR EXPORT ステートメントで取得したロックを解放します:
```
mysql> USE test;
mysql> UNLOCK TABLES;
```
宛先インスタンスで、テーブルスペースをインポートします:
```
mysql> USE test;
mysql> ALTER TABLE t1 IMPORT TABLESPACE;
```

パーティションテーブルのインポート

この例では、各テーブルパーティションが file-per-table テーブルスペースに存在するパーティションテーブルをインポートする方法を示します。

宛先インスタンスで、インポートするパーティションテーブルと同じ定義でパーティションテーブルを作成します。 (テーブル定義は、SHOW CREATE TABLE 構文を使用して取得できます。) テーブル定義が一致しない場合は、インポート操作を試行するとスキーマの不一致エラーが報告されます。
```
mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 3;
```
/datadir/test ディレクトリには、3 つのパーティションごとにテーブルスペースの .ibd ファイルがあります。
```
mysql> \! ls /path/to/datadir/test/
t1.frm  t1#p#p0.ibd  t1#p#p1.ibd  t1#p#p2.ibd
```
宛先インスタンスで、パーティションテーブルのテーブルスペースを破棄します。 (インポート操作の前に、受信側のテーブルのテーブルスペースを破棄する必要があります。)
```
mysql> ALTER TABLE t1 DISCARD TABLESPACE;
```
パーティションテーブルの 3 つのテーブルスペース .ibd ファイルが/datadir/test ディレクトリから破棄され、次のファイルが残されます:
```
mysql> \! ls /path/to/datadir/test/
t1.frm
```
ソースインスタンスで、FLUSH TABLES ... FOR EXPORT を実行して、インポートするパーティションテーブルを静止します。テーブルが静止している場合、テーブルでは読取り専用トランザクションのみが許可されます。
```
mysql> USE test;
mysql> FLUSH TABLES t1 FOR EXPORT;
```
FLUSH TABLES ... FOR EXPORT では、サーバーの実行中にバイナリテーブルのコピーを作成できるように、指定されたテーブルへの変更がディスクにフラッシュされます。 FLUSH TABLES ... FOR EXPORT を実行すると、InnoDB によって、各テーブルスペースファイルのテーブルのスキーマディレクトリに .cfg メタデータファイルが生成されます。
```
mysql> \! ls /path/to/datadir/test/
t1#p#p0.ibd  t1#p#p1.ibd  t1#p#p2.ibd
t1.frm  t1#p#p0.cfg  t1#p#p1.cfg  t1#p#p2.cfg
```
.cfg ファイルには、テーブルスペースのインポート時にスキーマ検証に使用されるメタデータが含まれています。 FLUSH TABLES ... FOR EXPORT は、個々のテーブルパーティションではなく、テーブルでのみ実行できます。
.ibd および .cfg ファイルをソースインスタンスのスキーマディレクトリから宛先インスタンスのスキーマディレクトリにコピーします。例:
```
shell>scp /path/to/datadir/test/t1*.{ibd,cfg} destination-server:/path/to/datadir/test
```
次のステップで説明するように、共有ロックを解放する前に .ibd および .cfg ファイルをコピーする必要があります。
注記
暗号化されたテーブルスペースからテーブルをインポートする場合、InnoDB は .cfg メタデータファイルに加えて .cfp ファイルを生成します。 .cfp ファイルは、.cfg ファイルとともに宛先インスタンスにコピーする必要があります。 .cfp ファイルには、転送キーと暗号化されたテーブルスペースキーが含まれます。インポート時に、InnoDB は転送キーを使用してテーブルスペースキーを復号化します。関連情報については、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
ソースインスタンスで、UNLOCK TABLES を使用して、FLUSH TABLES ... FOR EXPORT によって取得されたロックを解放します:
```
mysql> USE test;
mysql> UNLOCK TABLES;
```
宛先インスタンスで、パーティションテーブルのテーブルスペースをインポートします:
```
mysql> USE test;
mysql> ALTER TABLE t1 IMPORT TABLESPACE;
```

テーブルパーティションのインポート

この例では、各パーティションが file-per-table テーブルスペースファイルに存在する個々のテーブルパーティションをインポートする方法を示します。

次の例では、4 つのパーティションテーブルの 2 つのパーティション (p2 および p3) がインポートされます。

宛先インスタンスで、パーティションのインポート元のパーティションテーブルと同じ定義を使用してパーティションテーブルを作成します。 (テーブル定義は、SHOW CREATE TABLE 構文を使用して取得できます。) テーブル定義が一致しない場合は、インポート操作を試行するとスキーマの不一致エラーが報告されます。
```
mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 4;
```
/datadir/test ディレクトリには、4 つのパーティションごとにテーブルスペースの .ibd ファイルがあります。
```
mysql> \! ls /path/to/datadir/test/
t1.frm  t1#p#p0.ibd  t1#p#p1.ibd  t1#p#p2.ibd t1#p#p3.ibd
```
宛先インスタンスで、ソースインスタンスからインポートするパーティションを破棄します。 (パーティションをインポートする前に、受信側のパーティションテーブルから対応するパーティションを破棄する必要があります。)
```
mysql> ALTER TABLE t1 DISCARD PARTITION p2, p3 TABLESPACE;
```
破棄された 2 つのパーティションのテーブルスペース .ibd ファイルが宛先インスタンスの/datadir/test ディレクトリから削除され、次のファイルが残されます:
```
mysql> \! ls /path/to/datadir/test/
t1.frm  t1#p#p0.ibd  t1#p#p1.ibd
```
注記
サブパーティションテーブルで ALTER TABLE ... DISCARD PARTITION ... TABLESPACE を実行する場合、パーティションテーブル名とサブパーティションテーブル名の両方が許可されます。パーティション名を指定すると、そのパーティションのサブパーティションが操作に含まれます。
ソースインスタンスで、FLUSH TABLES ... FOR EXPORT を実行してパーティションテーブルを静止します。テーブルが静止している場合、テーブルでは読取り専用トランザクションのみが許可されます。
```
mysql> USE test;
mysql> FLUSH TABLES t1 FOR EXPORT;
```
FLUSH TABLES ... FOR EXPORT では、インスタンスの実行中にバイナリテーブルのコピーを作成できるように、指定されたテーブルへの変更がディスクにフラッシュされます。 FLUSH TABLES ... FOR EXPORT を実行すると、InnoDB によって、テーブルのスキーマディレクトリ内のテーブルスペースファイルごとに .cfg メタデータファイルが生成されます。
```
mysql> \! ls /path/to/datadir/test/
t1#p#p0.ibd  t1#p#p1.ibd  t1#p#p2.ibd t1#p#p3.ibd
t1.frm  t1#p#p0.cfg  t1#p#p1.cfg  t1#p#p2.cfg t1#p#p3.cfg
```
.cfg ファイルには、インポート操作中のスキーマ検証に使用されるメタデータが含まれています。 FLUSH TABLES ... FOR EXPORT は、個々のテーブルパーティションではなく、テーブルでのみ実行できます。
パーティション p2 およびパーティション p3 の .ibd および .cfg ファイルを、ソースインスタンスのスキーマディレクトリから宛先インスタンスのスキーマディレクトリにコピーします。
```
shell> scp t1#p#p2.ibd t1#p#p2.cfg t1#p#p3.ibd t1#p#p3.cfg destination-server:/path/to/datadir/test
```
次のステップで説明するように、共有ロックを解放する前に .ibd および .cfg ファイルをコピーする必要があります。
注記
暗号化されたテーブルスペースからパーティションをインポートする場合、InnoDB は .cfg メタデータファイルに加えて .cfp ファイルを生成します。 .cfp ファイルは、.cfg ファイルとともに宛先インスタンスにコピーする必要があります。 .cfp ファイルには、転送キーと暗号化されたテーブルスペースキーが含まれます。インポート時に、InnoDB は転送キーを使用してテーブルスペースキーを復号化します。関連情報については、セクション15.13「InnoDB 保存データ暗号化」を参照してください。
ソースインスタンスで、UNLOCK TABLES を使用して、FLUSH TABLES ... FOR EXPORT によって取得されたロックを解放します:
```
mysql> USE test;
mysql> UNLOCK TABLES;
```
宛先インスタンスで、テーブルパーティション p2 および p3 をインポートします:
```
mysql> USE test;
mysql> ALTER TABLE t1 IMPORT PARTITION p2, p3 TABLESPACE;
```
注記
サブパーティションテーブルで ALTER TABLE ... IMPORT PARTITION ... TABLESPACE を実行する場合、パーティションテーブル名とサブパーティションテーブル名の両方が許可されます。パーティション名を指定すると、そのパーティションのサブパーティションが操作に含まれます。

制限

トランスポータブルテーブルスペース機能は、file-per-table テーブルスペースに存在するテーブルでのみサポートされます。システムテーブルスペースまたは一般テーブルスペースに存在するテーブルではサポートされていません。共有テーブルスペースのテーブルは静止できません。
全文検索補助テーブルはフラッシュできないため、FLUSH TABLES ... FOR EXPORT は FULLTEXT インデックスのあるテーブルではサポートされていません。 FULLTEXT インデックスを含むテーブルをインポートした後、OPTIMIZE TABLE を実行して FULLTEXT インデックスを再構築します。または、エクスポート操作の前に FULLTEXT インデックスを削除し、宛先インスタンスにテーブルをインポートした後にインデックスを再作成します。
.cfg メタデータファイルの制限により、パーティションテーブルのインポート時にパーティションタイプまたはパーティション定義の違いについてスキーマの不一致は報告されません。カラムの差異がレポートされます。
MySQL 8.0.19 より前では、インデックスキー部分のソート順序情報は、テーブルスペースのインポート操作中に使用される .cfg メタデータファイルに格納されません。したがって、インデックスキー部分のソート順序は昇順 (デフォルト) とみなされます。その結果、インポート操作に関係するテーブルが DESC インデックスキー部分のソート順序で定義されていて、他のテーブルが意図しない順序でレコードがソートされることがあります。回避策は、影響を受けるインデックスを削除して再作成することです。インデックスキー部分のソート順序の詳細は、セクション13.1.15「CREATE INDEX ステートメント」を参照してください。
MySQL 8.0.19 で .cfg ファイル形式が更新され、インデックスキー部分のソート順情報が含まれるようになりました。前述の問題は、MySQL 8.0.19 サーバーインスタンス間のインポート操作には影響しません。

使用上の注意

ALTER TABLE ... IMPORT TABLESPACE では、テーブルをインポートするために .cfg メタデータファイルは必要ありません。ただし、.cfg ファイルなしでインポートする場合、メタデータチェックは実行されず、次のような警告が発行されます:
```
Message: InnoDB: IO Read error: (2, No such file or directory) Error opening '.\
test\t.cfg', will attempt to import without schema verification
1 row in set (0.00 sec)
```
.cfg メタデータファイルを使用しないテーブルのインポートは、スキーマの不一致が予想されない場合にのみ考慮する必要があります。 .cfg ファイルなしでインポートする機能は、メタデータにアクセスできないクラッシュリカバリシナリオで役立ちます。
Windows では、InnoDB はデータベース、テーブルスペース、およびテーブル名を内部的に小文字で格納します。 Linux や Unix などの大/小文字が区別されるオペレーティングシステムでのインポートの問題を回避するには、小文字の名前を使用してすべてのデータベース、テーブルスペースおよびテーブルを作成します。名前が小文字で作成されるようにする便利な方法は、サーバーを初期化する前に lower_case_table_names を 1 に設定することです。 (サーバーの初期化時に使用された設定とは異なる lower_case_table_names 設定でサーバーを起動することは禁止されています。)
```
[mysqld]
lower_case_table_names=1
```
サブパーティションテーブルで ALTER TABLE ... DISCARD PARTITION ... TABLESPACE および ALTER TABLE ... IMPORT PARTITION ... TABLESPACE を実行する場合、パーティションテーブル名とサブパーティションテーブル名の両方が許可されます。パーティション名を指定すると、そのパーティションのサブパーティションが操作に含まれます。

内部情報

次の情報では、テーブルのインポート手順中にエラーログに書き込まれる内部およびメッセージについて説明します。

ALTER TABLE ... DISCARD TABLESPACE が目的のインスタンスで実行された場合。

テーブルは X モードでロックされています。
テーブルスペースがテーブルから切り離されています。

FLUSH TABLES ... FOR EXPORT がソースインスタンスで実行された場合。

エクスポートのためにフラッシュされたテーブルが共有モードでロックされています。
パージコーディネータのスレッドが停止しています。
ダーティーページがディスクに同期しています。
テーブルのメタデータがバイナリの .cfg ファイルに書き込まれました。

この操作で予想されるエラーログメッセージです。

[Note] InnoDB: Sync to disk of '"test"."t1"' started.
[Note] InnoDB: Stopping purge
[Note] InnoDB: Writing table metadata to './test/t1.cfg'
[Note] InnoDB: Table '"test"."t1"' flushed to disk

UNLOCK TABLES がソースインスタンスで実行された場合。

バイナリ .cfg ファイルが削除されます。
インポートされたテーブル (または複数のテーブル) の共有ロックが解放され、パージコーディネータのスレッドが再起動されました。

この操作で予想されるエラーログメッセージです。

[Note] InnoDB: Deleting the meta-data file './test/t1.cfg'
[Note] InnoDB: Resuming purge

ALTER TABLE ... IMPORT TABLESPACE が目的のインスタンスで実行されると、インポートのアルゴリズムはインポートされたテーブルスペースごとに次の操作を実行します。

テーブルスペースの各ページに破損があるかどうかをチェックします。
各ページのスペース ID とログシーケンス番号 (LSN) が更新されます。
フラグが検証され、ヘッダーページの LSN が更新されます。
B ツリーページが更新されます。
ページの状態は、ディスクに書き込まれるようにダーティに設定されます。

この操作で予想されるエラーログメッセージです。

[Note] InnoDB: Importing tablespace for table 'test/t1' that was exported
from host 'host_name'
[Note] InnoDB: Phase I - Update all pages
[Note] InnoDB: Sync to disk
[Note] InnoDB: Sync to disk - done!
[Note] InnoDB: Phase III - Flush changes to disk
[Note] InnoDB: Phase IV - Flush complete

注記

テーブルスペースが破棄されたこと (目的のテーブルのテーブルスペースを破棄した場合) を伝える警告、および .ibd ファイルがないために統計値が計算できなかったことを伝えるメッセージも受け取る場合があります。

[Warning] InnoDB: Table "test"."t1" tablespace is set as discarded.
7f34d9a37700 InnoDB: cannot calculate statistics for table
"test"."t1" because the .ibd file is missing. For help, please refer to
http://dev.mysql.com/doc/refman/8.0/en/innodb-troubleshooting.html