12.6 Dump Loading Utility — MySQL Shell 9.2

12.6 Утилита загрузки дампов

Утилита загрузки дампов MySQL Shell util.loadDump() поддерживает импорт схем или таблиц, созданных с помощью утилиты дампов MySQL Shell (Раздел 12.5, «Утилита дампов экземпляра, утилита дампов схемы и утилита дампов таблиц»), в базу данных HeatWave Service или экземпляр MySQL Server. Утилита загрузки дампов обеспечивает потоковую передачу данных из удаленного хранилища, параллельную загрузку таблиц или фрагментов таблиц, отслеживание состояния выполнения, возможность возобновления и сброса, а также возможность одновременной загрузки во время создания дампа. Для наилучшей функциональности всегда используйте последнюю доступную версию утилит дампов и загрузки дампов MySQL Shell.

О утилите

Для импорта в систему баз данных HeatWave Service MySQL Shell должен быть установлен на экземпляре Oracle Cloud Infrastructure Compute, имеющем доступ к системе баз данных HeatWave Service. Если файлы дампов находятся в ведре Oracle Cloud Infrastructure Object Storage, вы можете получить доступ к ведру Object Storage с экземпляра Compute. Если файлы дампов находятся на локальной системе, вам необходимо перенести их на экземпляр Oracle Cloud Infrastructure Compute с помощью утилиты копирования, подходящей для вашей операционной системы. Убедитесь, что дамп был создан с параметром ocimds, установленным в значение true в утилите дампов экземпляра или утилите дампов схемы MySQL Shell для совместимости с HeatWave Service. Утилита дампов таблиц MySQL Shell не использует этот параметр.

Для вывода, созданного утилитой дампов экземпляра или утилитой дампов схемы, утилита загрузки дампов MySQL Shell использует файлы DDL и табличные файлы .tsv данных для настройки экземпляра сервера или схемы в целевом экземпляре MySQL, а затем загружает данные. Можно использовать дампы, содержащие только файлы DDL или только файлы данных, для выполнения этих задач по отдельности. Утилита загрузки дампов также позволяет применять файлы DDL и файлы данных из обычного дампа, содержащего оба типа файлов, по отдельности.

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

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

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

Параметр waitDumpTimeout позволяет применять дамп, который ещё создаётся. Таблицы загружаются по мере их появления, и утилита ожидает указанное количество секунд после того, как новые данные перестанут поступать в местоположение дампа. Когда таймаут истекает, утилита предполагает, что дамп завершён, и останавливает импорт.

Состояние выполнения импорта сохраняется в файле состояния выполнения, который записывает успешно завершенные шаги и шаги, которые были прерваны или завершились ошибкой. По умолчанию, файл состояния выполнения называется load-progress.server_uuid.json и создаётся в каталоге дампа, но вы можете выбрать другое имя и расположение. Утилита загрузки дампов ссылается на файл состояния выполнения при возобновлении или повторной попытке импорта дампа и пропускает завершенные шаги. Дублирование автоматически обрабатывается для таблиц, которые были частично загружены. Если вы прерываете выполняемый дамп, используя Ctrl + C, при первом использовании этой комбинации клавиш утилита не запускает новых задач, но существующие задачи продолжаются. Нажатие Ctrl + C снова останавливает существующие задачи, что приводит к сообщениям об ошибках. В любом случае, утилита всё ещё может возобновить импорт с места остановки.

Вы можете выбрать сброс состояния выполнения и повторный запуск импорта дампа с начала, но в этом случае утилита не пропускает объекты, которые уже были созданы, и не управляет дублированием. Если вы это сделаете, чтобы гарантировать правильный импорт, вы должны вручную удалить из целевого экземпляра MySQL все ранее загруженные объекты из этого дампа, включая схемы, таблицы, пользователей, представления, триггеры, процедуры и события. В противном случае импорт завершится ошибкой, если объект в файлах дампов уже существует в целевом экземпляре MySQL. При надлежащей осторожности вы можете использовать параметр ignoreExistingObjects, чтобы утилита сообщала о дублирующихся объектах, но пропускала их и продолжала импорт. Обратите внимание, что утилита не проверяет, отличаются ли содержимое объекта в целевом экземпляре MySQL и в файлах дампов, поэтому возможен импорт некорректных или неверных данных.

Важно

Не изменяйте данные в файлах дампов между остановкой и возобновлением дампа. Возобновление дампа после изменения данных имеет неопределённое поведение и может привести к несоответствию и потере данных. Если вам нужно изменить данные после частичной загрузки дампа, вручную удалите все объекты, созданные во время частичного импорта (как указано в файле состояния выполнения), затем запустите утилиту загрузки дампов с параметром resetProgress, чтобы начать сначала.

Если вам нужно изменить какие-либо данные в файлах данных дампа перед импортом в целевой экземпляр MySQL, вы можете сделать это, объединив утилиту параллельного импорта таблиц MySQL Shell util.importTable() с утилитой загрузки дампов. Для этого сначала используйте утилиту загрузки дампов для загрузки только DDL для выбранной таблицы, чтобы создать таблицу на целевом сервере. Затем используйте утилиту параллельного импорта таблиц для захвата и преобразования данных из выходных файлов для таблицы и импортируйте их в целевую таблицу. Повторите этот процесс по мере необходимости для других таблиц, где вы хотите изменить данные. Наконец, используйте утилиту загрузки дампов для загрузки DDL и данных для любых оставшихся таблиц, которые вы не хотите изменять, исключая таблицы, которые вы изменили. Описание процедуры см. в разделе Изменение данных дампов.

Таблицы в дампе загружаются параллельно, используя количество потоков, заданное параметром threads, которое по умолчанию равно 4. Если данные таблицы были разделены на фрагменты при создании дампа, для таблицы можно использовать несколько потоков, в противном случае каждый поток загружает по одной таблице за раз. Утилита загрузки дампов планирует импорт данных между потоками, чтобы максимизировать параллелизм. Для извлечения содержимого файлов используется пул фоновых потоков. Если файлы дампов были сжаты утилитами дампов MySQL Shell, утилита загрузки дампов обрабатывает их разархивирование.

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

Для дополнительного повышения производительности загрузки данных вы можете отключить журнал пересоздания в целевом экземпляре MySQL во время импорта. Обратите внимание, что это следует выполнять только на новом экземпляре MySQL Server (не на рабочей системе), и эта функция недоступна в MySQL DB System. Более подробную информацию см. .

Требования и ограничения

