RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

Глава 20. Опции mysqlbackup

Следующие разделы описывают параметры командной строки для различных режимов работы mysqlbackup.

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

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

Таблица 20.1. Список опций

ИмяОписание ВведенаУстарела Удалена
--backup-dir Каталог, чтобы сохранить данные резервного копирования.
--backup-image Определяет путь образа резервной копии.
--backup_innodb_data_file_path Определяет системный путь файлов табличного пространства Innodb и размер в резервной копии.
--backup_innodb_data_home_dir Резервный основной каталог для всех файлов данных InnoDB в системном табличном пространстве.
--backup_innodb_log_group_home_dir Резервный каталог для файлов журнала InnoDB.
--backup_innodb_undo_directory Относительный или абсолютный путь к каталогу, где InnoDB создает отдельные табличные пространства для журнала отмены.
--character-sets-dir Каталог для файлов набора символов.
--cloud-access-key Ключ доступа для облака.8.0.23
--cloud-access-key-id Ключ доступа AWS ID для регистрации на Amazon S3.
--cloud-aws-region Регион для Amazon Web Services, к которому mysqlbackup обращается в S3.
--cloud-basicauth-url URL для HTTP Basic Authentication для доступа Swift.
--cloud-bucket Место хранения для образа резервной копии.
--cloud-buffer-size Размер буфера для операций с облаком.
--cloud-ca-info Абсолютный путь к CA-файлам для идентификации хоста для связей SSL.
--cloud-ca-path Каталог сертификата CA в дополнение к каталогу системы по умолчанию.
--cloud-chunk-size Размер куска в мегабайтах, если передача кусками позволена. 8.0.23
--cloud-chunked-transfer Используйте передачу кусками с обслуживанием облачного хранилища.
--cloud-container Контейнер Swift для образа резервной копии.
--cloud-host Имя хоста для обслуживания хранения. 8.0.22
--cloud-identity-url URL обслуживания идентификации Keystone.
--cloud-object Объект хранения для образа резервной копии.
--cloud-object-key Ключ объекта Amazon S3 для образа резервной копии.
--cloud-par-url Предварительно заверенный запрос URL для хранения объектов OCI 8.0.22
--cloud-password Пароль для пользователя, определенного --cloud-user-id.
--cloud-proxy Адрес прокси и номер порта для перекрытия параметров настройки окружающей среды по умолчанию для доступа к облачному сервису.
--cloud-region Регион Keystone для пользователя, определенного --cloud-user-id.
--cloud-secret-access-key Ключ доступа AWS.
--cloud-secret-key Секретный ключ для облака.8.0.23
--cloud-service Облачный сервис для резервного копирования данных или восстановления.
--cloud-tempauth-url URL сервиса идентификации для подтверждения пользователя с системой аутентификации Swift's TempAuth.
--cloud-tenant Арендатор Keystone для пользователя, определенного --cloud-user-id.
--cloud-trace Напечатать трассировочную информацию для операций по облаку.
--cloud-user-id User ID для доступа к Swift.
--comments Определяет последовательность комментариев.
--comments-file Определяет путь к файлу комментариев.
--compress Создать резервную копию в сжатом формате.
--compress-level Определяет уровень сжатия.
--compress-method Определяет алгоритм сжатия.
--compression-algorithms Разрешенные алгоритмы сжатия для связей с сервером 8.0.18
--connect_timeout Тайм-аут связи в секундах.
--datadir Путь к каталогу данных mysql.
--debug Напечатать отладочную информацию.
--decrypt Расшифровать образ резервной копии, написанный в MEB Secure File.
--default-character-set Установить набор символов по умолчанию.
--defaults-extra-file Прочитать этот файл после того, как глобальные файлы будут прочитаны.
--defaults-file Прочитать опции по умолчанию только от данного файла.
--defaults-group-suffix Также прочитать группы опций с обычными именами и суффиксом str.
--disable-manifest Не создавать файлы декларации для операции резервного копирования.
--dst-entry Используется с однофайловым резервным копированием файлов, чтобы извлечь единственный файл или каталог к определенному пользователями пути.
--enable-cleartext-plugin Позволяет плагин идентификации открытого текста. 8.0.22
--encrypt Зашифровать образ резервной копии и записать в MEB Secure File.
--encrypt-password Заданный пользователем пароль, которым mysqlbackup шифрует ключи шифрования для зашифрованных табличных пространств InnoDB.
--error-code Код выхода, для которого команда печатает соответствующее выходное сообщение.
--exclude-tables Исключите в резервной копии или восстановлении таблицы, имена которых соответствуют регулярному выражению REGEXP.
--exec-when-locked Выполните указанную утилиту в фазе блокировки около конца операции резервного копирования.
--force Принудительно переписать данные, журнал или файл образа в зависимости от операции.
--free-os-buffers Освободить кэш файловой системы, синхронизируя буфера
--help Отобразить справочное сообщение.
--host Имя хоста, чтобы соединиться.
--include [Устаревшая] Резервная копия только тех файлов данных innodb, которые соответствуют регулярному выражению REGEXP. 8.0.20
--include-tables Включить в резервной копии или восстановлении таблицы, имена которых соответствуют регулярному выражению REGEXP.
--incremental Определяет, что связанная операция backup или backup-to-image возрастающая.
--incremental-backup-dir Определяет местоположение для возрастающей директивной резервной копии.
--incremental-base Спецификация основной резервной копии для --incremental.
--incremental-with-redo-log-only Определяет инкрементное резервное копирование таблиц InnoDB, основанное на копировании журнала отката к резервной копии, без включения любых файлов данных InnoDB в резервной копии.
--innodb_data_home_dir Определяет основной каталог для всех файлов данных InnoDB в общем системном табличном пространстве.
--innodb_log_group_home_dir Путь к каталогу к файлам журнала InnoDB.
--innodb_undo_directory Путь к каталогу табличных пространств отмены InnoDB.
--key Симметричный ключ используется для шифрования и декодирования.
--key-file Путь к файлу, который содержит симметричный ключ, используемый для шифрования и декодирования.
--limit-memory Память в MB, доступном для операции MEB.
--lock-wait-timeout Определите тайм-аут в секундах для FLUSH TABLES WITH READ LOCK во время заключительного этапа резервной копии. 8.0.16
--log-bin Определите местоположение для двоичной регистрации, которая будет восстановлена.
--log-bin-index Определяет абсолютный путь индексного файла, который перечисляет все двоичные файлы журнала.
--login-path Прочитайте опции из названного пути логина в файле .mylogin.cnf.
--messages-logdir Определяет путь существующего каталога для хранения регистрации сообщений.
--no-defaults Не читать опции по умолчанию ни от какого заданного файла.
--no-history-logging Отключить сохранение истории, даже если связь доступна.
--no-locking Отключить все табличные блокировки во время резервных копий.
--no-redo-log-archive Пропустить архивирование журнала отката во время резервных копий. 8.0.17
--number-of-buffers Определяет точное количество буферов памяти, которые будут использоваться для операции резервного копирования.
--on-disk-full Определяет поведение, когда процесс резервного копирования сталкивается с полным дискоом.
--only-innodb Поддержать только файлы данных InnoDB и файлы журнала.
--only-known-file-types Включает только файлы списка известных типов в резервной копии.
--optimistic-busy-tables Выполнить оптимистическую резервную копию, используя регулярное выражение, определенное опцией для выбора таблиц, которые будут пропущены в первой фазе оптимистической резервной копии.
--optimistic-time Выполнить оптимистическую резервную копию со значением, определенным как оптимистическое время, то есть время, после которого таблицы, которые не были изменены, считаются неактивными.
--page-reread-count Максимальное количество страницы для перечитывания.
--page-reread-time Время ожидания перед перепрочтением страницы.
--password Пароль для связи.
--pipe Псевдоним для --protocol=pipe.
--plugin-dir Определяет каталог для клиентских плагинов. 8.0.22
--port Номер порта TCP, чтобы соединиться.
--print-defaults Напечатать список значений опций, поставляемых файлами по умолчанию.
--process-threads Определяет количество потоков процесса для операции резервного копирования.
--progress-interval Интервал между отчетами о выполнении работ в секундах.
--protocol Протокол для связи.
--read-threads Определяет количество потоков чтения для операции резервного копирования.
--relay-log Определяет местоположение для журнала реле, который будет восстановлен на сервере точной копии.
--relay-log-index Определяет абсолютный путь индексного файла, который перечисляет все файлы журнала реле.
--rename Переименовать единственную таблицу, когда она будет выбрана опцией --include-tables для восстановления
--safe-slave-backup-timeout Поддерживая сервер точной копии, значение тайм-аута для ожидания потока SQL репликации, чтобы удалить его временные таблицы.
--sbt-database-name Используется в качестве подсказки Media Management Software (MMS) для выбора носителя и политики для резервного копирования на магнитную ленту.
--sbt-environment Список разделенных запятой значений назначений переменной окружения, которые будут переданы библиотеке SBT.
--sbt-lib-path Путь к библиотеке SBT, использовавшейся программным обеспечением, которое справляется с резервными копированиями на магнитную ленту.
--shared-memory-base-name Это называет имя общей памяти, используемой сервером Windows, чтобы разрешить клиентам соединяться с использованием общей памяти (только Windows).
--show-progress Периодически производить короткие отчеты о выполнении работ, известные как индикаторы хода выполнения.
--skip-binlog Не включать двоичные файлы журнала во время резервной копии или не восстанавливать их во время восстановления.
--skip-final-rescan Пропустить заключительный перепросмотр для таблиц InnoDB, которые изменяются операциями DDL.
--skip-messages-logdir Отключить регистрацию в файл teelog.
--skip-relaylog Не включать файлы журнала реле во время резервной копии или восстановления.
--skip-unused-pages Пропустить неиспользованные страницы в табличных пространствах, поддерживая таблицы InnoDB.
--slave-info Информация, чтобы настроить идентичный сервер точной копии.
--sleep Время, которое спать в миллисекундах после копирования каждого 1 МБ данных.
--socket Файл сокета, чтобы использовать, чтобы соединиться.
--src-entry Определяет файл или каталог, чтобы извлечь из однофайлового резервного копирования.
--ssl-ca Файл CA в формате PEM (подразумевает --ssl).
--ssl-capath Каталог CA (см. документацию OpenSSL, подразумевает --ssl).
--ssl-cert Сертификат X509 в формате PEM (подразумевает --ssl).
--ssl-cipher SSL-шифр (подразумевает --ssl).
--ssl-fips-mode Работает ли MEB в режиме FIPS. 8.0.14
--ssl-key Ключ X509 в формате PEM (подразумевает --ssl).
--ssl-mode Состояние защиты связи с сервером.
--start-lsn Определяет самое высокое значение LSN, включенное в предыдущую резервную копию.
--suspend-at-end Делает паузу mysqlbackup, когда процедура резервного копирования близка к окончанию.
--trace Уровень сообщений отладки mysqlbackup.
--uncompress Распаковать резервную копию во время операции.
--use-tts Позволить выборочную резервную копию таблиц InnoDB, используя транспортабельные табличные пространства (TTS).
--user Имя пользователя базы данных, чтобы соединиться.
--verbose Напечатать больше информации.
--version Покажите информацию о версии.
--with-timestamp Создайте подкаталог под резервным каталогом с именем, сформированным из метки времени операции резервного копирования.
--write-threads Определяет количество потоков записи для операции резервного копирования.
--zstd-compression-level Уровень сжатия для связей с сервером с использованием сжатия ZSTD 8.0.18

20.1. Общие опции

