14.6.1.3 Importing InnoDB Tables — MySQL 5.7

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

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

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

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

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

Переменная innodb_file_per_table должна быть включена, что по умолчанию и есть.
Размер страницы табличного пространства должен соответствовать размеру страницы экземпляра MySQL-сервера назначения. Размер страницы определяется переменной innodb_page_size, которая настраивается при инициализации экземпляра MySQL-сервера. InnoDB
Если таблица имеет внешнее ключевое отношение, 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 см. в Разделе 14.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 использует ключ передачи для расшифровки ключа табличного пространства. Дополнительную информацию см. в Разделе 14.14, «Шифрование данных 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/
db.opt  t1.frm  t1#P#p0.ibd  t1#P#p1.ibd  t1#P#p2.ibd
```
На целевом экземпляре удалите табличную систему для разграниченной таблицы. (Перед операцией импорта необходимо удалить табличную систему получающей таблицы.)
```
mysql> ALTER TABLE t1 DISCARD TABLESPACE;
```
Три файла табличной системы .ibd разграниченной таблицы удаляются из каталога /datadir/test, оставляя следующие файлы:
```
mysql> \! ls /path/to/datadir/test/
db.opt  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/
db.opt 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 из каталога схемы исходного экземпляра в каталог схемы целевого экземпляра. Например:
```
$>scp /path/to/datadir/test/t1*.{ibd,cfg} destination-server:/path/to/datadir/test
```
Файлы .ibd и .cfg необходимо скопировать перед освобождением общих блокировок, как описано в следующем шаге.

Примечание

Если вы импортируете таблицу из зашифрованной табличной системы, InnoDB генерирует файлы .cfp дополнительно к файлам метаданных .cfg. Файлы .cfp необходимо скопировать на целевой экземпляр вместе с файлами .cfg. Файлы .cfp содержат ключ передачи и ключ зашифрованной табличной системы. При импорте InnoDB использует ключ передачи для расшифровки ключа табличной системы. Для получения дополнительной информации см. Раздел 14.14, «Шифрование данных 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/
db.opt  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;
```
Файлы табличной системы .ibd для двух удаленных разделов удаляются из каталога /datadir/test на целевом экземпляре, оставляя следующие файлы:
```
mysql> \! ls /path/to/datadir/test/
db.opt  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/
db.opt  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 может быть выполнена только для таблицы, а не для отдельных разделов таблицы.
Скопируйте файлы .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 использует ключ передачи для расшифровки ключа табличной системы. Для получения дополнительной информации см. Раздел 14.14, «Шифрование данных 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 несоответствия схемы не сообщаются для различий в типе раздела или определении раздела при импорте разграниченной таблицы. Различия в столбцах сообщаются.

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

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 в раздел [mysqld] вашего файла my.cnf или my.ini перед созданием баз данных, табличных пространств или таблиц:
```
[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/5.7/en/innodb-troubleshooting.html