Для целевого экземпляра MySQL, в который загружается дамп, требуется MySQL 5.7 или более поздней версии.
Утилита загрузки дампов MySQL Shell из версий MySQL Shell, предшествующих 8.0.27, не может загружать дампы, созданные с помощью утилит дампов в MySQL Shell 8.0.27 или более поздних версий. Это связано с тем, что начиная с MySQL Shell 8.0.27, в метаданных дампа содержится информация о функциях, использованных при создании дампа. Этот список функций несовместим с предыдущими версиями, но поддерживает обратную совместимость при добавлении новых функций в будущих выпусках. Для достижения наилучшей функциональности всегда используйте последнюю доступную версию утилит дампов и загрузки дампов MySQL Shell.
Утилита загрузки дампов использует оператор LOAD DATA LOCAL INFILE, поэтому глобальная настройка системной переменной в целевом экземпляре MySQL должна быть ON на период импорта. По умолчанию эта системная переменная установлена в значение ON в стандартной конфигурации HeatWave Service DB System.
Оператор LOAD DATA LOCAL INFILE использует нестрогую интерпретацию данных, которая преобразует ошибки в предупреждения и продолжает операцию загрузки. Этот процесс может включать присвоение значений по умолчанию и неявных значений по умолчанию к полям, а также преобразование недопустимых значений в ближайшее допустимое значение для типа данных столбца. Подробности о работе оператора см. в .
В целевом экземпляре MySQL утилита загрузки дампов проверяет, установлена ли системная переменная в значение ON, и если это так, возвращает ошибку, если в файлах дампа есть таблица без первичного ключа. По умолчанию эта системная переменная установлена в значение OFF в стандартной конфигурации HeatWave Service DB System.
Утилита загрузки дампов не автоматически применяет набор GTID из исходного экземпляра MySQL в целевой экземпляр MySQL. Набор GTID включен в метаданные дампа из утилиты дампов экземпляра MySQL Shell, утилиты дампов схемы или утилиты дампов таблиц в качестве поля gtidExecuted в файле дампа @.json. Для применения этих GTID в целевом экземпляре MySQL для использования с репликацией используйте параметр updateGtidSet или импортируйте их вручную, в зависимости от версии целевого экземпляра MySQL и версии MySQL Shell. Это также поддерживается в экземплярах HeatWave Service DB System. Подробности см. в описании параметра updateGtidSet.

Использование PAR для загрузки файлов дампов

MySQL Shell поддерживает загрузку файлов дампов из ведра Object Storage с использованием предварительно аутентифицированного запроса (PAR). PAR позволяют пользователям получать доступ к ведру или объекту без предоставления собственных учетных данных.

Важно

Перед использованием этого метода доступа оцените бизнес-требования и последствия для безопасности предварительно аутентифицированного доступа к ведру или объектам в ведре. PAR предоставляет любому, у кого есть PAR, доступ к целевым объектам, указанным в запросе. Тщательно управляйте распределением PAR.

MySQL Shell поддерживает использование PAR с доступом для чтения (PAR для чтения объектов) для всех объектов в ведре или объектов в ведре со специфическим префиксом. Сведения о создании PAR ведра и префикса PAR см. в . При использовании PAR ведра или префикса PAR утилите загрузки дампов требуется локальный файл состояния прогресса. Содержание файла находится в формате JSON, поэтому подходящим типом файла является текстовый файл с расширением .json (например, progress.json). Следующий пример демонстрирует синтаксис загрузки файлов дампов с использованием PAR, созданного для всех объектов в ведре:

JS> util.loadDump("BucketPARURL", {progressFile: "progress.json"})

Тот же синтаксис используется для загрузки объектов в ведре со специфическим префиксом, но в этом случае URL PAR включает префикс:

shell-js> util.loadDump("PrefixPARURL", progressFile: "progress.json"})

Запуск утилиты

Утилита загрузки дампов использует глобальную сессию MySQL Shell для получения данных подключения к целевому экземпляру MySQL, в который должен быть импортирован дамп. Вы должны открыть глобальную сессию (которая может иметь соединение с протоколом X или классическое соединение MySQL) перед запуском утилиты. Утилита открывает свои собственные сессии для каждого потока, копируя такие параметры, как сжатие соединения и параметры SSL из глобальной сессии, и не использует глобальную сессию далее.

В API MySQL Shell утилита загрузки дампов является функцией глобального объекта util и имеет следующий вид:

util.loadDump(url[, options])

options — это словарь параметров, который можно опустить, если он пуст. Параметры перечислены в последующих разделах этой темы.

Если вы импортируете дамп, который находится в файловой системе экземпляра Oracle Cloud Infrastructure Compute, где вы запускаете утилиту, url — это строка, определяющая путь к локальному каталогу, содержащему файлы дампа. Вы можете префиксровать путь к локальному каталогу схемой file://. В этом примере в режиме JavaScript MySQL Shell выполняется пробный запуск, чтобы проверить, не возникнет ли проблем при загрузке файлов дампа из локального каталога в подключенный экземпляр MySQL:

shell-js> util.loadDump("/mnt/data/worlddump", {dryRun: true})

Если вы импортируете дамп из ведра Oracle Cloud Infrastructure Object Storage, url — это префикс пути, по которому файлы дампа находятся в ведре, который был назначен параметром outputUrl при создании дампа. Используйте параметр osBucketName для указания имени ведра Object Storage и параметр osNamespace для определения пространства имен ведра. В этом примере в режиме JavaScript MySQL Shell дамп с префиксом worlddump загружается из ведра Object Storage в подключенный экземпляр HeatWave Service DB System с использованием 8 потоков:

shell-js> util.loadDump("worlddump", {
          threads: 8, osBucketName: "hanna-bucket", osNamespace: "idx28w1ckztq"})

Пространство имен ведра Object Storage отображается на вкладке «Информация о ведре» страницы подробностей ведра в консоли Oracle Cloud Infrastructure или может быть получено с помощью командной строки Oracle Cloud Infrastructure. Подключение к ведру Object Storage устанавливается с использованием профиля по умолчанию в файле конфигурации Oracle Cloud Infrastructure CLI по умолчанию или с помощью альтернативных данных, которые вы указываете с помощью параметров ociConfigFile и ociProfile. Инструкции по настройке файла конфигурации CLI см. в Файл конфигурации SDK и CLI.

Параметры управления загрузкой

dryRun: [ true | false ]

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

waitDumpTimeout: number

Установка этого параметра со значением больше 0 активирует одновременную загрузку дампа во время его создания. Значение — таймаут (в секундах), в течение которого утилита ждёт новых данных после обработки всех загруженных фрагментов данных из местоположения дампа. Это позволяет утилите импортировать дамп во время его создания. Данные обрабатываются по мере их появления, и импорт останавливается, когда таймаут истекает без появления новых данных в месте расположения дампа. Значение по умолчанию, 0, означает, что утилита помечает дамп как завершённый, когда все загруженные фрагменты данных обработаны, и не ждёт дополнительных данных. При значении по умолчанию одновременная загрузка отключена.