Это опции общего характера или опции, которые не классифицированы ни под какой другой определенной группой:

  • Следующие общие опции также существуют для команды mysql. Полные описания для них могут быть найдены в документации MySQL, например, в Server Option, System Variable, and Status Variable Reference . Эти опции должны быть определены перед любыми другими опциями mysqlbackup, включая остальную часть общих опций:

    • --print-defaults: Напечатать список аргументов программы.

    • --no-defaults: не читать опции по умолчанию ни от какого файла.

    • --defaults-file=PATH : прочитать опции по умолчанию из данного файла. Это должно быть первой опцией, которая будет определена, если используется.

    • --defaults-extra-file= PATH: прочитать этот файл после того, как глобальные файлы будут прочитаны.

    • --defaults-group-suffix= str: также прочитать группы опций с обычными именами и суффиксом str.

  • Следующие варианты также распространены между mysqlbackup и mysql, полные описания для них могут быть найдены в документации MySQL, например, Server Option, System Variable, and Status Variable Reference. Но mysqlbackup не принимает кратких форм для этих опций (например, необходимо использовать --help вместо -h для mysqlbackup):

    • --help : отобразить справочное сообщение.

    • --version: показать информацию о версии.

  • Более общие варианты доступны для mysqlbackup:

    • --verbose: напечатать больше информации.

      --debug=STRING: напечатать дополнительную отладочную информацию. Принимает следующие аргументы:

      • all: печатать дополнительную отладочную информацию для всех операций.

      • SBT: печатать дополнительную отладочную информацию для операций, использующих интерфейс System Backup to Tape (SBT).

      • null: когда пустая строка или никакой аргумент вообще не определяются, mysqlbackup ведет себя как будто задано --verbose.

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

      Для любой операции восстановления НЕ пытайтесь вернуть данные непустому каталогу данных, используя --force, это может вызвать повреждение данных и другие неожиданные действия. Не используйте --force с copy-back или с copy-back-and-apply-log.

      • Переписывание файлов данных InnoDB и файлов журнала во время apply-log и apply-incremental-backup.

      • Замена файла образа во время backup-to-image или backup-dir-to-image.

    • --trace=level

      Формат командной строки --trace=LEVEL
      ТипEnumeration
      По умолчанию0
      Допустимые значения

      0

      1

      2

      3

      Уровень отладки сообщений mysqlbackup. Допустимые уровни в порядке увеличивающейся точности:

      • 0 - INFO (information, warnings, errors).

      • 1 - FINE (больше информации, чем на уровне 0).

      • 2 - FINER (больше информации, чем на уровне 1).

      • 3 - FINEST (самый полный уровень информации, которая может быть дана).

    • --error-code=CODE

      Формат командной строки --error-code
      ТипNumeric
      Минимум0
      Максимум19

      Определяет код выхода для которого print-message печатает соответствующее выходное сообщение. Посмотрите раздел 17.1.

    • --enable-cleartext-plugin

      MySQL Enterprise Backup 8.0.22 и позже: Позволяет Client-Side Cleartext Pluggable Authentication. Требуемый, используя простую аутентификацию LDAP. См. главу 16.

    • --plugin-dir=plugin-dir

      MySQL Enterprise Backup 8.0.22 и позже: Определяет каталог для клиентских плагинов. Требуемый, используя основанную на SASL аутентификацию LDAP И клиентский плагин не находится в каталоге плагинов сервера. См. главу 16.

20.2. Опции связи

Когда mysqlbackup создает резервную копию, он посылает команды SQL в сервер MySQL, используя соединение с базой данных. Способ создать связь подобен тому, что описан в Connecting to the MySQL Server Using Command Options MySQL 8.0 Reference Manual.

Как часть вызова mysqlbackup определите соответствующие --user, --password, --port и другие опции соединения с сервером MySQL. Можно определить определенные для связи опции клиента MySQL, упомянутые ниже в разделах [mysqlbackup] или [client] конфигурационного файла MySQL, или через параметры командной строки mysqlbackup:

  • mysqlbackup читает только опции --user, --password, --port и --socket группы [client] и игнорирует любые другие варианты связи.

  • Если вы не предоставляете значение для --password, команда его спросит.

  • Опция --host позволена в конфигурационном файле для совместимости, но это не имеет никакого эффекта. mysqlbackup всегда соединяется с IP-адресом локального сервера.

  • Если ни один из алгоритмов, определенных --compression-algorithms, не разрешен сервером, связь с сервером не будет установлена.

Большинство других параметров связи, используемых командой mysql, признаны, но тихо проигнорированы. Неизвестные параметры связи заставляют mysqlbackup бросать ошибку и завершаться.

20.3. Варианты хранилища сервера

Эти варианты хранилища определяют различные параметры, связанные с сервером базы данных, на который восстанавливается резервная копия.

