11.6 Dump Loading Utility — MySQL Shell 8.4

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

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

О утилите

Для импорта в HeatWave Service DB System, MySQL Shell должен быть установлен на экземпляре Oracle Cloud Infrastructure Compute, у которого есть доступ к HeatWave Service DB System. Если файлы дампов находятся в ведре хранилища объектов Oracle Cloud Infrastructure, вы можете получить доступ к ведру хранилища объектов с экземпляра Compute. Если файлы дампов находятся на локальной системе, вам необходимо перенести их на экземпляр Oracle Cloud Infrastructure Compute с помощью утилиты копирования по вашему выбору, в зависимости от операционной системы, выбранной для вашего экземпляра 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, утилита загрузки дампов обрабатывает их разархивирование.

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

Для дополнительного повышения производительности загрузки данных можно отключить журнал перегенерации (redo log) в целевом экземпляре 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, либо вручную. При использовании GTID на целевом MySQL-сервере (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-сервер.

ignoreExistingObjects: [ true | false ]

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

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

handleGrantErrors: abort|drop_account|ignore

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

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

characterSet: "string"

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

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

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

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

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

Для целевого экземпляра MySQL версии MySQL 5.7 установите параметр в значение replace, что заменяет набор GTID на целевом экземпляре MySQL набором GTID из исходного экземпляра MySQL. В MySQL 5.7 для этого наборы 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 Server к набору GTID целевого экземпляра MySQL. Для MySQL 5.7 знак плюс (+) должен быть опущен, а наборы GTID и на целевом экземпляре MySQL должны быть пустыми. Для получения дополнительной информации см. описание системной переменной в версии целевого экземпляра MySQL.

createInvisiblePKs: [ true | false ]

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

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

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

Параметры для HeatWave Service и Oracle Cloud Infrastructure

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

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

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

Примечание

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

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

s3BucketName: "string"

Имя корзины S3, в которой находятся файлы дампов. По умолчанию используется профиль default в командной строке Amazon Web Services (AWS) и файлах конфигурации 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 на имя пространства Object Storage и 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 в корзине Object Storage Bucket001, используя конфигурационный профиль oci и параметр s3EndpointOverride для направления подключения к конечной точке OCI требуемой аренды и региона:

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

Параметры для хранилища BLOB Microsoft Azure

MySQL Shell поддерживает загрузку из хранилища BLOB Microsoft Azure.

Примечание

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

Дополнительную информацию о требованиях к конфигурации и порядке приоритетов конфигурационных типов см. в разделе 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.

Если пользователь, выполняющий утилиту загрузки MySQL Shell, не имеет необходимых привилегий сервера MySQL, попытка установить не удастся. Если попытка не удастся и 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.dumpSchemas()). В большинстве случаев код ошибки соответствует возникающей HTTP-ошибке - например, ошибка 54404 возникает, когда целевой ресурс по указанному URL не найден (HTTP 404 Not Found). Могут быть возвращены следующие ошибки:

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

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

Сообщение: Сообщение, зависящее от контекста