schema: "string"

Целевая схема, в которую должен быть загружен дамп, созданный средствами дампинга MySQL Shell.

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

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

threads: number

Количество параллельных потоков для загрузки фрагментов данных на целевой MySQL-сервер. Каждый поток имеет собственное соединение с MySQL-сервером. По умолчанию значение 4. Если дамп был создан с включённым фрагментированием (что является по умолчанию), утилита может использовать несколько потоков для загрузки данных для таблицы; в противном случае поток используется только для одной таблицы.

backgroundThreads: number

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

progressFile: "string"

Указывает путь к локальному файлу состояния процесса для отслеживания прогресса загрузки. Допускаются и другие значения в зависимости от типа операции загрузки:

При загрузке дампа из локального хранилища:

Параметр progressFile может быть опущен. В этом случае файл состояния процесса с именем load-progress-server-uuid.json автоматически создаётся в каталоге дампа.
Параметр progressFile может быть установлен в пустую строку для отключения отслеживания состояния процесса, что означает, что утилита загрузки дампа не может возобновить частично завершённый импорт.

При загрузке дампа из хранилища OCI Object Storage с помощью предварительно авторизованного запроса (PAR), параметр progressFile является обязательным.

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

Если указан локальный файл состояния процесса или допустимый запись PAR, но файл состояния процесса не существует, он будет создан.

showProgress: [ true | false ]

Отображение (true) или скрытие (false) информации о прогрессе импорта. По умолчанию установлено значение true, если stdout является терминалом (tty), например, когда MySQL Shell находится в интерактивном режиме, и false в противном случае. Информация о прогрессе включает количество активных потоков и их действия, количество загруженных данных, процент завершения и скорость пропускной способности. Когда информация о прогрессе не отображается, состояние прогресса всё равно записывается в файле состояния процесса утилиты загрузки дампа.

resetProgress: [ true | false ]

Установка этого параметра в значение true сбрасывает состояние прогресса и запускает импорт заново с начала. По умолчанию установлено значение false. Обратите внимание, что при использовании этого параметра утилита загрузки дампа не пропускает объекты, которые уже были созданы, и не управляет дублированием. Если вы хотите использовать этот параметр для обеспечения правильного импорта, вы должны предварительно вручную удалить из целевого MySQL-сервера все ранее загруженные объекты, включая схемы, таблицы, пользователей, представления, триггеры, процедуры и события из этого дампа. В противном случае импорт завершится ошибкой, если объект в файлах дампа уже существует на целевом MySQL-сервере. При надлежащей осторожности можно использовать параметр ignoreExistingObjects, чтобы утилита сообщала о дублирующих объектах, но пропускала их и продолжала импорт.

skipBinlog: [ true | false ]

Пропускает двоичный журналик на целевом MySQL-сервере для сессий, используемых утилитой во время импорта, путём выполнения инструкции SET sql_log_bin=0. По умолчанию установлено значение false, поэтому двоичный журналик активен по умолчанию. Для HeatWave Service DB System этот параметр не используется, и импорт завершится ошибкой, если вы попытаетесь установить его в значение true. Для других MySQL-серверов всегда устанавливайте skipBinlog в значение true, если вы применяете набор GTID из исходного MySQL-сервера на целевой MySQL-сервер, либо с использованием параметра updateGtidSet, либо вручную. Если на целевом MySQL-сервере используются GTID (gtid_mode=ON), установка этого параметра в значение true предотвращает генерацию и присвоение новых GTID во время импорта, чтобы можно было использовать исходный набор GTID с исходного сервера. Пользовательская учётная запись должна иметь необходимые права для установки системной переменной sql_log_bin.

ignoreVersion: [ true | false ]

Импортирует дамп даже если номер основной версии MySQL-сервера, с которого были загружены данные, не является последовательным с номером основной версии MySQL-сервера, на который данные будут загружены. По умолчанию установлено значение false, что означает, что выдаётся ошибка, и импорт не продолжается, если номер основной версии не является последовательным. При установке этого параметра в значение true выдаётся предупреждение, и импорт продолжается. Обратите внимание, что импорт будет успешным только в том случае, если схемы в файлах дампа не имеют проблем совместимости с новой основной версией.

Примечание

ignoreVersion не требуется при копировании между последовательными основными версиями, такими как 8.0 на 8.1.

Перед попыткой импорта с помощью параметра ignoreVersion используйте утилиту проверки обновления MySQL Shell checkForServerUpgrade() для проверки схем на исходном MySQL-сервере. Исправьте любые проблемы совместимости, выявленные утилитой, перед созданием дампов схем и их импортом на целевой MySQL-сервер.

dropExistingObjects: [ true | false ]

Значение по умолчанию — false.

Импортирует дамп, даже если он содержит учётные записи пользователей или объекты DDL, которые уже существуют в целевой базе данных. Если этот параметр установлен в значение false, любые существующие объекты приводят к ошибке. Установка его в значение true удаляет существующие учётные записи пользователей и объекты перед их созданием.

Примечание

Схемы не удаляются.

Примечание

Невозможно включить параметр dropExistingObjects, если включен параметр ignoreExistingObjects или если отключён параметр loadDdl.

ignoreExistingObjects: [ true | false ]

Импортирует дамп, даже если он содержит объекты, которые уже существуют в целевой схеме MySQL-сервера. По умолчанию установлено значение false, означающее, что выдаётся ошибка, и импорт останавливается при обнаружении дублирующего объекта, если импорт не возобновляется из предыдущей попытки с использованием файла состояния процесса, в этом случае проверка пропускается. Когда этот параметр установлен в значение true, дублирующие объекты сообщаются, но ошибка не генерируется, и импорт продолжается. Этот параметр следует использовать с осторожностью, так как утилита не проверяет, отличаются ли содержимое объекта на целевом MySQL-сервере и в файлах дампа, поэтому возможен импорт некорректных или недействительных данных. Альтернативная стратегия — использовать параметр excludeTables для исключения таблиц, которые вы уже загрузили, убедившись, что объект в файлах дампа идентичен импортированному объекту на целевом MySQL-сервере. Самый безопасный вариант — удалить дублирующие объекты из целевого MySQL-сервера перед перезапуском импорта.

Этот параметр также позволяет импортировать дамп, созданный без использования параметра ocimds, в экземпляр HeatWave Service.

Примечание

Невозможно включить параметр ignoreExistingObjects, если включён параметр dropExistingObjects.

handleGrantErrors: abort|drop_account|ignore

Действие, выполняемое при возникновении ошибок, связанных с ошибками GRANT или REVOKE.

