17.6.1.3 Importing InnoDB Tables — MySQL 9.2

17.6.1.3 Импорт таблиц InnoDB

В этом разделе описано, как импортировать таблицы с помощью функции Переносимые табличные пространства, которая позволяет импортировать таблицы, разнесённые таблицы или отдельные разделы таблиц, находящиеся в файловых табличных пространствах. Существует много причин, по которым вам может потребоваться импорт таблиц:

Чтобы выполнить отчёты на экземпляре MySQL сервера, не являющимся производственным, чтобы избежать дополнительной нагрузки на производственный сервер.
Чтобы скопировать данные на новый сервер-репликант.
Чтобы восстановить таблицу из файла резервной копии табличного пространства.
Как более быстрый способ перемещения данных, чем импорт файла дампов, который требует повторной вставки данных и перестроения индексов.
Чтобы переместить данные на сервер со средствами хранения, которые лучше подходят для ваших требований к хранению. Например, вы можете переместить загруженные таблицы на устройство SSD или переместить большие таблицы на устройство HDD с большой ёмкостью.

Функция Переносимые табличные пространства описана в следующих разделах данного раздела:

Предварительные условия

Переменная innodb_file_per_table должна быть включена, что по умолчанию так и есть.
Размер страницы табличного пространства должен соответствовать размеру страницы целевого экземпляра MySQL сервера. InnoDB размер страницы определяется переменной innodb_page_size, которая настраивается при инициализации экземпляра MySQL сервера.
Если таблица имеет внешнее ключевое отношение, foreign_key_checks необходимо отключить перед выполнением DISCARD TABLESPACE. Также следует экспортировать все таблицы, связанные с внешними ключами, в один и тот же логический момент времени, так как ALTER TABLE ... IMPORT TABLESPACE не применяет ограничения внешних ключей к импортированным данным. Для этого необходимо остановить обновление связанных таблиц, подтвердить все транзакции, получить совместные блокировки на таблицах и выполнить операции экспорта.
При импорте таблицы с другого экземпляра MySQL сервера оба экземпляра MySQL сервера должны иметь статус «Доступно» (GA) и быть одной версии. В противном случае таблица должна быть создана на том же экземпляре MySQL сервера, в который она импортируется.
Если таблица была создана во внешнем каталоге путём указания условия DATA DIRECTORY в операторе CREATE TABLE, таблица, которую вы заменяете на целевом экземпляре, должна быть определена с тем же условием DATA DIRECTORY. Если условия не совпадают, выводится ошибка несоответствия схемы. Чтобы определить, было ли исходная таблица определена с условием DATA DIRECTORY, используйте SHOW CREATE TABLE для просмотра определения таблицы. Сведения об использовании условия DATA DIRECTORY см. в разделе 17.6.1.2 «Создание таблиц во внешних средах».
Если опция ROW_FORMAT не определена явно в определении таблицы или используется ROW_FORMAT=DEFAULT, значение innodb_default_row_format должно быть одинаковым на исходном и целевом экземплярах. В противном случае, при попытке операции импорта выводится ошибка несоответствия схемы. Используйте SHOW CREATE TABLE для проверки определения таблицы. Используйте SHOW VARIABLES для проверки значения innodb_default_row_format. Дополнительную информацию см. в определении формата строк таблицы.

Импорт таблиц

В этом примере показано, как импортировать обычную неразнесённую таблицу, находящуюся в файловом табличном пространстве.