Эти варианты используются только с операциями восстановления то есть, copy-back и copy-back-and-apply-log. Описания ниже объясняют, как эти опции используются с mysqlbackup, для получения информации о том, как они используются с сервером MySQL, щелкните по имени, чтобы увидеть описание в документации MySQL.

  • datadir=PATH

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

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

  • log-bin [=basename]

    Определите местоположение для двоичной регистрации, которая будет восстановлена. По умолчанию, во время восстановления двоичная регистрация вернется к тому же самому местоположению, где это было найдено на поддержанном сервере. Используйте эту опцию, чтобы определить иное целевое местоположение для двоичной регистрации. Опция работает так же, как --log-bin сервера MySQL при определении местоположения и названия файлов журнала, см. здесь. Как резюме:

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

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

    • Используя этот выбор с basename, содержащим полный путь к файлу (например, /home/admin/db/binlogdir/binlog), двоичный журнал будет помещен в заданный каталог (в этом примере в /home/admin/db/binlogdir/) с использованием поставляемого базового имени (в этом примере это binlog).

    Опция только для copy-back-and-apply-log и copy-back. Использование с любыми другими операциями заставляет команду потерпеть неудачу.

  • relay-log [=basename]

    Определите местоположение для журнала реле, который будет восстановлен на сервере точной копии. По умолчанию во время восстановления для сервера точной копии журнал реле вернется к тому же самому местоположению, где это было найдено на поддержанном сервере точной копии. Используйте этот выбор, чтобы определить иное целевое местоположение для него. Выбор работает так же, как и --relay-log сервера MySQL в плане определения местоположения и названия файлов журнала реле, см. здесь. Вкратце:

    • Используя этот выбор без basename, журнал будет помещен в каталог данных целевого сервера с базовым именем по умолчанию host_name -relay-bin.

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

    • Используя этот выбор с basename, содержащим полный путь к файлу (например, /home/admin/db/relaylogdir/relaylog), журнал будет помещен в заданный каталог данных целевого сервера (/home/admin/db/relaylogdir/) с использованием поставляемого базового имени (relaylog).

    Опция только для copy-back-and-apply-log и copy-back. Использование с любыми другими операциями заставляет команду потерпеть неудачу.

  • --log-bin-index[= PATH]

    Определите абсолютный путь (включая имя файла и расширение) для восстановления индексного файла, который перечисляет все двоичные файлы журнала, если это отличается от пути по умолчанию, данного ниже.

    По умолчанию: data_dir/ host_name-bin.index.

  • --relay-log-index[=PATH ]

    Определите абсолютный путь (включая имя файла и расширение) для восстановления индексного файла, который перечисляет все файлы журнала реле, если это отличается от пути по умолчанию, данного ниже.

    По умолчанию: data_dir/host_name -relay-bin.index.

  • innodb_data_home_dir= PATH

    Определяет каталог, где размещены файлы данных InnoDB. Обычно тот же самый, что и datadir, но может отличаться. Этот параметр вместе с innodb_data_file_path= SIZE определяет, где на сервере MySQL расположены файлы данных InnoDB ibdata1, ibdata2 и т.д.

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

    Для восстановления: каталог, где файлы данных InnoDB должны быть восстановлены. Определите опцию, только если файлы данных InnoDB должны быть восстановлены за пределами каталога данных сервера. 8.0.16 и и позже: указанный каталог не должен существовать или должен быть пустым, иначе операция восстановления потерпит неудачу, даже если использован парметр --force.

  • innodb_log_group_home_dir= PATH

    Определяет, где журнал отката InnoDB лежит в хранилище сервера. Обычно то же самое, что datadir, но может отличаться.

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

    Для восстановления: каталог, где файлы данных InnoDB должны быть восстановлены. Определите опцию, только если файлы журнала отката InnoDB должны быть восстановлены за пределами каталога данных сервера. 8.0.16 и и позже: указанный каталог не должен существовать или должен быть пустым, иначе операция восстановления потерпит неудачу, даже если использован парметр --force.

  • Если innodb_data_home_dir относительный путь, то путь расположен относительно (то есть, ниже) значения datadir.

  • innodb_data_home_dir = "" указывает на каталог /.

  • Если innodb_data_home_dir абсолютный путь, его значение используется как есть.

  • innodb_undo_directory= PATH

    Определяет, где находятся на сервере журналы отмены InnoDB. Обычно то же самое, как datadir, но может отличаться.

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

    Для восстановления:

    • 8.0.16 и позже: каталог, где табличные пространства отмены, а также любые табличные пространства отмены не по умолчанию, находящиеся в каталоге данных поддержанного сервера, должны быть восстановлены. Внешний табличные пространства отмены вернутся по умолчанию к местоположениям, в которых они были найдены на поддержанном сервере, посмотрите описание для undo log files. Указанный каталог не должен существовать или должен быть пустым, иначе операция восстановления потерпит неудачу, даже если использован парметр --force.

    • 8.0.15 и ранее: каталог, где файлы журнала отмены должен быть восстановлен. Определите опцию только если файлы журнала отмены должны быть восстановлены за пределами каталога данных сервера.

    Его значение получено следующим образом:

    • Если innodb_undo_directory не указана, это наследует значение от datadir.

    • Если innodb_undo_directory относительный путь, то путь взят относительно (то есть, ниже) значения datadir.

    • Если innodb_undo_directory абсолютный путь, его значение используется как есть.

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

  • 20.4. Варианты резервного репозитория

    Эти опции определяют различные параметры, связанные с образом резервной копии или каталогом, или с тем, как резервная копия будет восстановлена. Как правило, --backup-image и --backup-dir единственные опции из группы, которые необходимо определить, используя mysqlbackup.

    Варианты резервного репозитория используются со следующими операциями:

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

    Следующие варианты определяют структуру резервной копии:

    • --backup-image=IMAGE

      Формат командной строки --backup-image=IMAGE
      ТипFile name

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

      Кроме тех случаев, когда текущий образ резервной копии с --backup-image=- , если --backup-image не дает имя полного пути, mysqlbackup интерпретирует значение так:

      По умолчанию однофайловое резервное копирование транслируется к стандартному выводу, чтобы можно было перекачать его по каналу непосредственно к другим командам, таким как резервное копирование на магнитную ленту или ssh-команды.

      Вы можете произвольно префикс имени образа с file:, чтобы показать показать файловый ввод-вывод по умолчанию). Для резервных копий на магнитную ленту префикс sbt:. См. раздел 4.3.1.2 для получения дополнительной информации о резервных копированиях на магнитную ленту.

    • --backup_dir=PATH

      Аналогично --backup-dir. Резервный каталог в соответствии с которым данные резервного копирования и метаданные сохранены постоянно или временно. Это решающий параметр, требуемый для большинства видов резервной копии.

      Опция используется по-другому для различных операций и в различных ситуациях:

      • Для резервной копии к единственному файлу (включая возрастающие, сжатые, зашифрованные и облачные резервные копии): используйте --backup-dir, чтобы поставлять временный каталог, чтобы сохранить метаданные резервных копий (включая журнал сообщений mysqlbackup, начальный и конечный LSN и т.д.) и некоторый временный вывод. Данные резервного копирования, вместе с копией метаданных, будут сохранены в файле, имя которого определяется опцией --backup-image .

        Но если --backup-image не дает имя полного пути, mysqlbackup на самом деле возьмет значение --backup-image как путь относительно каталога, определенного --backup-dir, и таким образом сохранит копию под --backup-dir (или если используется опция --with-timestamp в подкаталоге, созданном под --backup-dir, который имеет метку времени в имени).

        Для 8.0.19 и 8.0.20: относительный путь, определенный для --backup-image взят относительно каталога, в котором запущена команда backup-to-image .

      • Для резервной копии в каталог: используйте --backup-dir , чтобы определить каталог, чтобы сохранить данные резервного копирования и метаданные (включая регистрацию сообщений mysqlbackup, значения LSN и т.д.). Каталог, определенный --backup-dir, не может быть подкаталогом каталога, определенного --datadir.

        Когда --with-timestamp также задана, дополнительный уровень подкаталога с меткой времени в имени создается под --backup-dir (см. описание для --with-timestamp). Если применена опция --with-timestamp , каталог, определенный --backup-dir, должен быть пустым, или операция резервного копирования потерпит неудачу с ошибкой.

      • Для восстановления однофайлового резервного копирования (включая возрастающие, сжатые, зашифрованные и облачные резервные копии): при применении copy-back-and-apply-log, чтобы восстановить копию, используйте --backup-dir, чтобы указать место, где хранить временные данные. Каталог, определенный --backup-dir, должен быть пустым: если непустой каталог будет использоваться, операция восстановоения будет выполнена, но восстановленные данные могут быть испорчены.

        Когда восстановление однофайлового резервного копирования файлов создается с опцией use-tts= with-minimum-locking, каталог, определенный --backup-dir, также используется для извлечения временно всех таблиц в резервной копии и для выполнения фазы apply-log , чтобы сделать данные актуальными прежде, чем вернуть их в каталог данных сервера.

      • Для восстановления резервного каталога: Примените опцию --backup-dir, чтобы определить местоположение резервного каталога, из которого данные вернутся серверу.

    • backup_innodb_data_home_dir= PATH

      Каталог, в соответствии с которым должны быть сохранены файлы данных резервной копии InnoDB. Определите опцию, если вы хотите поместить файлы данных где-нибудь кроме местоположения по умолчанию (которое является backup-dir /datadir). Если значение параметра отличается от backup-dir /datadir, это сохранено в файле backup-my.cnf как innodb_data_home_dir для получения информации, чтобы mysqlbackup мог понять структуру резервной копии, когда это выполняет различные операции на резервной копии. Вместе с backup_innodb_data_file_path это определяет фактические пути к файлам данных InnoDB в резервной копии.

      Значение для параметра получено следующим образом:

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

    • backup_innodb_data_file_path= VALUE

      Имена файла данных InnoDB и размеры. Примеры:

      ibdata1:32M;ibdata2:32M:autoextend
      /abs/path/ibdata1:32M:autoextend
      innodb-dir/ibdata1:32M:autoextend
      

      Этот параметр вместе с backup_innodb_data_home_dir определяет, где файлы данных InnoDB сохранены в резервном репозитории. Любой путь к файлу, определенный здесь, взят относительно значения backup_innodb_data_home_dir (которое верно, даже если путь к файлу определяется в форме абсолютного пути, как /abs/path/ibdata1:32M:autoextend). Чтобы определить действительно абсолютные пути для файлов данных InnoDB в резервной копии, необходимо установить backup_innodb_data_home_dir = "" [пустая строка] в дополнение к использованию абсолютного пути для этой опции.

      Когда параметр не определяется, он наследует значение от innodb_data_file_path на поддержанном сервере. Если источник и место назначения указывают те же самые абсолютные пути, который ведут к тем же самым файлам, резервная копия отменяются.

      Значение параметра сохранено в файле backup-my.cnf как innodb_data_file_path, чтобы mysqlbackup мог понять структуру резервной копии, когда выполняет различные операции на резервной копии.

    • backup_innodb_log_group_home_dir= PATH

      Каталог, в соответствии с которым будут сохранены журналы InnoDB. Определите это значение только если вы хотите поместить журналы где-нибудь кроме местоположения по умолчанию (которое является backup-dir /datadir). Если значение параметра отличается от backup-dir /datadir, это сохранено в файле backup-my.cnf . Обратите внимание, что в то время, как можно определить каталог для хранения журналов, названия файлов журнала фиксируются и не реконфигурируемы.

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

    • backup_innodb_undo_directory= PATH

      Относительный или абсолютный путь к каталогу, где отдельные табличные пространства создаются для журналов отмены InnoDB во время резервной копии. Когда не указано, опция принимает то же самое значение, как backup_innodb_log_group_home_dir, определите эту опцию только если вы хотите поместить журналы в некоторое другое местоположение. Если значение параметра отличается от backup-dir /datadir, это сохранено в файле backup-my.cnf как innodb_undo_directory.

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

    • --with-timestamp

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

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

    20.5. Варианты метаданных

    Эти варианты управляют созданием метаданных о резервных копиях. Некоторые метаданные сохранены в резервном каталоге, другие метаданные сохранены в таблицах базы данных mysql.

    • --no-history-logging

      Выключает запись резервного прогресса и истории в регистрирующих таблицах. См. раздел 17.3.

      По умолчанию: сохранение истории позволено.

    • --comments=STRING

      Формат командной строки --comments=STRING
      ТипString

      Определяет последовательность комментария, которая описывает резервную копию. Окружите комментарии из нескольких слов соответствующими кавычками. Последовательность сохранена в файле meta/comments.txt в резервной копии. Например: --comments="Backup of HR data on 2010/12/10".

    • --comments-file=PATH

      Формат командной строки --comments-file=PATH
      ТипFile name

      Определяет путь к файлу, содержащему комментарий, описывающий резервную копию. Этот файл сохранен как meta/comments.txt в резервной копии. Например: --comments-file=/path/to/comments.txt.

      Эта опция перекрывает --comments, если обе определяются.

    20.6. Варианты сжатия

    Для обзора сжатия посмотрите раздел 4.3.4.

    • --compress

      Создайте резервную копию в сжатом формате. Для регулярного резервного копирования, среди всех механизмов хранения, поддержанных MySQL, сжаты только файлы данных формата InnoDB, и они имеют расширение .ibz после сжатия. Точно так же для однофайлового резервного копирования образа, только файлы данных формата InnoDB в образе резервной копии сжаты. Файлы журнала реле и двоичной регистрации сжаты и сохранены с расширением .bz, будучи включенными в сжатую резервную копию.

      Вы не можете использовать опцию --compress с --incremental-with-redo-log-only.

      По умолчанию: сжатие отключено.

    • --compress-method= ALGORITHM

      Формат командной строки --compress-method=ALGORITHM
      ТипEnumeration
      По умолчаниюlz4
      Допустимые значения

      zlib

      lz4

      lzma

      punch-hole

      none

      Определяет алгоритм для сжатия или позволяет поддержку InnoDB transparent page compression. Поддержанные аргументы и алгоритмы, которые они представляют:

      • lz4: LZ4 r109. Из трех алгоритмов сжатия, которые поддерживаются, этот самый эффективный, как правило, выдает самую короткую резервную копию и восстанавливает с самой низкой нагрузкой на CPU. См. lz4: Extremely Fast Compression algorithm для получения дополнительной информации, включая сравнение с другими алгоритмами сжатия.

      • lzma: LZMA 9.20. Из трех поддержанных алгоритмов сжатия это, как правило, обеспечивает самый высокий коэффициент сжатия, но это также намного более дорого с точки зрения значения CPU, чем другие два варианта. Таким образом мы не рекомендуем это для активных систем, а только для бездействующих баз данных, или где скорость I/O чрезвычайно низка.

      • zlib: ZLIB v1.2.3. Это промежуточно между другими поддержанными алгоритмами сжатия с точки зрения скорости и с точки зрения коэффициента сжатия. ZLIB был единственным алгоритмом сжатия, доступным для MySQL Enterprise Backup до версии 3.10.

      • punch-hole: (MySQL Enterprise Backup 8.0.13 и позже). Позволяет поддержку для transparent page compression таблиц InnoDB для директивных резервных копий, что означает, что когда целевая платформа для mysqlbackup делают копию или восстанавливает данные, поддерживая hole punching, mysqlbackup хранит соответствующие данные в странично сжатых файлах InnoDB, которые это передает.

        Ограничения: функция НЕ поддерживается в следующих случаях, для которых punched holes удалены из файлов InnoDB:

        • Для однофайлового резервного копирования файлов.

        • Для TTS, возрастающих, сжатых или зашифрованных резервных копий.

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

        • Для тех страниц файлов данных InnoDB, которые изменяются журналом отката в фазе apply-log .

        Когда опция активирована, но hole punching не работает, mysqlbackup выпускает предупреждающее сообщение после того, как операция закончена, например:

        WARNING: "Punch hole" operation failed.
        

        Или:

        WARNING: InnoDB datafiles in the backup are larger than in the source
                 because of missing sparse file support.
        

        Резервная копия может быть взята с --compress-method=punch-hole и затем быть восстановлена позже, не используя эту функцию, обратное также верно: резервная копия взята без использования --compress-method=punch-hole, но восстановлена позже уже с этой функцией.

        punch-hole это специальный аргумент с --compress-method для поддержки прозрачного сжатия страницы. --compress-method=punch-hole проигнорирован, когда используется вместе с любыми другими опциями сжатия mysqlbackup.

      • none: без сжатия.

      По умолчанию: lz4. Явно определяя значение кроме punch-hole через конфигурационный файл или командную строку, вы автоматически позволяете опцию --compress .

    • --compress-level=LEVEL

      Формат командной строки --compress-level=LEVEL
      ТипNumeric
      По умолчанию1
      Минимум0
      Максимум9

      Определяет уровень сжатия в пределах от 0 до 9: 0 выключает сжатие, 1 быстрейший вариант, 9 лучший (и самый медленный). Опция значащая только для сжатия, используя ZLIB или алгоритм LZMA, это проигнорировано когда любые другие алгоритмы выбраны опцией --compress-method.

      По умолчанию: 1 (слабое, но зато быстрое сжатие). Явно определение ненулевого значения через конфигурационный файл или командную строку автоматически позволяет опцию --compress .

    • --uncompress

      MySQL Enterprise Backup 8.0.20 и ранее: При использовании с copy-back, copy-back-and-apply-log, apply-log и apply-incremental-backup выполняет распаковку сжатой резервной копии во время операции (опция больше не нужна для MySQL Enterprise Backup 8.0.21 и позже).

      MySQL Enterprise Backup 8.0.18 и позже: При использовании с extract распаковывает файлы, которые извлечены из сжатого однофайлового резервного копирования файлов (опция не требуется для MySQL Enterprise Backup 8.0.21 и позже, когда применена опция --src-entry).

    20.7. Варианты инкрементного резервного копирования

    Для обзора возрастающих резервных копий и примеров использования для этих вариантов посмотрите разделы 4.3.3 и 5.1.3.

    Чтобы взять инкрементное резервное копирование, определите --incremental или --incremental-with-redo-log-only наряду с --backup-dir. В зависимости от того, использована --incremental или --incremental-with-redo-log-only, другие опции требуются или рекомендуются. Все данные InnoDB, измененные после определенного LSN (определен прямо или косвенно примененными опциями) копируются в инкрементное резервное копирование. MySQL Enterprise Backup 8.0.20 и ранее: чтобы восстановить инкрементное резервное копирование, определите --incremental (опция больше не требуется для MySQL Enterprise Backup 8.0.21 и позже).

    • --incremental[={page-track|full-scan|optimistic }]

      Формат командной строки --incremental
      ТипEnumeration
      По умолчаниюfull-scan
      Допустимые значения

      page-track

      full-scan

      optimistic

      Выполняя инкрементное резервное копирование, есть три возможных значения для этой опции:

      • page-track: MySQL Enterprise Backup 8.0.18 и позже: mysqlbackup ищет измененные страницы в файлах данных InnoDB, которые были изменены, начиная с последней резервной копии, используя функциональность отслеживания страницы на сервере, затем копирует их. Это потенциально самый быстрый путь mysqlbackup, чтобы создать возрастающие резервные копии. Даже с этим набором значений, функциональность отслеживания страницы используется только когда определенные требования удовлетворены, посмотрите здесь.

      • full-scan: mysqlbackup просматривает все файлы данных InnoDB в каталоге данных сервера, чтобы найти страницы, которые были изменены, начиная с последней резервной копии, и копирует их.

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

      По умолчанию: page-track, MySQL Enterprise Backup 8.0.18 и позже. Однако, если функциональность отслеживания страницы не может быть использована mysqlbackup по некоторым причинам (см. здесь), mysqlbackup выполняет резервную копию полного просмотра вместо этого, если не установлена опция --incremental или бросает ошибку, когда --incremental=page-track .

      MySQL Enterprise Backup 8.0.17 и ранее: резервная копия полного просмотра это метод по умолчанию для возрастающих резервных копий, который используется, если никакое значение не определяется для --incremental.

      Во время резервной копии опция --incremental также требует использования любой опции --incremental-base или --start-lsn . Только таблицы InnoDB поддерживаются с приращением. По умолчанию все не-InnoDB файлы включены в инкрементное резервное копирование. Чтобы исключить не-InnoDB данные в инкрементном резервном копировании, используйте --only-innodb .

      У значения для опции есть только значение, когда опция использует инкрементное резервное копирование.

      MySQL Enterprise Backup 8.0.20 и ранее : для операций copy-back-and-apply-log, copy-back и apply-log определяется, что связанная резервная копия --incremental (опция больше не требуется для MySQL Enterprise Backup 8.0.21 и позже).

    • --incremental-with-redo-log-only

      Определяет, что инкрементное резервное копирование должно быть создано, используя только журнал отката. У этого дополнительного типа инкрементного резервного копирования есть различные показатели производительности и эксплуатационные ограничения по сравнению с резервными копиями, созданными с опцией --incremental, см. здесь.

      Чтобы использовать эту опцию, также необходимо определить --incremental-base или --start-lsn. Точно так же, как с --incremental, только таблицы InnoDB поддерживаются с приращением. По умолчанию все не-InnoDB файлы включены в инкрементное резервное копирование. Чтобы исключить не-InnoDB данные в инкрементном резервном копировании, используйте опцию --only-innodb.

      Вы не можете использовать опцию --compress с --incremental-with-redo-log-only.

    • --incremental-base=mode :argument

      Формат командной строки --incremental-base=mode:argument
      ТипString

      Когда mysqlbackup восстанавливает данные, информация, чтобы выполнить возрастающие резервные копии, берется от метаданных в резервном каталоге, а не от опции --start-lsn. Это спасает вас от необходимости определить постоянно меняющееся, непредсказуемое значение LSN, делая последовательность возрастающих резервных копий. Вместо этого вы определяете способ определить местонахождение предыдущего резервного каталога через комбинацию mode: argument в синтаксисе опции. Альтернативы:

      • history:[last_backup | last_full_backup]

        Префикс history: сопровождаемый одним из двух возможных значений:

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

      • dir:directory_path

        Дополнительно: Вы определяете префикс dir: сопровождаемый аргументом пути к каталогу, который указывает на предыдущую директивную резервную копию. С первым инкрементным резервным копированием вы определяете каталог, содержащий полную директивную резервную копию, со вторым инкрементным резервным копированием вы определяете каталог, содержащий первую возрастающую директивную резервную копию и так далее.

    • --start-lsn=LSN

      Формат командной строки --start-lsn=LSN
      ТипNumeric

      В инкрементном резервном копировании определяет самое высокое значение LSN, включенное в предыдущую резервную копию. Можно получить это значение от вывода предыдущей операции резервного копирования или из таблицы backup_history, столбец end_lsn, для предыдущей операции резервного копирования. Всегда используется в сочетании с --incremental, не нужна, когда вы используете --incremental-base, не рекомендуется, когда вы используете --incremental-with-redo-log-only для возрастающих резервных копий.

      Никакие двоичные файлы журнала не копируются в инкрементное резервное копирование, если используется --start-lsn. Чтобы включить двоичные файлы журнала в течение периода, покрытого инкрементным резервным копированием, вместо --start-lsn примените --incremental-base, которая предоставляет необходимую информацию для mysqlbackup, чтобы гарантировать, что никакой промежуток не существует между данными журнала, включенными в предыдущую резервную копию и текущим инкрементным резервным копированием.

    • --incremental-backup-dir=PATH

      Дополнительно: определяет местоположение данных возрастающей директивной резервной копии. Создавая или восстанавливая возрастающую директивную резервную копию, опция служит той же самой функции, как --backup-dir для резервных копий и восстановления в целом, опция может на самом деле использоваться наравне с --backup-dir для директивных резервных копий. См. описание для --backup-dir.

      Для apply-incremental-backup опция определяет каталог инкрементного резервного копирования, данные которого используются, чтобы обновить директивную резервную копию, определенную --backup-dir.

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

    20.8. Частичная резервная копия и восстановление

    Чтобы выбрать определенные данные, которые будут поддержаны или восстановлены, используйте частичную резервную копию и опции, описанные в этой секции.

    Для обзора частичной резервной копии, а также примеров использования посмотрите разделы 4.3.5 и 5.1.4.

    • --include-tables=REGEXP

      Формат командной строки --include-tables=REGEXP
      ТипString

      Включайте для резервной копии или восстановления только те таблицы (Innodb и не-Innodb) чьи полностью полностью определенные имена (в форме db_name. table_name) соответствуют регулярному выражению REGEXP. Используемый синтаксис регулярного выражения является расширенной формой, определенной в стандарте POSIX 1003.2. Например, --include-tables=^mydb\.t[12]$ соответствует таблицам t1 и t2 базы данных mydb. В Unix-системах укажите регулярное выражение соответственно, чтобы предотвратить интерпретацию метасимволов оболочки. mysqlbackup бросает ошибку, когда опция используется без регулярного выражения.

      В то время как mysqlbackup понимает соглашение MySQL цитирования базы данных или имени таблицы обратными галочками (см. Schema Object Names), нет никакой потребности включать обратные галочки в регулярное выражение для --include-tables.

      Опция может также использоваться с backup-dir-to-image и image-to-backup-dir, чтобы выбрать таблицы, создавая или распаковывая образ резервной копии.

      mysqlbackup бросает ошибку, когда никакая таблица не соответствует регулярному выражению, определенному --include-tables.

      Когда используется вместе с --exclude-tables , --include-tables применяется сначала, заставляя mysqlbackup сначала выбирать все таблицы, определенные --include-tables, а затем исключает из набора таблицы, определенные --exclude-tables.

      Опция не может использоваться вместе с --include.

    • --exclude-tables=REGEXP

      Формат командной строки --exclude-tables=REGEXP
      ТипString

      Исключить для резервной копии или восстановления все таблицы (Innodb и не-Innodb) чьи полностью полностью определенные имена (в форме db_name. table_name) соответствуют регулярному выражению REGEXP. Синтаксис регулярного выражения это расширенная форма, определенная в стандарте POSIX 1003.2. Например, --exclude-tables=^mydb\.t[12]$ соответствует таблицам t1 и t2 базы данных mydb. В Unix-системах укажите регулярное выражение соответственно, чтобы предотвратить интерпретацию метасимволов оболочки. mysqlbackup бросает ошибку, когда опция используется без регулярного выражения.

      Так как mysqlbackup понимает соглашение MySQL цитирования базы данных или имени таблицы обратными галочками (см. Schema Object Names), нет никакой потребности включать обратные галочки в регулярное выражение для --exclude-tables.

      Опция может также использоваться с backup-dir-to-image и image-to-backup-dir, чтобы выбрать таблицы, создавая или распаковывая образ резервной копии.

      Опция не может использоваться вместе с --include.

      Когда используется вместе с --include-tables , --include-tables применяется сначала, заставляя mysqlbackup сначала выбрать все таблицы, определенные --include-tables, а затем исключить из набора таблицы, определенные --exclude-tables.

    • --only-known-file-types

      По умолчанию все файлы в подкаталогах базы данных в соответствии с каталогом данных сервера включены в резервную копию (см. таблицу 1.1). Если указана опция --only-known-file-types, mysqlbackup поддерживает только те типы файлов, которые являются файлами данных для MySQL или его встроенных механизмов хранения, которые кроме файлов ibdata* имеют следующие расширения:

      • .ARM: Метаданные таблицы ARCHIVE.

      • .ARZ: Данные таблицы ARCHIVE.

      • .CSM: Метаданные таблицы CSV.

      • .CSV: Данные таблицы CSV.

      • .ibd: Табличное пространство InnoDB, созданное с использованием режима file-per-table.

      • .MRG: Ссылки механизма хранения Merge на другие таблицы.

      • .MYD: Данные таблицы MyISAM.

      • .MYI: Индексы таблицы MyISAM.

    • --only-innodb

      Поддержать только файлы данных InnoDB и файлы журнала. Исключены все файлы, созданные другими механизмами хранения. Как правило, используется, когда не надо копировать файлы MyISAM.

      Опция не совместима с --slave-info.

      По умолчанию: резервные копии включают файлы от всех механизмов хранения.

    • --use-tts[={with-minimum-locking|with-full-locking }]

      Формат командной строки --use-tts[={with-minimum-locking|with-full-locking}]
      ТипEnumeration
      По умолчаниюwith-minimum-locking
      Допустимые значения

      with-minimum-locking

      with-full-locking

      Разрешает выборочную резервную копию таблиц InnoDB, используя transportable tablespaces (TTS). Это должно использоваться вместе с --include-tables и --exclude-tables для отбора таблиц InnoDB InnoDB, которые будут поддержаны, регулярными выражениями. Использование TTS для резервных копий предлагает следующие преимущества:

      • Резервные копии могут вернуться к иному серверу.

      • Системное табличное пространство не поддерживается, экономя ресурсы I/O и дисковое пространство.

      • Непротиворечивостью данных таблиц управляет MySQL Enterprise Backup.

      Однако, у опции есть следующие ограничения:

      • Отдельный раздел не может быть выборочно поддержан или восстановлен. Таблицы, отобранные --include-tables и --exclude-tables, всегда поддерживаются или восстанавливаются полностью.

      • Может сделать только копию таблиц, которые сохранены в их собственных отдельных табличных пространствах (то есть, таблиц, составленных с опцией innodb_file_per_table).

      • Таблицы не-InnoDB не поддерживаются.

      • MySQL Enterprise Backup 8.0.20 и ранее: зашифрованные таблицы InnoDB никогда не включаются (предупреждение выпущено в файле журнала каждый раз, когда зашифрованная таблица InnoDB, которая соответствует критериям отбора, пропущена).

      • Не может использоваться для возрастающих резервных копий.

      • Не включает двоичную регистрацию или журнал реле в резервную копию.

      См. приложение B для некоторых более незначительных ограничений.

      Есть два возможных значений для опции:

      • with-minimum-locking: Поддерживаются горячие копии отобранных таблиц, таблицы тогда блокированы в режиме только для чтения в то время, как журнал отката (только часть, содержащая соответствующие изменения, внесенные после горячего резервного копирования) включается в резервную копию. Проигнорированы любые таблицы, составленные во время фазы блокировки.

      • with-full-locking: Отобранные таблицы блокированы в режиме только для чтения в то время, как они поддерживаются. Журнал отката не включен в резервную копию. Проигнорированы любые таблицы, составленные во время фазы блокировки.

        Из-за известной проблемы, создавая резервную копию, используя TTS для сервера, содержащего таблицы с соединением форматов файлов Antelope и Barracuda, НЕ применяют полную блокировку на таблицах.

      По умолчанию: with-minimum-locking.

      Чтобы использовать --use-tts, дополнительные привилегии требуются для пользователя, от которого mysqlbackup соединяется с сервером, посмотрите раздел 4.1.2.

      Есть некоторые особые требования для восстановления резервных копий, созданных с --use-tts , см. раздел 5.1.5.

    • --rename= old_table_name to new_table_name

      Переименуйте единственную таблицу, когда она будет выбрана --include-tables или --exclude-tables (или вместе), чтобы вернуть базе данных из резервной копии, созданной, используя --use-tts. Таблица old_table_name переименована в new_table_name. Отметьте что, используя опцию:

      • --include-tables или --exclude-tables (или вместе) должны определить, что одна и только одна таблица восстанавливается, если в резервной копии более одной таблицы, когда применяется опция --rename или восстановление потерпит неудачу.

      • old_table_name и new_table_name могут быть полностью квалифицированными (содержащими имена базы данных, в форме old_db_name. old_tb_name и new_db_name. new_tb_name) или нет. При помощи полностью квалифицированных имен таблица может быть восстановлена в базу данных, отличающуюся от ее оригинальной. Если база данных, определенная с new_db_name, не существует на целевом сервере, она будет создан во время процесса восстановления. Регулярные выражения не приняты в аргументе опции.

      • Восстановление терпит неудачу, если old_table_name не соответствует таблице, определенной, используя --include-tables или --exclude-tables (или вместе) или если new_table_name уже существует в целевой базе данных.

      • Требования, перечисленные в разделе 5.1.5 применяются.

      См. раздел 5.1.5 для получения дополнительной информации о выборчном восстановлении и для примера переименования таблицы.

    Старые опции частичных резервных копий

    Информация в этом подразделе только для использования устаревшей опции --include. Для создания частичных резервных копий используйте --include-tables и --exclude-tables .

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

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

    • --include=REGEXP

      Эта опция для фильтрации таблиц InnoDB для резервной копии. Полностью определенные имена таблиц InnoDB сравнены с регулярным выражением, определенным опцией. Если REGEXP соответствует db_name. table_name, таблица включена. Используемый синтаксис регулярного выражения является расширенной формой, определенной в стандарте POSIX 1003.2. Например, --include=mydb\.t[12] соответствует таблицам t1 и t2 в базе данных mydb. mysqlbackup бросает ошибку, когда опция используется без регулярного выражения.

      Эта опция только относится к таблицам InnoDB, составленным с опцией innodb_file_per_table (по умолчанию для MySQL 5.6 и выше) в этом случае таблицы находятся в отдельных файлах, которые могут быть включены или исключены из резервной копии. Все таблицы в системном табличном пространстве InnoDB всегда поддерживаются.

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

      По умолчанию: поддерживает все таблицы InnoDB.

      Эта опция не фильтрует не-InnoDB таблицы.

    • --use-tts[={with-minimum-locking|with-full-locking }]

      Позвольте выборочную резервную копию таблиц InnoDB, используя transportable tablespaces (TTS). Это должно использоваться вместе с --include, которая выбирает таблицы InnoDB, которые будут поддержаны регулярным выражением. Использование TTS для резервных копий предлагает следующие преимущества:

      • Резервные копии могут вернуться к иному серверу.

      • Системное табличное пространство не поддерживается, экономя ресурсы I/O и дисковое пространство.

      • Непротиворечивостью данных таблиц управляет MySQL Enterprise Backup.

      Посмотрите важные обсуждения здесь ограничений с использованием --use-tts.

      Есть два возможных значения для опции:

      • with-minimum-locking: Поддерживаются горячие копии выбранных таблиц, таблицы тогда блокированы в режиме только для чтения в то время, как журнал отката (только часть, содержащая соответствующие изменения, внесенные после горячего резервного копирования), включается в резервную копию. Проигнорированы любые таблицы, составленные во время фазы блокировки.

      • with-full-locking: Отобранные таблицы блокированы в режиме только для чтения в то время, как они поддерживаются. Журнал отката не включен в резервную копию. Проигнорированы любые таблицы, составленные во время фазы блокировки.

      По умолчанию: работа с минимальными блокировками.

      Есть некоторые особые требования для восстановления резервных копий, созданных с --use-tts, см. раздел 5.1.

    20.9. Варианты однофайлового резервного копирования

    Эти варианты связаны с однофайловым резервным копированием. Вы используете их в сочетании с командами backup-to-image , image-to-backup-dir, backup-dir-to-image, copy-back-and-apply-log, list-image и extract (не все варианты применимы ко всем этим командам). Для примеров использования посмотрите раздел 4.3.1.

    • --backup-image= IMAGE

      См. описание опции в разделе 20.4.

    • --src-entry=STRING

      Формат командной строки --src-entry=STRING
      ТипPath name

      Определяет файлы или каталоги, пути которых содержат STRING, которая будет извлечена из копии. Эта опция используется с extract и image-to-backup-dir. Произвольно можно также определить --dst-entry, чтобы извлечь файл или каталог к местоположению, отличающемуся от его оригинального пути.

      Например: src-entry=d1/f2 извлечет только один файл f2 в то время, как src-entry=d1/ извлекает все дерево каталогов для d1 (обратите внимание на / в конце аргумента, без которого все файлы или каталоги, содержащие последовательность d1, в их путях будут извлечены).

      По умолчанию: все записи извлечены.

      • Следующие пункты всегда извлекаются из резервной копии, независимо от --src-entry (и местоположения их извлечения не затронуты --dst-entry):

        • Файл backup-my.cnf.

        • Каталог datadir (который содержит только пункты, соответствовавшие --src-entry).

        • Каталог meta, который содержит файл backup_variables.txt, файл журнала для операции по извлечению, а также пункты, соответствовавшие --src-entry.

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

    • --dst-entry=PATH

      Формат командной строки --dst-entry=PATH
      ТипPath name

      Используется, чтобы извлечь файл или каталог к определенному пользователями пути. Использование этой опции требует определения --src-entry. Эта опция определяет путь назначения для входа, выбранного из образа резервной копии --src-entry. Запись может указать на единственный файл или единственный каталог. Например, чтобы восстановить файл комментариев из образа резервной копии и сохранить его как /tmp/my-comments.txt, используйте команду:

      mysqlbackup --src-entry=meta/comments.txt \
                  --dst-entry=/tmp/my-comments.txt \
                  --backup-image=/var/myimage.bkiextract
      

      Точно так же, чтобы извлечь все содержание datadir/pets/ как /pets-extracted/, используйте команду:

      mysqlbackup --src-entry=datadir/pets/ \
                  --dst-entry=/pets-extracted/ \
                  --backup-image=/var/myimage.bkiextract
      

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

      В случае, если аргумент в --src-entry соответствует многим файлам или каталогам, они все извлечены в каталог, путь к которому относительно каталога назначения дан аргументом --dst-entry (если аргумент не определяет абсолютный путь).

      По умолчанию: оригинальные пути используются, чтобы создать файлы под каталогом назначения.

    • --sbt-database-name=NAME

      Формат командной строки --sbt-database-name=NAME
      ТипString
      По умолчаниюMySQL

      Для резервных копирований на магнитную ленту эта опция может использоваться в качестве подсказки Media Management Software (MMS). Это имя не имеет никакого отношения к именам базы данных MySQL. Это термин, использованный MMS. Посмотрите раздел 4.3.1.2 .

    • --sbt-lib-path=PATH

      Формат командной строки --sbt-lib-path=PATH
      ТипFile name

      Путь библиотеки SBT, использовавшейся программным обеспечением, которое справляется с резервными копированиями на магнитную ленту. Если это не определяется, определенные для системы методы поиска используются, чтобы определить местонахождение libobk.so (UNIX) или orasbt.dll (Windows). См. раздел 4.3.1.2.

    • --sbt-environment=VAR =value,...

      Формат командной строки --sbt-environment=VAR1=value1[,VAR2=value2[,...]] SBT API provider)
      ТипString

      Передает определенные для продукта переменные окружения в Oracle Secure Backup или другой SBT-совместимый продукт управления как альтернатива урегулированию и сбросу переменных окружения прежде и после каждого вызова mysqlbackup.

      Параметр этой опции это список разделенных запятой значений пар ключ/значение, используя синтаксис, подобный инструменту RMAN для Oracle Database. Например, --sbt-environment=VAR1=val1,VAR2=val2, VAR3=val3.

      Консультируйтесь с документацией для своего резервного продукта управления, чтобы видеть, какой из его особенностей можно управлять через переменные окружения. Например, продукт Oracle Secure Backup определяет переменные окружения, например, OB_MEDIA_FAMILY, OB_DEVICE и OB_RESOURCE_WAIT_TIME. Вы могли бы установить такие переменные с mysqlbackup определив опцию как --sbt-environment="OB_MEDIA_FAMILY=my_mf,OB_DEVICE=my_tape".

      Если последовательность аргумента содержит какой-либо пробел или специальные символы, признанные командным процессором, заключите всю последовательность аргумента в кавычки. Чтобы экранировать знак = или запятую, используйте символ \. Например, --sbt-environment="VAR1=multiple words,VAR2=<angle_brackets>, VAR3=2+2\=4".

    • --disable-manifest

      Отключает создание файлов декларации для операции резервного копирования, которые являются backup_create.xml и backup_content.xml в подкаталоге meta.

    20.10. Опции масштабируемости и производительности

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

    • --number-of-buffers=num_buffers

      Формат командной строки --number-of-buffers=NUMBER
      ТипNumeric
      По умолчанию14
      Минимум1

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

      Используйте большое количество для интенсивной CPU-обработки, например, резервная копия, особенно использующая сжатие. Используйте низкое количество для интенсивной дисковой обработки, такой как восстановление резервной копии. Это значение должно быть, по крайней мере, настолько же высоко, как количество потоков чтения или записи, в зависимости от типа операции.

      По умолчанию: сейчас 14.

      Для операций по сжатию или инкрементному резервному копированию размер буфера немного больше, чем 16 МБ, чтобы приспособить заголовки.

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

      Сжатая резервная копия, сжатое однофайловое резервное копирование и операции apply-log требуют одного дополнительного буфера для каждого потока процесса.

      Если вы изменяете количество потоков, можно экспериментировать с изменением этого значения так, чтобы это было немного больше, чем общее количество потоков, определенных другими вариантами. Посмотрите разделы 13.1 и 13.2 для дополнительного совета о рекомендуемых комбинациях для этой и других связанных с работой возможностей для различных аппаратных конфигураций, таких как устройства хранения данных не-RAID или RAID.

    • --read-threads=num_threads

      Формат командной строки --read-threads=NUMBER
      ТипNumeric
      По умолчанию1
      Минимум1
      Максимум15

      Определяет количество потоков, чтобы использовать для чтения данных с диска. Опция относится к этим видам операций: copy-back, copy-back-and-apply-log, extract, backup и backup-and-apply-log. Если вы определяете значение 0, оно тихо станет 1. Максимум равняется 15. Если вы поставляете отрицательную величину, она тихо станет 15. Для apply-log на резервных каталогах и фазе apply-log операций copy-back-and-apply-log, backup-and-apply-log или apply-incremental-backup, количество потоков чтения всегда 1 независимо от этой опции. Посмотрите разделы 13.1 и 13.2 для совета о рекомендуемых комбинациях значений для --read-threads , --process-threads и --write-threads для различных аппаратных конфигураций, таких как RAID или устройства хранения данных не-RAID.

      По умолчанию: 1.

    • --process-threads=num_threads

      Формат командной строки --process-threads=NUMBER
      ТипNumeric
      По умолчанию6
      Минимум1
      Максимум15

      Определяет количество потоков, чтобы использовать для обработки данных, включая сжатие и распаковку, шифрование и декодирование, операции apply-log, упаковку и извлечение образов резервной копии. Для backup-and-apply-log, copy-back-and-apply-log и apply-incremental-backup --process-threads определяет число рабочих потоков для фазы apply-log. Опция проигнорирована для тех операций, которые не включают обработку данных, например, copy-back (если декодирование или распаковка не включаются), backup-dir-to-image или операция резервного копирования, которая использует опцию --incremental-with-redo-log-only.

      По умолчанию: 6 для всех операций, к которым опция применима.

      Если вы определяете значение 0, оно тихо станет 1. Максимум равняется 15. Если вы поставляете отрицательную величину, она тихо станет 15. См. разделы 13.1 и 13.2 для совета о рекомендуемых комбинациях значений для --read-threads , --process-threads и --write-threads для различных аппаратных конфигураций, таких как RAID или устройства хранения данных не-RAID.

    • --write-threads=num_threads

      Формат командной строки --write-threads=NUMBER
      ТипNumeric
      По умолчанию1
      Минимум1
      Максимум15

      Определяет количество потоков, чтобы использовать для записи данных на диск. Эта опция относится к этим видам операций: copy-back, copy-back-and-apply-log, extract, backup-to-image, backup и backup-and-apply-log. Много потоков записи поддерживается для любой цели записи, которая позиционируется, --write-threads вынуждена быть 1 только, когда цель не позиционируема (например, когда резервная копия написана на ленту, stdout или в облако). Опция проигнорирована, когда используется с другими операциями однофайлового резервного копирования как list-image или validate.

      Если вы определяете значение 0, оно тихо станет 1. Максимум равняется 15. Если вы поставляете отрицательную величину, она тихо станет 15. Для операции apply-log на резервных каталогах и фазы apply-log для copy-back-and-apply-log, backup-and-apply-log или apply-incremental-backup количество потоков записи всегда 0 независимо от этой опции. Посмотрите разделы 13.1 и 13.2 для совета о рекомендуемых комбинациях значений для --read-threads, --process-threads и --write-threads для различных аппаратных конфигураций, таких как RAID или устройства хранения данных не-RAID.

      По умолчанию: 1.

    • --limit-memory=MB

      Формат командной строки --limit-memory=MB
      ТипNumeric
      По умолчанию100 для apply-log (без распаковки), 300 для других действий
      Минимум0
      Максимум999999
      Единица измерения megabyte

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

      По умолчанию: 100 для apply-log без распаковки, 400 для всех других операций (в мегабайтах).

      Предел памяти, определенный этой опцией, ограничивает количество буферов 16 МБ, доступных для многопоточной обработки. Например, с пределом 400 МБ максимальное количество буферов равняется 25 (за исключением облачной резервной копии, для которой необходима дополнительная память, и максимальное количество буферов равняется 18). Если дополнительные буфера требуются, потому что вы увеличили значения для --read-threads, --process-threads, --write-threads и/или --number-of-buffers, увеличьте значение соответственно.

    • --sleep=MS

      Формат командной строки --sleep=MS
      ТипNumeric
      По умолчанию0
      Единица измерения millisecond

      Определите число в миллисекундах, чтобы спать после копирования определенного количества данных из таблиц InnoDB. Каждый блок данных это 1024 страницы данных InnoDB, как правило, в общей сложности 16 МБ. Это должно ограничить издержки CPU и I/O на сервере базы данных.

      По умолчанию: 0 (не спать).

    • --no-locking

      Отключает все блокировки во время резервной копии (см. здесь). Это может использоваться, чтобы поддержать сервер с меньшим количеством разрушений в нормальной обработке базы данных. Могли быть несоответствия в InnoDB и не-InnoDB данных, если какие-либо изменения внесены в то время, как те файлы поддерживаются.

    • --lock-wait-timeout

      Формат командной строки --lock-wait-timeout
      Удалена8.0.16
      ТипNumeric
      По умолчанию60
      Минимум1
      Единица измерения second

      MySQL Enterprise Backup 8.0.16 и позже: опция больше не поддерживается.

      MySQL Enterprise Backup 8.0.15 и ранее: укажите тайм-аут в секундах для FLUSH TABLES WITH READ LOCK, который mysqlbackup делает во время заключительного этапа резервной копии, чтобы временно поместить базу данных в статус только для чтения. Если тайм-аут превышен, запрос прерывается и блокировка на таблицах выпущена, чтобы запросы могли быть выполнены. mysqlbackup тогда повторяет запрос и продолжает резервную копию. Тайм-аут предотвращает случай, в котором долгий запрос на сервере подвешивает FLUSH TABLES WITH READ LOCK и в конечном счете сбивает сервер. По умолчанию 60. Минимум 1.

    • --page-reread-time=MS

      Формат командной строки --page-reread-time=MS
      ТипNumeric
      По умолчанию100
      Единица измерения millisecond

      Интервал в миллисекундах, который mysqlbackup ждет прежде, чем перечитать страницу, которая не проходит тест контрольной суммы. Занятый сервер мог писать страницу одновременно с чтением ее mysqlbackup. Может быть числом с плавающей запятой, такое как 0.05 (50 микросекунд). Самое лучшее разрешение составляет 1 микросекунду, но это может быть хуже на некоторых платформах. По умолчанию 100 миллисекунд (0.1 секунды).

    • --page-reread-count=retry_limit

      Формат командной строки --page-reread-count=number
      ТипNumeric
      По умолчанию500

      Максимальное количество попыток перечитывания, когда страница не проходит тест контрольной суммы. Занятый сервер мог писать страницу одновременно с ее чтением mysqlbackup. Если та же самая страница проваливает много тестов контрольной суммы последовательно с паузой на основе --page-reread-time, резервная копия терпит неудачу. По умолчанию 500.

    • --on-disk-full={abort|abort_and_remove|warn}

      Формат командной строки --on-disk-full=option
      ТипEnumeration
      По умолчаниюabort
      Допустимые значения

      abort

      warn

      abort_and_remove

      Определяет поведение, когда процесс резервного копирования сталкивается с полным диском. Эта опция только для операций резервного копирования ( backup, backup-and-apply-log и backup-to-image).

      • abort: Резервная копия аварийно прекращает работу, не удаляя резервный каталог. Диск остается полным.

      • abort_and_remove: Резервная копия аварийно прекращает работу и удаляет резервный каталог.

      • warn: Пишет предупреждающее сообщение каждые 30 секунд и повторяет резервную копию, пока дисковое пространство не станет доступно.

      По умолчанию: abort.

    • --skip-unused-pages

      Пропустить неиспользованные страницы в табличных пространствах, поддерживая таблицы InnoDB. Эта опция применима к backup и backup-to-image , но не к возрастающим резервным копиям. Опция проигнорирована backup-and-apply-log.

      Обратите внимание на то, что резервные копии, созданные с --skip-unused-pages, не могут быть восстановлены, используя copy-back-and-apply-log.

      Неиспользованные страницы это свободные страницы, часто вызываемые большим объемом удаления данных. Пропуская неиспользованные страницы во время резервных копий, эта опция может уменьшить размеры резервных копий и таким образом необходимое дисковое пространство и ресурсы I/O для операций. Однако, последующая операция apply-log на резервных копиях займет больше времени, поскольку неиспользованные страницы вставляются назад в таблицы во время операций.

    • --skip-binlog

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

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

      • Если ресурсные или исполнительные проблемы возникают.

      • MySQL Enterprise Backup 8.0.18 и ранее: если какие-либо двоичные файлы журнала отсутствуют на сервере, при этом надо избежать ошибки для недостающих файлов.

      MySQL Enterprise Backup 8.0.19 и позже: опция делает пропуск двочного журнала не только для операции по актуальной резервной копии, но также и для всех последующих возрастающих резервных копий, которые основаны на актуальной резервной копии.

      MySQL Enterprise Backup 8.0.19 и позже: Когда инкрементное резервное копирование восстановлено с --skip-binlog, mysqlbackup переименовывает любые файлы двоичного журнала, которые были уже восстановлены на сервере, добавив к ним расширение .old.

    • --skip-relaylog

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

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

      Если пользователь будет выполнять FLUSH LOGS в то время, как резервная копия происходит для точной копии, процесс резервного копирования потерпит неудачу. Используйте --skip-relaylog, если вы ожидаете FLUSH LOGS во время резервной копии и нет необходимости включать журнал реле в резервную копию.

    • --no-redo-log-archive

      MySQL Enterprise Backup 8.0.17 и позже: Пропустить архивирование журнала отката на сервере во время резервной копии, используется по умолчанию. Опция не имеет никаких эффектов для операций кроме резервных копий. См. главу 7.

    • --skip-final-rescan

      MySQL Enterprise Backup 8.0.16 и позже: пропустите заключительный перепросмотр для таблиц InnoDB, которые были изменены операциями DDL, который, как предполагается, происходит после того, как mysqlbackup блокирует базу данных около конца операции резервного копирования. Это потенциально сокращает продолжительность блокировки и уменьшает воздействие резервной копии на нормальное функционирование сервера, особенно когда много таблиц поддерживаются.

      MySQL Enterprise Backup 8.0.15 и ранее: пропустите заключительный перепросмотр для таблиц InnoDB, которые были изменены операциями DDL, который происходит после того, как база данных была блокирована около конца операции резервного копирования. Это потенциально сокращает продолжительность блокировки и уменьшает воздействие резервной копии на нормальное функционирование сервера, особенно когда много таблиц поддерживаются.

      Эта опция может вызвать неполную или непоследовательную резервную копию, если во время операции резервного копирования операции DDL выполняются на каких-либо таблицах InnoDB, табличных пространствах file-per-table вне каталога данных MySQL (то есть, любых таблицах InnoDB, созданных с опцией DATA DIRECTORY).

      Опция проигнорирована для резервных копий, используя --incremental-with-redo-log-only и не для операций резервного копирования.

    • --optimistic-time[= DATE-TIME]

      Формат командной строки --optimistic-time=DATE-TIME
      ТипString
      По умолчаниюnow

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

      Принятые форматы для определения опции включают:

      • now: Это включает все таблицы в оптимистическую фазу процесса резервного копирования. Это значение по умолчанию для опции, когда никакое значение не определяется.

      • {Number}{Unit}: Указывает оптимистическое время как время в определенной продолжительности в прошлое. {Unit} может быть одним из years, months, hours и minutes. Некоторые примеры для последовательностей опции в этом формате включают: 5years, 2days, 13months, 23hours и 35minutes.

      • Формат даты и времени в любой из следующих форм: YYMMDD, YYYYMMDD, YYMMDDHHMMSS, YYYYMMDDHHMMSS, YY-MM-DD, YYYY-MM-DD, YY-MM-DD HH.MM.SS или YYYYMMDDTHHMMSS (здесь T это именно символ T).

      Когда optimistic-time и optimistic-busy-tables используются и вступают в конфликт при определении, какие таблицы должны быть поддержаны в оптимистической фазе, optimistic-busy-tables имеет приоритет перед optimistic-time.

    • --optimistic-busy-tables= REGEXP

      Формат командной строки --optimistic-busy-tables=REGEXP
      ТипString

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

      MySQL Enterprise Backup бросит ошибку, если опция будет использоваться, но никакое регулярное выражение не поставляется.

      Когда вместе используются optimistic-time и optimistic-busy-tables, причем вступают в конфликт при определении, какие таблицы должны быть оптимистичными , optimistic-busy-tables имеет приоритет перед optimistic-time.

    • --free-os-buffers

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

      По умолчанию: Автоматическая синхронизация отключена.

    20.11. Опции журналирования сообщений

    mysqlbackup пишет важную информацию о прогрессе и ошибках в stderr. Информация часто очень ценна для того, чтобы разыскать проблемы, которые происходят во время операции. Начиная с MySQL Enterprise Backup 3.9, вывод stderr также сохранен в файле журнала по умолчанию (для большинства действий mysqlbackup), чтобы к информации об ошибке можно было легко получить доступ в любом процессе отладки.

    Сообщение, регистрирующее работы, например, tee обрабатывает на подобной Unix системе, в которой вывод программы разделяется, чтобы быть показанным и сохраненным в файл. Файл журнала называют в следующем формате: MEB_timestamp _operation.log, где operation действие mysqlbackup (например, backup, apply-log и т.д.), timestamp это дата и время, в которое выполнено действие. Вот некоторые примеры названий файлов журнала:

    MEB_2013-06-24.16-32-43_backup.log
    MEB_2013-06-28.11-07-18_apply_log.log
    MEB_2013-06-29.10-08-06_list_image.log
    

    Следующие опции управляют сообщением, регистрирующим функцию:

    • --skip-messages-logdir

      Пропустите регистрацию сообщения. Регистрация включена по умолчанию (за исключением list-image и validate ) и это выключено этой опцией.

    • --messages-logdir=path

      Формат командной строки --messages-logdir=PATH
      ТипDirectory name
      По умолчаниюbackup_dir/meta

      Определяет путь существующего каталога для хранения сообщения. Если указанный каталог не существует, регистрация сообщения возвращает сообщение об ошибке. Когда эта опция опущена, каталог по умолчанию backup_dir /meta, где backup_dir каталог, определенный --backup-dir.

      Используйте эту опцию, чтобы включить сообщение для list-image и validate. Регистрация сообщения выключена по умолчанию для этих двух операций, потому что они не изменяют файлов, и регистрация сообщения обычно не требуется для их отладки. И потому что путь по умолчанию backup_dir/meta не значащий для этих двух операций, эта опция требуется для включения регистрации сообщения и для поставки пути каталога, в котором можно записать файл журнала. Однако, если также задана опция --skip-messages-logdir, она имеет приоритет и регистрация сообщения пропускается.

    Следующее это некоторые примеры, показывающие, как регистрацией сообщения управляют.

    Это создает файл журнала для операции backup в каталоге /home/backup_dir/meta из-за настроек по умолчанию:

    mysqlbackup -uroot --port=3306 --backup-dir=/home/backup_dir backup
    

    Это пропускает сообщение для действия backup:

    mysqlbackup -uroot --port=3306 --backup-dir=/home/backup_dir \
                --skip-messages-logdir backup
    

    Это создает файл журнала для действия apply-log в существующем каталоге /home/teelog_dir вместо местоположения по умолчанию:

    mysqlbackup -uroot --port=3306 --backup-dir=/home/backup_dir \
                --messages-logdir=/home/teelog_dir apply-log
    

    Это создает файл журнала для операции list-image в существующем каталоге /home/teelog_dir:

    mysqlbackup -uroot --port=3306 --backup-image=/backup/my.mbi \
                --messages-logdir=/home/teelog_dir list-image
    

    20.12. Опции отчета о выполнении работ

    Есть две возможности для управления функцией сообщения прогресса mysqlbackup: --show-progress и --progress-interval:

    • --show-progress[={stderr|stdout|file:FILENAME| fifo:FIFONAME|table|variable}]

      Формат командной строки --show-progress[=destinations]
      ТипEnumeration
      Допустимые значения

      stderr

      stdout

      file:FILENAME

      fifo:FIFONAME

      table

      variable

      Опция приказывает mysqlbackup периодически производить короткие отчеты о выполнении работ, известные как индикаторы хода выполнения.

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

      • stderr: Индикаторы хода выполнения посылают в стандартный поток сообщений об ошибках. Отчет включен в сообщение INFO от mysqlbackup с меткой времени. Например:

        130607 12:22:38 mysqlbackup: INFO: Progress: 191 of 191 MB; state: Completed
        
      • stdout: Индикаторы хода выполнения посылают в поток стандартного вывода. Единственный символ новой строки печатается после каждого индикатора хода выполнения.

      • file:FILENAME: Индикаторы хода выполнения посылают в файл. Каждый новый отчет о выполнении работ переписывает файл, и файл содержит новый индикатор хода выполнения, сопровождаемый единственным символом новой строки.

      • fifo:FIFONAME: Индикаторы хода выполнения посылают в файловую систему FIFO. Единственный символ новой строки печатается после каждого индикатора хода выполнения.

        Если нет никакого процесса чтения FIFO, процесс mysqlbackup висит в конце выполнения.

      • table: Индикаторы хода выполнения посылают в таблицу mysql.backup_progress. Это требует связи с сервером MySQL, поэтому работает только, поддерживая работающий экземпляр MySQL. mysqlbackup сначала добавляет одну строку отчета о выполнении работ к таблице mysql.backup_progress, затем обновляет ее с последним индикатором хода выполнения. Индикатор хода выполнения сохранен в колонке current_status таблицы.

        MySQL Enterprise Backup 8.0.15 и ранее: Если резервная копия блокирует экземпляр MySQL (например, через FLUSH TABLES WITH READ LOCK), отчеты о выполнении работ не поставляются таблице mysql.backup_progress до разблокировки.

      • variable: Индикаторы хода выполнения посылают в системную переменную backup_progress.

        Системная переменная backup_progress не определяется для MySQL Server. Пользователи должны создать свой собственный плагин, чтобы определить переменную. Посмотрите The MySQL Plugin API.

      Когда нет никакого аргумента, определенного для --show-progress, индикаторы хода выполнения посылают в stderr.

      О прогрессе можно сообщить в несколько мест назначения, определив --show-progress несколько раз в командной строке. Например, следующая командная строка сообщает о прогрессе команды резервного копирования в stderr и в файл meb_output:

      mysqlbackup --show-progress --show-progress=file:meb_output \
                  --backup-dir=/full-backup backup
      

      Индикаторы хода выполнения это короткие последовательности, которые указывают, как далеко зашло выполнение действия mysqlbackup. Индикатор хода выполнения состоит из одного или более маркеров, которые измеряют прогресс операции. Например:

      Progress: 100 of 1450 MB; state: Copying .ibd files
      

      Это показывает, что 100 мегабайтов из в общей сложности 1450 мегабайтов были скопированы или обработаны до сих пор, и mysqlbackup в настоящее время копирует файлы данных InnoDB (файлы .ibd).

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

      • Полный маркер данных: Это всегда первый маркер в индикаторе хода выполнения. Это находится в формате:

        DATA of TOTAL UNIT
        

        DATA и TOTAL это десятичные целые числа unsigned, а UNIT MB (мегабайты), KB (килобайты) или байты (1MB=1024KB, 1KB=1024 байт).

        У полного маркера данных есть два немного отличающихся значения в зависимости от действия mysqlbackup:

        • Объем данных скопирован или обработан и общая сумма данных, которые будут скопированы или обработаны mysqlbackup:

          Progress: 200 of 1450 MB
          

          Когда операция для, например, backup, индикатор означает, что 200 МБ скопировано из 1450 МБ. Но когда операция для, например, validate или incremental это означает, что 200 МБ обработано из 1450 МБ.

        • Общая сумма данных скопированных или обработанных и оценка для общего количества, которое будет скопировано к концу операции. Предполагаемое общее количество обновляется согласно данным по серверу как выполнение прогресса команды.

          Для некоторых операций, например, backup, невозможно знать точно в начале выполнения, сколько данных будет скопировано или обработано. Поэтому полный маркер данных показывает предполагаемую сумму полных данных для резервной копии. Оценка обновляется во время выполнения команды. Например:

          Progress: 200 of 1450 MB
          

          сопровождается:

          Progress: 200 of 1550 MB
          

          когда 100 МБ данных добавляются на сервере.

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

      • Маркер сжатия: Это указывает на скользящее среднее число коэффициента сжатия, который определяется для каждого сжатого блока данных как (orig_size-compressed_size)/orig_size:

        compression: 40%
        

        Это означает, что после сжатия, данные занимают на 40% меньше места (вычислено как среднее по последним 10 блокам данных).

        Маркер сжатия включен в индикатор хода выполнения, если включена опция --compress для действия mysqlbackup. Значение маркера сжатия не определено, пока по крайней мере 10 блоков данных не были сжаты. Неопределенное значение метра обозначено как '-':

        compression: -
        
      • Маркер статуса: Это краткое описание главного шага, который в настоящее время выполняет команда. Например:

        state: Copying InnoDB data
        state: Waiting for locks
        state: Copying system tablespace
        state: Copying .ibd files
        state: Copying non-InnoDB data
        state: Completed
        

      Вот некоторые примеры индикаторов хода выполнения с различными маркерами:

      Progress: 300 of 1540 MB; state: Waiting for locks
      Progress: 400 of 1450 MB; state: Copying InnoDB data: compression: 30%
      

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

    • --progress-interval= SECONDS

      Формат командной строки --progress-interval=SECONDS
      ТипNumeric
      По умолчанию2
      Минимум1
      Максимум100000
      Единица измеренияsecond

      Интервал между отчетами о выполнении работ в секундах. Значение по умолчанию составляет две секунды. Самый короткий интервал составляет 1 секунду, самый длинный позволенный интервал составляет 100000 секунд.

    20.13. Опции шифрования

    Эти опции для создания зашифрованного однофайлового резервного копирования и для расшифровки их. Дополнительную информацию см. в главе 10. Там же есть примеры использования для шифрования и функций декодирования MySQL Enterprise Backup.

    • --encrypt

      Зашифруйте данные, создавая образ резервной копии через backup-to-image или или упаковывая резервный каталог в единственный файл с помощью backup-dir-to-image. Это не может использоваться с backup или backup-and-apply-log.

    • --decrypt

      Расшифруйте зашифрованный образ резервной копии, используя extract, image-to-backup-dir или copy-back-and-apply-log. Это также используется для выполнения validate или list-image на зашифрованном образе резервной копии.

      Опция не может использоваться в apply-log, backup-and-apply-log или copy-back. Для восстановления, используя copy-back, зашифрованный образ резервной копии должен быть распакован и расшифрован сначала использованием image-to-backup-dir или extract с опцией --decrypt.

    • --key=STRING

      Формат командной строки --key=KEY
      ТипString

      Симметричный ключ для шифрования и декодирования образа резервной копии. Это должен быть 256-битный ключ, закодированный как ряд из 64 шестнадцатеричных цифр. См. главу 10 о том, как создать ключ. Опция несовместима с --key-file .

    • --key-file=PATH

      Формат командной строки --key-file=FILE
      ТипFile name

      Путь к файлу, который содержит 256-битный ключ, закодированный как ряд из 64 шестнадцатеричных цифр для шифрования и декодирования образа резервной копии. Опция несовместима с --key .

    20.14. Возможности для работы с зашифрованными табличными пространствами InnoDB и зашифрованными журналами

    MySQL Enterprise Backup понимает зашифрованные табличные пространства InnoDB и для выпусков 8.0.14 и позже зашифрованные журналы. Для получения дополнительной информации о том, как MySQL Server шифрует и расшифровывает эти объекты, посмотрите InnoDB Data-at-Rest Encryption и Encrypting Binary Log Files and Relay Log Files. См. главу 6 и раздел 8.4 о том, как команды mysqlbackup обращаются с этими зашифрованными объектами.

    • --encrypt-password[=STRING ]

      Формат командной строки --encrypt-password=STRING
      ТипString

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

      Опция должна использоваться, поддерживая сервер, которому позволили плагин брелка для таблицы InnoDB или шифрование журналов и для восстановления резервной копии, содержащей зашифрованные таблицы или журналы InnoDB. Если сервер использует плагин keyring_encrypted_file, пароль, поставляемый опцией, должен соответствовать значению системной переменной keyring_encrypted_file_password. Если сервер использует плагин keyring_hashicorp, используйте опцию, чтобы предоставить HashiCorp Vault AppRole authentication secret ID, который на сервере был значением keyring_hashicorp_secret_id.

      Тот же самый пароль, поставляемый во время резервной копии, должен поставляться снова во время copy-back-and-apply-log, apply-log или apply-incremental-backup для резервирования или mysqlbackup выдаст ошибку, когда столкнется с зашифрованным объектом. Если различные пароли использовались для различных резервных копий в последовательности полных и возрастающих резервных копий, удостоверьтесь, что задаете пароль, используемый, чтобы создать отдельную резервную копию, выполняя apply-log, apply-incremental-backup или copy-back-and-apply-log.

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

    20.15. Опции облачного хранилища

    Эти опции для использования облачного хранилища для однофайловых операций. Посмотрите разделы 4.3.1.3 и 5.2 для получения дополнительной информации и инструкции относительно использования облаков с MySQL Enterprise Backup.

    • Опции для всех облачных сервисов:

      • --cloud-service=SERVICE

        Облачный сервис для резервного копирования данных или восстановления. Различные типы услуг облачного хранилища поддерживаются mysqlbackup со следующими значениями опции:

        • OCI: Oracle Cloud Infrastructure Object Storage.

        • openstack: OpenStack Swift или или совместимые услуги хранения объектов.

        • s3: Amazon Simple Storage Service (S3) или совместимая служба хранения.

        • GCP: Хранение объектов GCP.

      • --cloud-trace

        Напечатайте трассировочную информацию для операций по облаку. Это работает независимо от --trace, которая определяет уровень отладки для необлачных операций mysqlbackup. Любое ненулевое значение для опции позволяет функцию отладки.

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

      • --cloud-proxy=proxy-url:port

        Адрес прокси и номер порта для параметров настройки окружающей среды по умолчанию для доступа к облаку.

        list-image может быть выполнена на облачной резервной копии, только если облако поддерживает заголовки диапазона HTTP.

      • --cloud-ca-info=PATH

        Абсолютный путь к CA-файлу для идентификации хоста для связей SSL. Когда опция определяется, использование файла CA предпочтено перед использованием индивидуальных файлов .pem для идентификации хоста.

      • --cloud-ca-path =PATH

        Каталог сертификата CA в дополнение к папке системы по умолчанию.

      • --cloud-buffer-size= MB

        Размер буфера для операций по облаку в мегабайтах. mysqlbackup накапливает данные до размера, определенного этой опцией, прежде, чем начать передачу в облако. Значение должно быть между 16 и 4096.

        По умолчанию: 64.

    • Опции для Oracle Cloud Infrastructure (OCI) Object Storage:

      • --cloud-object= OCI_OBJECT

        Объект хранения для образа резервной копии. Обратите внимание на то, что названия объектов в том же самом хранилище должны быть уникальными.

      • --cloud-par-url= OCI_PAR-URL

        Pre-Authenticated Request (PAR) URL for OCI Object Storage. Для резервной копии к OCI Object Storage это PAR URL хранилища, для восстановления и других операций на объекте, хранящемся на OCI, это PAR URL для объекта.

    • Опции для OpenStack Swift Object Storage:

      • --cloud-object= SWIFT_OBJECT

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

      • --cloud-container= SWIFT_CONTAINER

        Контейнер Swift для образа резервной копии.

      • --cloud-user-id= SWIFT_USER-ID

        Идентификатор пользователя (ID) для доступа к для Swift. Пользователи проверены системой идентичности Swift TempAuth, когда используется опция --cloud-tempauth-url, сервисом идентичности OpenStack Keystone, когда используется опция --cloud-identity-url и HTTP Basic Authentication, когда используется опция --cloud-basicauth-url.

      • --cloud-password= SWIFT_PASSWORD

        Пароль для доступа к Swift для пользователя, определенного --cloud-user-id. Пользователи проверены системой идентичности Swift TempAuth, когда используется опция --cloud-tempauth-url, сервисом идентичности OpenStack Keystone, когда используется опция --cloud-identity-url и HTTP Basic Authentication, когда используется опция --cloud-basicauth-url.

      • --cloud-tempauth-url= SWIFT_TEMPAUTH-URL

        TempAuth URL для подтверждения пользователя.

      • --cloud-basicauth-url= SWIFT_BASICAUTH-URL

        URL для HTTP Basic Authentication.

      • --cloud-identity-url= SWIFT_KEYSTONE-URL

        URL сервиса идентичности Keystone, когда это используется для подтверждения пользователя.

      • --cloud-tenant= SWIFT_KEYSTONE-TENANT

        Арендатор Keystone для пользователя, определенного --cloud-user-id , когда обслуживание идентичности Keystone используется для подтверждения пользователя.

      • --cloud-region= SWIFT_KEYSTONE-REGION

        Регион Keystone для пользователя, определенного --cloud-user-id, когда обслуживание идентичности Keystone используется для подтверждения пользователя.

      • --cloud-chunked-transfer={true|false}

        Используйте передачу кусками. Когда --cloud-service=openstack, резервные копии всегда передаются и хранятся как Dynamic Large Objects (DLOs), для которого многократные сегменты файла рассматриваются как единственный файл. Максимальное количество сегментов, которые может иметь резервная копия, определяется обслуживанием хранения объектов, максимальным размером сегментов управляет эта опция.

        Если опция установлена в true, mysqlbackup использует кодирование передачи, чтобы передать данные. Резервная копия, большая, чем значение --cloud-chunk-size (или больше 5 ГБ для выпуска 8.0.22 и ранее) разделяется на сегменты.

        Если опция установлена в false, mysqlbackup загружает резервную копию в сегментах в размере буфера.

        По умолчанию: false, когда --cloud-service=openstack.

        Установите опцию в true, только если передача кусками поддерживается вашим облачным хранилищем, иначе mysqlbackup может потерпеть неудачу.

      • --cloud-chunk-size= SWIFT_CHUNK-SIZE

        MySQL Enterprise Backup 8.0.23 и позже: размер куска в мегабайтах, если передача кусками позволена. Эта опция проигнорирована, если передача кусками отключена.

        Минимальное значение: 64

        Максимальное значение: 3072 в 32-bit, 5120 в 64-bit

        Значение по умолчанию: 2048

      Одно и только одно значение из --cloud-tempauth-url, --cloud-identity-url, --cloud-basicauth-url или --cloud-storage-url должно использоваться, получая доступ к сервису Swift, иначе mysqlbackup бросит ошибку.

    • Опции для Amazon S3 и совместимых сервисов:

      • --cloud-host= S3_HOSTNAME

        (MySQL Enterprise Backup 8.0.22 и позже) Имя хоста для сервиса S3.

        По умолчанию: s3.amazonaws.com

      • --cloud-bucket= S3_BUCKET

        Место хранения в S3-сервисе для образа резервной копии.

        Чтобы выполнить облачные резервные копии с хранилищем пользователь, указанный --cloud-access-key-id, должен иметь по крайней мере следующие разрешения:

        • s3:ListBucket: Для листинга информации об объектах в хранилище.

        • s3:ListBucketMultipartUploads: Для листинга многослойных происходящих закачек.

        • s3:GetObject: Для восстановления объектов.

        • s3:PutObject: Для добавления объектов.

      • --cloud-object-key= S3_OBJECT-KEY

        S3-ключ объекта для образа резервной копии.

      • --cloud-access-key-id= S3_KEY-ID

        Ключ доступа ID для регистрации на сервисе S3.

      • --cloud-secret-access-key= S3_ACCESS-KEY

        Секретный ключ доступа для id-ключа доступа, указанного --cloud-access-key-id.

      • --cloud-aws-region= S3_REGION

        Регион для веб-сервиса, к которому обращается mysqlbackup.

    • Опции для GCP object storage (MySQL Enterprise Backup 8.0.23 и позже):

      • --cloud-host= HOSTNAME

        Имя хоста для сервиса хранения.

        По умолчанию: storage.googleapis.com, когда --cloud-service=GCP .

      • --cloud-bucket= BUCKET

        Место хранения для образа резервной копии.

      • --cloud-object= OBJECT

        Объект хранения для образа резервной копии. Обратите внимание на то, что названия объектов в том же самом хранилище должны быть уникальными.

      • --cloud-access-key= ACCESS-KEY

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

      • --cloud-secret-key= SECRET-KEY

        Секретный ключ для пользователя облака, определенного --cloud-access-key . Опция обязательна для операции резервного копирования.

      • --cloud-chunked-transfer={true|false}

        Используйте передачу кусками.

        Если опция установлена в true, mysqlbackup использует кодирование передачи, чтобы передать данные. Резервная копия больше, чем значение --cloud-chunk-size разделяется на многократные сегменты.

        Если опция установлен в false, mysqlbackup загружает резервную копию в сегментах в размере буфера.

        По умолчанию: true, если --cloud-service=GCP .

      • --cloud-chunk-size= CHUNK-SIZE

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

        Минимальное значение: 64

        Максимальное значение: 3072 на 32-bit или 5120 на 64-bit.

        Значение по умолчанию: 2048

    20.16. Возможности для специальных типов резервирования

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

    • --slave-info

      Поддерживая сервер точной копии, эта информация должна была настроить идентичный сервер точной копии. Это создает файл meta/ibbackup_slave_info в резервном каталоге, содержащий запрос CHANGE MASTER с положением двоичной регистрации и названием файла двоичного журнала исходного сервера. Эта информация также печатается в выводе mysqlbackup. Чтобы настроить новую точную копию для этого источника, восстановите данные резервного копирования на другом сервере, запустите сервер точной копии на данных резервного копирования и выполните команду CHANGE MASTER с положением двоичной регистрации, сохраненным в файле ibbackup_slave_info. См. раздел 8.1.

      • Используйте эту опцию только поддерживая сервер точной копии. Ее поведение не определено, когда используется на источнике или не на сервере репликации.

      • Эта опция несовместима с --no-locking, использование обоих вариантов вместе заставит mysqlbackup бросить ошибку.

      • Эта опция несовместима с --only-innodb.

      • Для резервных копий TTS для серверов точной копии используйте --slave-info, чтобы иметь файл backup_gtid_executed.sql произведенный и включенный в резервные копии.

    • --safe-slave-backup-timeout= SECONDS

      MySQL Enterprise Backup 8.0.16 и позже: Для основанной на запросе репликации (SBR) или смешанной установки повторения опция определяет время (в секундах), которое mysqlbackup будет ждать Slave_open_temp_tables = 0 (это верно, когда никакие временные таблицы не открыты), чтобы закончить резервную копию для сервера точной копии и копировать все не-InnoDB таблицы. Если продолжительность ожидания превышает лимит, который определен опцией, mysqlbackup бросает ошибку. Ожидание нужно для того, чтобы воспрепятствовать mysqlbackup закончить резервную копию репликации, когда есть все еще открытые временные таблицы. См. здесь для получения дополнительной информации о том, как mysqlbackup имеет дело с временными таблицами на сервере точной копии.

      MySQL Enterprise Backup 8.0.15 и ранее: Для основанной на запросе репликации (SBR) или смешанной установки повторения опция определяет время (в секундах), которое mysqlbackup будет ждать Slave_open_temp_tables = 0 (это верно, когда никакие временные таблицы не открыты), чтобы закончить резервную копию для сервера точной копии и копировать все не-InnoDB таблицы. Если продолжительность ожидания превышает лимит, который определен опцией, mysqlbackup бросает ошибку. Ожидание нужно для того, чтобы воспрепятствовать mysqlbackup закончить резервную копию репликации, когда есть все еще открытые временные таблицы. См. здесь для получения дополнительной информации о том, как mysqlbackup имеет дело с временными таблицами на сервере точной копии.

      Кроме того, mysqlbackup также осуществляет начальную проверку в начале резервной копии репликации, чтобы видеть, что Slave_open_temp_tables=0 становится верным во время, заданное --safe-slave-backup-timeout. Если это не так, mysqlbackup отмечает ситуацию, что прежде чем резервная копия закончена, некоторые временные таблицы, вероятно, останутся открытыми после того, как предел тайм-аута будет превышен, mysqlbackup бросает ошибку, вместо того, чтобы продолжить резервную копию. Когда это происходит, можно перезапустить резервную копию с более высоким значением для --safe-slave-backup-timeout или повторить в то время, когда будет использоваться меньше временных таблиц.

      По умолчанию: 300.

      Надлежащее урегулирование этого значения зависит от варианта использования, это может измениться согласно ситуации. Указание слишком высокого или слишком низкого значения для этой опции неблагоприятно затронет выполнение операции резервного копирования:

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

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

      Для установки построчной репликации (RBR) временные таблицы не копируются на точную копию. Пользователи, которые уверены, что SBR не происходит для точной копии, могут установить --safe-slave-backup-timeout=0, с которым mysqlbackup не проверяет ни на какие открытые временные таблицы прежде, чем закончить резервную копию.

    • --suspend-at-end

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

      MySQL Enterprise Backup 8.0.16 и позже: Все не-InnoDB таблицы блокированы перед приостановкой, поместив их в статус только для чтения, если вы не выключаете блокировку с --no-locking. Опция --only-innodb также предотвращает шаг блокировки. Можно также использовать комбинацию --only-innodb и --suspend-at-end, чтобы поддержать только определенные таблицы InnoDB.

      MySQL Enterprise Backup 8.0.15 и ранее: Все таблицы блокированы перед приостановкой, поместив базу данных в статус только для чтения, если вы не выключаете блокировку с --no-locking. Опция --only-innodb также предотвращает шаг блокировки. Поскольку блокировка всех таблиц могла быть проблематичной на занятом сервере, вы могли бы использовать комбинацию --only-innodb и --suspend-at-end, чтобы поддержать только определенные таблицы InnoDB.

    • --exec-when-locked="utility arg1 arg2 ..."

      Формат командной строки --exec-when-locked="utility arg1 arg2 ..."
      ТипString

      MySQL Enterprise Backup 8.0.16 и позже: указанная utility выполняется, когда все не-InnoDB таблицы блокированы около конца операции резервного копирования.

      MySQL Enterprise Backup 8.0.15 и ранее: указанная utility выполняется, когда все таблицы блокированы около конца операции резервного копирования.

      Можно использовать эту опцию, чтобы управлять скриптом, который поддерживает любую информацию, которая не включена как часть обычной резервной копии. Например, с --exec-when-locked , можно использовать mysqldump, чтобы поддержать таблицы от механизма хранения MEMORY, которые не находятся на диске.

      Установите любую переменную, которую вы хотите использовать в рамках вашего скрипта, прежде чем вы будете управлять mysqlbackup. В следующем примере переменная окружения BACKUP_DIR собирается указать на каталог актуальной резервной копии (кавычки используются для аргумента --exec-when-locked , чтобы предотвратить преждевременное расширение переменной BACKUP_DIR):

      В Unix или Linux:

      export BACKUP_DIR=path_to_backupdir
      mysqlbackup --exec-when-locked="mysqldump mydb t1 > $BACKUP_DIR/t1.sql" \
                  other_options
                  mysqlbackup_command
      

      Или в Windows:

      set BACKUP_DIR=path_to_backupdir
      mysqlbackup --exec-when-locked="mysqldump mydb t1 > %BACKUP_DIR%/t1.sql" \
                  other_options
                  mysqlbackup_command
      

      Если программа не может быть выполнена или возвращает статус выхода отличный от нуля, процесс резервного копирования отменяется. Если вы также используете --suspend-at-end, программа, указанная --exec-when-locked, выполняется после того, как приостановка снята.

    Поиск

     

    Найди своих коллег!

    Вы можете направить письмо администратору этой странички, Алексею Паутову. mailto:alexey.v.pautov@mail.ru