abort (по умолчанию): останавливает процесс загрузки и отображает ошибку.
drop_account: удаляет учётную запись и продолжает процесс загрузки.
ignore: игнорирует ошибку и продолжает процесс загрузки.

characterSet: "string"

Набор символов, который будет использоваться для импорта в целевой экземпляр MySQL, например, в опции CHARACTER SET оператора. По умолчанию используется набор символов из метаданных дампа, который использовался при создании дампа с помощью утилиты instance dump, schema dump или table dump MySQL Shell, которые по умолчанию используют utf8mb4. Набор символов должен быть разрешён переменной системы character_set_client и поддерживаться экземпляром MySQL.

maxBytesPerTransaction: number

Максимальное количество байтов, которые могут быть загружены из файла данных в одном операторе. Если размер файла данных превышает значение maxBytesPerTransaction, данные из файла загружаются в несколько операторов частями, не превышающими значение maxBytesPerTransaction.

Можно использовать суффиксы единиц измерения k для килобайт, M для мегабайт и G для гигабайт. Минимальное значение составляет 4096 байт. Если указано меньшее значение, подразумевается минимальное значение 4096 байт. Если опция maxBytesPerTransaction не задана, значение bytesPerChunk, используемое для дампа данных, используется в качестве значения по умолчанию для файлов, размер которых больше 1,5 * значения bytesPerChunk. Если опция maxBytesPerTransaction не задана, а размер файла данных меньше 1,5 * значения bytesPerChunk, данные загружаются в одном операторе.

Если файл данных содержит строку, размер которой больше, чем задано в параметре maxBytesPerTransaction, данные строки загружаются в одном операторе. Для первой строки, размер которой превышает значение параметра maxBytesPerTransaction, выдаётся предупреждение.

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

Предполагаемое использование этой опции — загрузка данных частями меньшего размера, когда размер файла данных превышает лимиты целевого сервера, такие как лимиты, определённые настройками сервера или . Например, если при загрузке данных возникает ошибка "Ошибка MySQL 1197 (HY000): Для многооперационной транзакции требуется более 'max_binlog_cache_size' байтов памяти", задайте параметр maxBytesPerTransaction значением, меньшим или равным значению параметра целевого экземпляра сервера.

sessionInitSql: list of strings

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

sessionInitSQL: ["SET SESSION sql_log_bin=0;", "SET SESSION innodb_ddl_threads=8,"]

Если при выполнении SQL-операторов произойдёт ошибка, импорт остановится и будет возвращено сообщение об ошибке.

Параметры для загрузки содержимого

loadIndexes: [ true | false ]

Создать (true) или не создавать (false) вторичные индексы для таблиц. По умолчанию используется true. Если этот параметр установлен в false, вторичные индексы не создаются во время импорта, и их необходимо создать позднее. Это может быть полезно, если вы загружаете файлы DDL и файлы данных отдельно и хотите внести изменения в структуру таблицы после загрузки файлов DDL. После этого вы можете создать вторичные индексы, снова запустив утилиту загрузки дампов с параметром loadIndexes, установленным в значение true, и параметром deferTableIndexes, установленным в значение all.

MySQL Shell использует параллельное создание индексов MySQL Server. Ранее утилиты загрузки дампов добавляли индексы последовательно, по одному за раз. Начиная с этого выпуска, все индексы в таблице добавляются одновременно.

См. для ограничений и конфигурации.

deferTableIndexes: [ off | fulltext | all ]

Отложить создание вторичных индексов до загрузки данных таблицы. Это может сократить время загрузки. off означает, что все индексы создаются во время загрузки таблицы. Значение по умолчанию fulltext откладывает создание только полнотекстовых индексов. all откладывает создание всех вторичных индексов и создает только первичные индексы во время загрузки таблицы, а также индексы, определенные на столбцах с автоинкрементируемыми значениями.

analyzeTables: [ off | on | histogram ]

Выполнить ANALYZE TABLE для таблиц после их загрузки. on анализирует все таблицы, а histogram анализирует только таблицы, для которых информация об истории (гистограмме) хранится в дампе. По умолчанию используется off. Вы можете запустить утилиту загрузки дампов с этим параметром, чтобы проанализировать таблицы, даже если данные уже были загружены.

checksum: [true|false]

Если включено, утилита loadDump проверяет данные контрольной суммы, сгенерированные утилитой дампа, после загрузки соответствующих данных. Проверка ограничена данными, которые были скопированы в дамп, игнорируя сгенерированные данные, такие как невидимые первичные ключи, добавленные утилитой loadDump.

Возвращаются ошибки, если контрольная сумма не совпадает или если таблица отсутствует и не может быть проверена.

Если checksum: true, но данные не были загружены (из-за loadData: false или отсутствия данных в дампе), утилита проверяет информацию о контрольной сумме дампа относительно текущего содержимого затронутых таблиц.

Если таблица не существует, для каждой отсутствующей таблицы отображается сообщение об ошибке.
Если checksum: true и dryRun: true, контрольная сумма не проверяется. Отображается сообщение, что проверка не проводилась.

showMetadata: [ true | false ]

Выводит набор GTID и имя и позицию файла двоичного журнала из исходной инстанции, взятые из метаданных дампов, включенных в дампы, созданные утилитой instance dump, schema dump или table dump MySQL Shell. Метаданные выводятся в формате YAML.

Набор GTID всегда включён в дамп в качестве поля gtidExecuted в файле дампа @.json. Утилита загрузки дампов не автоматически применяет набор GTID из исходной инстанции MySQL на целевую инстанцию MySQL. Для применения этих GTID на целевой инстанции MySQL для использования с репликацией используйте параметр updateGtidSet или импортируйте их вручную, в зависимости от версии целевой инстанции MySQL. Это также поддерживается для инстанций HeatWave Service DB System. См. описание параметра updateGtidSet для получения подробностей.

Имя и позиция файла двоичного журнала включаются при условии, что учетная запись пользователя, использовавшаяся для запуска утилиты дампов, имела соответствующие привилегии. Имя и позиция файла двоичного журнала могут быть использованы для настройки репликации из сервера-источника, на котором не включены GTID и не используется репликация на основе GTID, на реплику, на которой включены GTID, используя параметр ASSIGN_GTIDS_TO_ANONYMOUS_TRANSACTIONS оператора (который доступен с MySQL Server 8.0.23).

updateGtidSet: [ off | append | replace ]

Применить набор GTID из исходной инстанции MySQL, как записано в метаданных дампа, к набору GTID на целевой инстанции MySQL. Набор GTID содержит GTID всех транзакций, которые были применены на сервере, но не существуют ни в одном файле двоичного журнала на сервере. По умолчанию используется off, что означает, что набор GTID не применяется.