На целевом экземпляре создайте таблицу с таким же определением, что и таблица, которую вы хотите импортировать. (Вы можете получить определение таблицы, используя синтаксис 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 содержит метаданные, используемые для проверки схемы при выполнении операции импорта.

Примечание

Соединение, выполняющее FLUSH TABLES ... FOR EXPORT, должно оставаться открытым во время выполнения операции; в противном случае файл .cfg удаляется при освобождении блокировок по закрытии соединения.
Скопируйте файл .ibd и файл метаданных .cfg с исходного экземпляра на целевой. Например:
```
$> scp /path/to/datadir/test/t1.{ibd,cfg} destination-server:/path/to/datadir/test
```
Файл .ibd и файл .cfg необходимо скопировать до освобождения совместных блокировок, как описано в следующем шаге.

Примечание

Если вы импортируете таблицу из зашифрованного табличного пространства, InnoDB генерирует файл .cfp в дополнение к файлу метаданных .cfg. Файл .cfp необходимо скопировать на целевой экземпляр вместе с файлом .cfg. Файл .cfp содержит ключ передачи и зашифрованный ключ табличного пространства. При импорте InnoDB использует ключ передачи для расшифровки ключа табличного пространства. Дополнительную информацию см. в разделе 17.13 «Шифрование данных InnoDB в состоянии покоя».
На исходном экземпляре используйте UNLOCK TABLES для освобождения блокировок, полученных оператором FLUSH TABLES ... FOR EXPORT:
```
mysql> USE test;
mysql> UNLOCK TABLES;
```
Операция UNLOCK TABLES также удаляет файл .cfg.
На целевом экземпляре импортируйте табличное пространство:
```
mysql> USE test;
mysql> ALTER TABLE t1 IMPORT TABLESPACE;
```

END_OF_DOCUMENT_MARKER ```

Импорт разбиений таблицы

Этот пример демонстрирует, как импортировать разбиение таблицы, где каждое разбиение таблицы хранится в файловой табличной структуре.

На целевом экземпляре создайте разбиение таблицы с тем же определением, что и у разбиения таблицы, которое вы хотите импортировать. (Вы можете получить определение таблицы, используя синтаксис SHOW CREATE TABLE.) Если определение таблицы не совпадает, при попытке импорта будет сообщено об ошибке несоответствия схемы.
```
mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 3;
```
В каталоге /datadir/test находится файл табличной структуры .ibd для каждого из трёх разбиений.
```
mysql> \! ls /path/to/datadir/test/
t1#p#p0.ibd  t1#p#p1.ibd  t1#p#p2.ibd
```
На целевом экземпляре удалите табличную структуру для разбиения таблицы. (Перед операцией импорта необходимо удалить табличную структуру целевой таблицы.)
```
mysql> ALTER TABLE t1 DISCARD TABLESPACE;
```
Три файла табличной структуры .ibd разбиения таблицы удаляются из каталога /datadir/test.
На исходном экземпляре запустите 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#p0.cfg  t1#p#p1.cfg  t1#p#p2.cfg
```
Файлы .cfg содержат метаданные, используемые для проверки схемы при импорте табличной структуры. FLUSH TABLES ... FOR EXPORT может быть выполнена только для таблицы, а не для отдельных разбиений таблицы.
Скопируйте файлы .ibd и .cfg из каталога схемы исходного экземпляра в каталог схемы целевого экземпляра. Например:
```
$>scp /path/to/datadir/test/t1*.{ibd,cfg} destination-server:/path/to/datadir/test
```
Файлы .ibd и .cfg должны быть скопированы перед разблокировкой общих блокировок, как описано в следующем шаге.

Примечание

Если вы импортируете таблицу из зашифрованной табличной структуры, InnoDB генерирует файлы .cfp в дополнение к файлам метаданных .cfg. Файлы .cfp должны быть скопированы на целевой экземпляр вместе с файлами .cfg. Файлы .cfp содержат ключ переноса и ключ зашифрованной табличной структуры. При импорте InnoDB использует ключ переноса для расшифровки ключа табличной структуры. Для получения дополнительной информации см. Раздел 17.13, «Шифрование данных InnoDB при хранении на диске».
На исходном экземпляре используйте UNLOCK TABLES для разблокировки блокировок, полученных FLUSH TABLES ... FOR EXPORT:
```
mysql> USE test;
mysql> UNLOCK TABLES;
```
На целевом экземпляре импортируйте табличную структуру разбиения таблицы:
```
mysql> USE test;
mysql> ALTER TABLE t1 IMPORT TABLESPACE;
```

Импорт разбиений таблицы

Этот пример демонстрирует, как импортировать отдельные разбиения таблицы, где каждое разбиение хранится в файле табличной структуры.

В следующем примере импортируются два разбиения (p2 и p3) четырёхразбиения таблицы.

На целевом экземпляре создайте разбиение таблицы с тем же определением, что и у разбиения таблицы, из которого вы хотите импортировать разбиения. (Вы можете получить определение таблицы, используя синтаксис SHOW CREATE TABLE.) Если определение таблицы не совпадает, при попытке импорта будет сообщено об ошибке несоответствия схемы.
```
mysql> USE test;
mysql> CREATE TABLE t1 (i int) ENGINE = InnoDB PARTITION BY KEY (i) PARTITIONS 4;
```
В каталоге /datadir/test находятся файлы табличной структуры .ibd для каждого из четырёх разбиений.
```
mysql> \! ls /path/to/datadir/test/
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;
```
Файлы табличной структуры .ibd для двух удалённых разбиений удаляются из каталога /datadir/test на целевом экземпляре, оставляя следующие файлы:
```
mysql> \! ls /path/to/datadir/test/
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#p#p0.cfg  t1#p#p1.cfg  t1#p#p2.cfg t1#p#p3.cfg
```
Файлы .cfg содержат метаданные, используемые для проверки схемы во время импорта. FLUSH TABLES ... FOR EXPORT может быть выполнена только для таблицы, а не для отдельных разбиений таблицы.
Скопируйте файлы .ibd и .cfg для разбиения p2 и разбиения p3 из каталога схемы исходного экземпляра в каталог схемы целевого экземпляра.
```
$> 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 генерирует файлы .cfp в дополнение к файлам метаданных .cfg. Файлы .cfp должны быть скопированы на целевой экземпляр вместе с файлами .cfg. Файлы .cfp содержат ключ переноса и ключ зашифрованной табличной структуры. При импорте InnoDB использует ключ переноса для расшифровки ключа табличной структуры. Для получения дополнительной информации см. Раздел 17.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 для подразделённых таблиц разрешены имена как разбиений, так и подразбиений. Если указано имя разбиения, в операцию включаются подразбиения этого разбиения.

Ограничения

Функция Переносимые табличные структуры поддерживается только для таблиц, находящихся в файловой табличной структуре. Она не поддерживается для таблиц, находящихся в системной табличной структуре или общих табличных структурах. Таблицы в общих табличных структурах не могут быть остановлены.
FLUSH TABLES ... FOR EXPORT не поддерживается для таблиц с индексом FULLTEXT, так как вспомогательные таблицы полнотекстового поиска не могут быть остановлены. После импорта таблицы с индексом FULLTEXT запустите OPTIMIZE TABLE, чтобы перестроить индексы FULLTEXT. В качестве альтернативы удалите индексы FULLTEXT перед операцией экспорта и создайте их заново после импорта таблицы на целевой экземпляр.
Из-за ограничения файла метаданных .cfg несоответствия схемы не сообщаются для различий в типе разбиения или определении разбиения при импорте разбиения таблицы. Различия в столбцах сообщаются.

END_OF_DOCUMENT_MARKER

Примечания по использованию

За исключением таблиц, содержащих мгновенно добавленные или удаленные столбцы, для импорта таблицы не требуется файл метаданных. Однако проверки метаданных не выполняются при импорте без файла метаданных, и выводится предупреждение, подобное следующему:
```
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)
```
Импорт таблицы без файла метаданных следует рассматривать только в том случае, если не ожидается несоответствий схем и таблица не содержит мгновенно добавленных или удаленных столбцов. Возможность импорта без файла метаданных может быть полезна в сценариях восстановления после сбоя, когда метаданные недоступны.

Попытка импорта таблицы со столбцами, добавленными или удаленными с помощью ALGORITHM=INSTANT без использования файла метаданных может привести к неопределенному поведению.
В 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 на целевом экземпляре алгоритм импорта выполняет следующие операции для каждого импортируемого табличного пространства:

Каждая страница табличного пространства проверяется на наличие повреждений.
Идентификатор пространства и номера последовательностей логов (LSNs) на каждой странице обновляются.
Флаги проверяются и 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/en/innodb-troubleshooting.html