Не используйте этот параметр для дампов, созданных утилитой table dump MySQL Shell, только для дампов, созданных утилитой instance dump или schema dump MySQL Shell. Также не используйте этот параметр, когда на целевой инстанции MySQL запущена репликация Group Replication.

Для инстанций MySQL, которые не являются инстанциями HeatWave Service DB System, при установке параметров append или replace для обновления набора GTID также установите параметр skipBinlog в значение true. Это гарантирует, что GTID на сервере-источнике совпадают с GTID на целевом сервере. Для инстанций HeatWave Service DB System этот параметр не используется.

Для целевой инстанции MySQL версии 8.0 можно установить параметр в append, который добавляет набор GTID из исходной инстанции MySQL к набору GTID на целевой инстанции MySQL. Набор GTID для применения, который отображается в поле gtidExecuted в файле дампа @.json, не должен пересекаться с набором, уже имеющимся на целевой инстанции MySQL. Например, вы можете использовать этот параметр при импорте схемы из другой инстанции MySQL на целевую инстанцию MySQL, которая уже имеет схемы из других источников.

Также можно использовать replace для целевой инстанции MySQL версии 8.0, чтобы заменить набор GTID на целевой инстанции MySQL на набор GTID из исходной инстанции MySQL. Для этого набор GTID из исходной инстанции MySQL должен быть супермножеством набора GTID на целевой инстанции MySQL и не должен пересекаться с множеством транзакций в наборе GTID целевой инстанции, которые отсутствуют в её наборе GTID.

Для целевой инстанции MySQL версии 5.7 установите параметр в replace, который заменяет набор GTID на целевой инстанции MySQL на набор GTID из исходной инстанции MySQL. В MySQL 5.7 для этого набор GTID и набор GTID на целевой инстанции MySQL должны быть пустыми, поэтому инстанция должна быть неиспользуемой и не иметь ранее импортированных наборов GTID.

Для HeatWave Service DB System этот метод не поддерживается. Для применения набора GTID после импорта используйте команду \sql MySQL Shell (или перейдите в режим SQL) для выполнения следующего оператора на подключённой инстанции MySQL, копируя набор GTID gtid_executed из поля gtidExecuted в файле дампа @.json в метаданных дампа:

shell-js> \sql SET @@GLOBAL.gtid_purged= "+gtidExecuted_set";

Этот оператор, который работает с MySQL 8.0, добавляет набор GTID исходной инстанции MySQL к набору GTID целевой инстанции MySQL. Для MySQL 5.7 знак плюс (+) должен быть опущен, а наборы GTID и GTID на целевой инстанции MySQL должны быть пустыми. Дополнительные сведения см. в описании системной переменной в версии целевой инстанции MySQL.

createInvisiblePKs: [ true | false ]

Добавить первичные ключи в невидимых столбцах для каждой таблицы в дампе, которая не содержит первичный ключ. Параметр true применяется автоматически, если дамп был создан с параметром create_invisible_pks утилитой instance dump, schema dump или table dump MySQL Shell. Первичные ключи добавляются только если DDL для дампа был загружен (loadDdl: true). Невидимые столбцы (называемые "my_row_id") не оказывают влияния на приложения, использующие загруженные таблицы.

При установке createInvisiblePKs в значение true целевая инстанция MySQL должна быть версии 8.0.24 или выше, иначе загрузка завершится ошибкой. Невидимые столбцы доступны с версии MySQL Server 8.0.23, но ограничение на них в этой версии не позволяет использовать эту функцию.

Добавление первичных ключей таким способом пока не поддерживает входящую репликацию изменённых таблиц в систему высокой доступности HeatWave Service, так как для этой функции в настоящее время требуется, чтобы первичные ключи существовали как на сервере-источнике, так и на реплике. Если возможно, вместо использования этого параметра рассмотрите создание первичных ключей в таблицах на сервере-источнике перед повторным созданием дампа. С MySQL 8.0.23 это можно сделать без влияния на приложения, используя невидимые столбцы для хранения первичных ключей. Это рекомендуемая практика для повышения производительности и удобства использования и помогает базе данных, сгенерированной дампом, работать безупречно с HeatWave Service.

Параметры для службы HeatWave и Oracle Cloud Infrastructure

osBucketName: "string"

Имя ведра хранилища объектов Oracle Cloud Infrastructure, в котором находятся файлы дампов. По умолчанию используется профиль [DEFAULT] в файле конфигурации Oracle Cloud Infrastructure CLI, расположенном по адресу ~/.oci/config, для подключения к ведру. Вы можете использовать альтернативный профиль для подключения с помощью параметров ociConfigFile и ociProfile. Инструкции по настройке файла конфигурации CLI см. в разделе Файл конфигурации SDK и CLI.

osNamespace: "string"

Пространство имен Oracle Cloud Infrastructure, в котором расположено ведро хранилища объектов, имя которого указано в osBucketName. Пространство имен для ведра хранилища объектов отображается на вкладке «Информация о ведре» на странице сведений о ведре в консоли Oracle Cloud Infrastructure или может быть получено с помощью командной строки Oracle Cloud Infrastructure.

ociConfigFile: "string"

Файл конфигурации Oracle Cloud Infrastructure CLI, содержащий профиль, используемый для подключения вместо файла в стандартном расположении ~/.oci/config.

ociProfile: "string"

Имя профиля Oracle Cloud Infrastructure, используемого для подключения вместо профиля [DEFAULT] в файле конфигурации Oracle Cloud Infrastructure CLI, используемом для подключения.

ociAuth: "string"

Способ аутентификации, используемый при подключении к Oracle Cloud Infrastructure. Для этого параметра требуется, чтобы osBucketName был настроен со значением.

Доступны следующие параметры:

api_key: Подключения OCI используют файл конфигурации OCI. См. Раздел 4.7.1, «Хранилище объектов Oracle Cloud Infrastructure».

Если osBucketName определено со значением, но ociAuth не определено, api_key используется по умолчанию.
instance_principal: Подключения OCI используют аутентификацию по принципалам экземпляра. См. Аутентификация по принципалам экземпляра.

Этот параметр не может быть использован, если определены ociConfigFile или ociProfile.
resource_principal: Подключения OCI используют аутентификацию по принципалам ресурсов. См. Аутентификация по принципалам ресурсов.

Этот параметр не может быть использован, если определены ociConfigFile или ociProfile.
security_token: Подключения OCI используют временный, сгенерированный токен сессии. См. Аутентификация на основе токена сессии.

Параметры для служб, совместимых с S3

MySQL Shell поддерживает загрузку дампов, хранящихся в совместимых с S3 ведрах, таких как Amazon Web Services (AWS) S3.

Примечание

MySQL Shell поддерживает конфигурацию AWS S3 в параметрах командной строки, переменных среды и конфигурационных файлах. Параметры командной строки переопределяют переменные среды, конфигурационные файлы и параметры по умолчанию.

Сведения о требованиях к конфигурации см. в разделе Раздел 4.7, «Конфигурация облачных служб».

s3BucketName: "string"

Имя ведра S3, в котором находятся файлы дампов. По умолчанию используется профиль default в файлах конфигурации Amazon Web Services (AWS) CLI config и credentials, расположенных по адресу ~/.aws/, для подключения к ведру S3. Вы можете использовать альтернативные конфигурации и учетные данные для подключения с помощью параметров s3ConfigFile и s3CredentialsFile. Инструкции по установке и настройке AWS CLI см. в разделе Начало работы с AWS CLI.

s3CredentialsFile: "string"

Файл учетных данных, содержащий учетные данные пользователя для подключения вместо файла в стандартном расположении, ~/.aws/credentials. Как правило, файл учетных данных содержит aws_access_key_id и aws_secret_access_key, используемые для подключения.

s3ConfigFile: "string"

Файл конфигурации AWS CLI, содержащий профиль, используемый для подключения, вместо файла в стандартном расположении ~/.aws/config. Как правило, в конфигурационном файле содержатся регион и тип вывода для подключения.

s3Profile: "string"

Имя профиля профиля s3 CLI, используемого для подключения вместо профиля default в файле конфигурации AWS CLI, используемом для подключения.

s3Region: "string"

Имя региона, используемого для подключения.

s3EndpointOverride: "string"

URL конечной точки, используемой вместо стандартной.

При подключении к API совместимости S3 Oracle Cloud Infrastructure конечная точка имеет следующий формат: https://namespace.compat.objectstorage.region.oraclecloud.com. Замените namespace на пространство имен хранилища объектов и region на идентификатор вашего региона. Например, идентификатор региона для региона США-Восток (Эшберн) — us-ashburn-1.

Для пространства имен axaxnpcrorw5 в регионе США-Восток (Эшберн):

https://axaxnpcrorw5.compat.objectstorage.us-ashburn-1.oraclecloud.com.

Следующий пример демонстрирует загрузку MySQL дампа из папки test в ведре AWS S3 Bucket001:

      util.loadDump("test",{s3BucketName: "Bucket001", threads: 4})

Следующий пример демонстрирует загрузку MySQL дампа из префикса test в ведре хранилища объектов Bucket001, используя профиль конфигурации oci и s3EndpointOverride для направления подключения к конечной точке OCI необходимой аренды и региона:

      util.loadDump("test",{s3BucketName: "Bucket001",
      s3EndpointOverride: "https://axaxnpcrorw5.compat.objectstorage.us-ashburn-1.oraclecloud.com",
      s3Profile: "oci", threads: 4})

Параметры для Microsoft Azure Blob Storage

MySQL Shell поддерживает загрузку из Microsoft Azure Blob Storage.

Примечание

MySQL Shell поддерживает конфигурацию Microsoft Azure Blob Storage в параметрах командной строки, переменных среды и конфигурационных файлах. Параметры командной строки переопределяют переменные среды и конфигурационные файлы.

Сведения о требованиях к конфигурации и порядке приоритета типов конфигурации см. в разделе Раздел 4.7, «Конфигурация облачных служб».

azureContainerName: "string"

Обязательно. Имя Azure контейнера, из которого будет загружен дамп. Контейнер должен существовать.

azureConfigFile: "string"

Необязательно. Файл конфигурации, содержащий параметры подключения к хранилищу, вместо файла в стандартном расположении, например, ~/.azure/config. Если он не определён, используется файл конфигурации по умолчанию.

azureContainerName должен быть определён и не пуст.

azureStorageAccount: "string"

Необязательно. Имя Azure хранилища, используемого для операции.

azureStorageSasToken: "string"

Необязательно. Токен Azure Shared Access Signature (SAS), используемый для аутентификации операции вместо ключа.

В следующем примере конфигурация использует строку конфигурации для параметров подключения, что означает, что команда dump требует только azureContainerName.

Пример файла config:

        [cloud]
         name = AzureCloud

        [storage]
         connection_string=alphanumericConnectionString

Пример команды loadDump, которая импортирует содержимое папки с именем prefix1 в контейнер с именем mysqlshellazure в подключённую MySQL базу данных:

        util.loadDump("prefix1", {azureContainerName: "mysqlshellazure", threads: 4})

END_OF_DOCUMENT_MARKER

Параметры фильтрации

loadDdl: [ true | false ]

Установка этого параметра в значение false исключает файлы DDL из дампа при загрузке. По умолчанию установлено значение true, что означает, что файлы DDL загружаются.

loadData: [ true | false ]

Установка этого параметра в значение false исключает файлы данных из дампа при загрузке. По умолчанию установлено значение true, что означает, что файлы данных загружаются.

loadUsers: [ true | false ]

Импортировать (true) или не импортировать (false) пользователей и их роли и разрешения в целевой экземпляр MySQL. По умолчанию установлено значение false, поэтому пользователи по умолчанию не импортируются. Заявления для текущего пользователя пропускаются. Если пользователь уже существует в целевом экземпляре MySQL, возвращается ошибка, и разрешения пользователя из файлов дампа не применяются. Вы можете использовать параметр excludeUsers или includeUsers в утилите загрузки дампов для указания учётных записей пользователей, которые необходимо исключить или включить в импорт.

Утилиты дампов схемы и таблиц MySQL Shell не включают пользователей, роли и разрешения в дамп, но утилита дампов экземпляра может, и по умолчанию делает это. Параметры excludeUsers и includeUsers также могут быть использованы в утилите дампов экземпляра для исключения или включения указанных учётных записей пользователей из файлов дампа.

Если вы укажете true, но предоставленные файлы дампа не содержат учётных записей пользователей, утилита вернёт предупреждение и продолжит выполнение.

excludeUsers: array of strings

Исключить указанные учётные записи пользователей из импорта. Вы можете использовать его для исключения учётных записей пользователей, которые не принимаются для импорта в базу данных HeatWave Service или которые уже существуют или не нужны в целевом экземпляре MySQL. Укажите строку каждой учётной записи пользователя в формате "'user_name'@'host_name'" для учётной записи, определённой с именем пользователя и именем хоста, или "'user_name'" для учётной записи, определённой только с именем пользователя. Если вы не укажете имя хоста, будут исключены все учётные записи с этим именем пользователя.

includeUsers: array of strings

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

excludeSchemas: array of strings

Исключить указанные схемы из импорта. Обратите внимание, что схемы information_schema, mysql, ndbinfo, performance_schema и sys всегда исключаются из дампов, созданных утилитой дампов экземпляра MySQL Shell.

includeSchemas: array of strings

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

excludeTables: array of strings

Исключить указанные таблицы из импорта, чтобы они не загружались в целевой экземпляр MySQL. Имена таблиц должны быть квалифицированы с помощью действительного имени схемы и заключены в обратные кавычки, если это необходимо. Обратите внимание, что данные для таблиц mysql.apply_status, mysql.general_log, mysql.schema и mysql.slow_log tables всегда исключаются из дампа, созданного утилитой дампов схем MySQL Shell, хотя их DDL-заявления включаются.

includeTables: array of strings

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

excludeEvents: array of strings

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

includeEvents: array of strings

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

excludeRoutines: array of strings

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

includeRoutines: array of strings

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

excludeTriggers: array of strings

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

includeTriggers: array of strings

Загрузить только указанные триггеры из файлов дампа. Имена триггеров должны быть квалифицированы с помощью действительного имени схемы и имени таблицы (schema.table.trigger) и заключены в обратные кавычки, если это необходимо. Вы можете включить все триггеры для определённой таблицы, указав имя схемы и имя таблицы с этим параметром (schema.table).

Режим сгенерированных невидимых первичных ключей

MySQL Server 8.0.30 представил режим GIPK. При работе в этом режиме для любой таблицы InnoDB, созданной без явного первичного ключа, MySQL сервер автоматически добавляет сгенерированный невидимый первичный ключ (GIPK) в таблицу. Этот режим включается путем установки в значение ON.

Параметр утилиты загрузки MySQL Shell createInvisiblePKs использует режим GIPK сервера для генерации невидимых первичных ключей для таблиц, не имеющих первичных ключей.

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

Если createInvisiblePKs:false и , первичные ключи не генерируются для любой таблицы, загруженной из дампа.

Если createInvisiblePKs:false и , MySQL Shell пытается установить . Если изменение успешно, первичные ключи не генерируются для любой таблицы, загруженной из дампа.

Если createInvisiblePKs:true и , MySQL Shell пытается установить . Если изменение успешно, первичные ключи генерируются для каждой таблицы без первичных ключей, загруженной из дампа.

Если createInvisiblePKs:true и , первичные ключи генерируются для каждой таблицы, загруженной с использованием режима GIPK MySQL Server.

Если у пользователя, выполняющего утилиту загрузки MySQL Shell, нет необходимых привилегий MySQL Server, попытка установить не удастся. Если попытка не удалась и createInvisiblePKs:true, MySQL Shell генерирует невидимые первичные ключи для любой таблицы, у которой их нет.

Если параметр сервера GIPK включен, а параметр утилиты загрузки MySQL Shell createInvisiblePKs выключен, и у пользователя нет необходимых привилегий для изменения , генерируется ошибка, и загрузка завершается неудачно. Можно переопределить это поведение, включив переменную среды MySQL Shell MYSQLSH_ALLOW_ALWAYS_GIPK. Эта переменная среды переопределяет createInvisiblePKs:false, активизируя невидимые частные ключи для всех загруженных таблиц, если включено.

Если параметр утилиты загрузки MySQL Shell createInvisiblePKs включен, но параметр сервера GIPK выключен, MySQL Shell пытается включить . Если у пользователя есть соответствующие привилегии на целевом сервере MySQL, включено, и утилита загрузки использует режим GIPK сервера для создания невидимых первичных ключей в загруженных таблицах. Если у пользователя нет необходимых привилегий, таких как в HeatWave Service, MySQL Shell возвращается к предыдущему поведению и создаёт первичные ключи в таблице без использования режима GIPK сервера.

Изменение данных дампов

Параллельная утилита импорта таблиц MySQL Shell util.importTable() может быть использована совместно с утилитой загрузки дампов util.loadDump() для изменения данных в фрагментированных выходных файлах перед их загрузкой в целевой экземпляр MySQL. Вы можете изменить данные для одной таблицы за раз этим способом.

Используйте утилиту загрузки дампов с параметрами loadDdl: true и loadData: false для загрузки только файла DDL и создания выбранной таблицы в целевом экземпляре MySQL без данных.
```
shell-js> util.loadDump("/mnt/data/proddump", {
        > includeTables: ["product.pricing"],
        > loadDdl: true,
        > loadData: false});
```
Используйте утилиту параллельного импорта таблиц для захвата и преобразования данных для таблицы и импорта их в пустую таблицу в целевом экземпляре MySQL. В этом примере данные для таблицы pricing находятся в нескольких сжатых файлах, которые указываются с использованием шаблонов подстановок. Значения из столбцов id и prodname в файлах дампа без изменений присваиваются аналогичным столбцам в целевой таблице. Значения из столбца price в файлах дампа сохраняются и присваиваются переменной @1. Затем параметр decodeColumns используется для уменьшения цен на стандартную сумму, и уменьшенные цены помещаются в столбец price целевой таблицы.
```
shell-js> util.importTable ("/mnt/data/proddump/product@pricing@*.zst", {
        > schema: "product",
        > table: "pricing",
        > columns: ["id",  "prodname",  1],
        > decodeColumns: { "price": "0.8 * @1"}});
```
Повторите шаги 1 и 2 по необходимости для других таблиц в файлах дампов, где вам нужно изменить данные.
После завершения загрузки всех таблиц и данных, которые нужно было изменить, используйте утилиту загрузки дампов для загрузки DDL и данных для любых оставшихся таблиц, которые не требуют изменения. Убедитесь, что вы исключаете таблицы, которые вы изменяли на предыдущих шагах.
```
shell-js> util.loadDump("/mnt/data/proddump", {excludeTables: ["product.pricing"]});
```

END_OF_DOCUMENT_MARKER

Сообщения об ошибках утилиты импорта/экспорта MySQL Shell

Номера ошибок в диапазоне 53000-53999 относятся к утилите импорта данных MySQL Shell util.loadDump(). Могут быть возвращены следующие ошибки:

Номер ошибки: 53000; Символ: SHERR_LOAD_MANIFEST_EXPIRED_PARS

Сообщение: PAR в файле манифеста просрочены, время истечения срока действия: %s
Номер ошибки: 53001; Символ: SHERR_LOAD_MANIFEST_PAR_MISMATCH

Сообщение: Предоставленный PAR должен быть файлом в местоположении дампа: '%s'
Номер ошибки: 53002; Символ: SHERR_LOAD_SPLITTING_DDL_FAILED

Сообщение: Ошибка разделения скрипта DDL для таблицы %s: %s
Номер ошибки: 53003; Символ: SHERR_LOAD_SECONDARY_ENGINE_ERROR

Сообщение: Таблица %s имеет второе движке, но не все индексы были пересозданы
Номер ошибки: 53004; Символ: SHERR_LOAD_FAILED_TO_DISABLE_BINLOG

Сообщение: 'SET sql_log_bin=0' завершился с ошибкой: %s
Номер ошибки: 53005; Символ: SHERR_LOAD_WORKER_THREAD_FATAL_ERROR

Сообщение: Ошибка при загрузке дампа
Номер ошибки: 53006; Символ: SHERR_LOAD_UNSUPPORTED_DUMP_VERSION

Сообщение: Неподдерживаемая версия дампа
Номер ошибки: 53007; Символ: SHERR_LOAD_UNSUPPORTED_DUMP_CAPABILITIES

Сообщение: Неподдерживаемые возможности дампа
Номер ошибки: 53008; Символ: SHERR_LOAD_INCOMPLETE_DUMP

Сообщение: Неполный дамп
Номер ошибки: 53009; Символ: SHERR_LOAD_UNSUPPORTED_SERVER_VERSION

Сообщение: Загрузка дампов поддерживается только в MySQL 5.7 и новее
Номер ошибки: 53010; Символ: SHERR_LOAD_DUMP_NOT_MDS_COMPATIBLE

Сообщение: Думп несовместим с MDS
Номер ошибки: 53011; Символ: SHERR_LOAD_SERVER_VERSION_MISMATCH

Сообщение: Несовпадение версий MySQL
Номер ошибки: 53012; Символ: SHERR_LOAD_UPDATE_GTID_GR_IS_RUNNING

Сообщение: Опция updateGtidSet не может быть использована на сервере с запущенной групповой репликацией.
Номер ошибки: 53013; Символ: SHERR_LOAD_UPDATE_GTID_APPEND_NOT_SUPPORTED

Сообщение: Целевой сервер MySQL не поддерживает updateGtidSet:'append'.
Номер ошибки: 53014; Символ: SHERR_LOAD_UPDATE_GTID_REQUIRES_SKIP_BINLOG

Сообщение: Опция updateGtidSet на целевом сервере MySQL 5.7 может быть использована только при включенной опции skipBinlog.
Номер ошибки: 53015; Символ: SHERR_LOAD_UPDATE_GTID_REPLACE_REQUIRES_EMPTY_VARIABLES

Сообщение: Опция updateGtidSet:'replace' может быть использована на целевом сервере только если GTID_PURGED и GTID_EXECUTED пустые, но они не пустые.
Номер ошибки: 53016; Символ: SHERR_LOAD_UPDATE_GTID_REPLACE_SETS_INTERSECT

Сообщение: Опция updateGtidSet:'replace' может быть использована только если gtid_subtract(gtid_executed,gtid_purged) на целевом сервере не пересекается с набором GTID, который был экспортирован.
Номер ошибки: 53017; Символ: SHERR_LOAD_UPDATE_GTID_REPLACE_REQUIRES_SUPERSET

Сообщение: Опция updateGtidSet:'replace' может быть использована только если экспортированный набор GTID является надмножеством текущего значения gtid_purged на целевом сервере.
Номер ошибки: 53018; Символ: SHERR_LOAD_UPDATE_GTID_APPEND_SETS_INTERSECT

Сообщение: Опция updateGtidSet:'append' может быть использована только если gtid_executed на целевом сервере не пересекается с экспортированным набором GTID.
Номер ошибки: 53019; Символ: SHERR_LOAD_INVISIBLE_PKS_UNSUPPORTED_SERVER_VERSION

Сообщение: Опция 'createInvisiblePKs' требует сервер 8.0.24 или новее.
Номер ошибки: 53020; Символ: SHERR_LOAD_REQUIRE_PRIMARY_KEY_ENABLED

Сообщение: sql_require_primary_key включён на целевом сервере
Номер ошибки: 53021; Символ: SHERR_LOAD_DUPLICATE_OBJECTS_FOUND

Сообщение: Найдены дублирующие объекты в целевой базе данных
Номер ошибки: 53022; Символ: SHERR_LOAD_DUMP_WAIT_TIMEOUT

Сообщение: Таймаут дампа
Номер ошибки: 53023; Символ: SHERR_LOAD_INVALID_METADATA_FILE

Сообщение: Неверный файл метаданных %s
Номер ошибки: 53024; Символ: SHERR_LOAD_PARSING_METADATA_FILE_FAILED

Сообщение: Не удалось пропарсить файл метаданных %s: %s
Номер ошибки: 53025; Символ: SHERR_LOAD_LOCAL_INFILE_DISABLED

Сообщение: local_infile отключен на сервере
Номер ошибки: 53026; Символ: SHERR_LOAD_PROGRESS_FILE_ERROR

Сообщение: Ошибка загрузки файла прогресса загрузки '%s': %s
Номер ошибки: 53027; Символ: SHERR_LOAD_PROGRESS_FILE_UUID_MISMATCH

Сообщение: Файл прогресса был создан для сервера с UUID %s, в то время как целевой сервер имеет UUID: %s
Номер ошибки: 53028; Символ: SHERR_LOAD_MANIFEST_UNKNOWN_OBJECT

Сообщение: Неизвестный объект в манифесте: %s
Номер ошибки: 53029; Символ: SHERR_LOAD_CORRUPTED_DUMP_MISSING_METADATA

Сообщение: Каталог дампов повреждён, некоторые файлы метаданных отсутствуют
Номер ошибки: 53030; Символ: SHERR_LOAD_CORRUPTED_DUMP_MISSING_DATA

Сообщение: Каталог дампов повреждён, некоторые файлы данных отсутствуют
Номер ошибки: 53031; Символ: SHERR_LOAD_CHECKSUM_VERIFICATION_FAILED

Сообщение: Проверка контрольной суммы завершилась неудачей

Номера ошибок в диапазоне 54000-54999 относятся к ошибкам соединения и сети, которые возникли при использовании утилиты загрузки дампов MySQL Shell util.loadDump(), или утилиты экспорта дампов MySQL Shell util.dumpInstance(), утилиты экспорта схемы util.dumpSchemas() и утилиты экспорта таблицы util.dumpTables(). В большинстве случаев код ошибки соответствует HTTP-ошибке, например, ошибка 54404 возникает, когда целевой объект URL не найден (HTTP 404 Not Found). Могут быть возвращены следующие ошибки:

Номер ошибки: 54000; Символ: SHERR_DL_COMMON_CONNECTION_ERROR

Сообщение: %sОшибка соединения: %s.
Номер ошибки: 54100 до 54511; Символ: SHERR_NETWORK_[HTTP error name]

Сообщение: Сообщение, специфичное для контекста