Chapter 3 What's New in MySQL Enterprise Backup 4.1? — MySQL Enterprise Backup 4.1

Глава 3 Что нового в MySQL Enterprise Backup 4.1?

В этой главе представлены новые функции в MySQL Enterprise Backup 4.1, а также значительные изменения, внесённые в MySQL Enterprise Backup с выпуском этой серии.

MySQL Enterprise Backup теперь поддерживает оптимистичный инкрементный бэкап, в котором mysqlbackup сканирует только те файлы данных InnoDB, которые были изменены с момента последнего бэкапа для поиска изменённых страниц и затем сохраняет их в инкрементный бэкап. Это потенциально ускоряет инкрементные бэкапы. Подробности см. в Разделе "Полный сканирование против оптимистичного инкрементного бэкапа".
Теперь реализован полный набор кодов выхода для MySQL Enterprise Backup. Также добавлена новая команда mysqlbackup, print-message, которая возвращает сообщение об выходе для любого предоставленного кода выхода с использованием нового параметра --error-code. Подробности см. в Разделе 13.1 «Коды выхода MySQL Enterprise Backup».
Операции с журналом применения (apply-log) теперь можно выполнять с несколькими рабочими потоками параллельно, что может улучшить производительность операций. Количество используемых потоков можно указать с помощью параметра --process-threads.
MySQL Enterprise Backup теперь поддерживает параметр --ssl-mode, который позволяет задать состояние безопасности соединения с сервером. Он заменяет параметры со стороны клиента и , которые теперь устарели. См. описание параметра в для получения подробной информации.
Реализовано несколько мер для повышения производительности горячих бэкапов, уменьшая продолжительность заключительной фазы горячих бэкапов, в которой сервер блокируется. Подробнее см. в Заметки о выпуске MySQL Enterprise Backup 4.1.
Новый параметр --skip-final-rescan позволяет mysqlbackup пропустить окончательное пересканирование для таблиц InnoDB, которые модифицируются операциями DDL после того, как база данных была заблокирована в конце операции бэкапа. Подробнее см. описание параметра --skip-final-rescan.
Вывод mysqlbackup, который отправляется в поток stderr и журнал сообщений, был улучшен, чтобы включать метки времени и идентификаторы потоков для всех этапов, выполняемых mysqlbackup, для предоставления дополнительной информации при отладке.
Таблица backup_history теперь включает следующие новые столбцы:
- start_time_utc
- end_time_utc
- consistency_time_utc
- meb_version
- server_uuid (для версии 4.1.2 и более поздних)
Для MySQL Enterprise Backup 4.1.1 и более поздних версий, работающих с MySQL Server 5.7.21 и более поздними: Теперь MySQL Enterprise Backup поддерживает использование плагинов и серверами. Подробности см. в Главе 6 «Работа с зашифрованными таблицами InnoDB».
Для MySQL Enterprise Backup 4.1.1 и более поздних версий: Теперь поддерживаются HTTP Basic Authentication и неразбитый перенос для бэкапа и восстановления с использованием служб хранения объектов, совместимых с OpenStack Swift. Подробности см. в Разделе 16.15 «Параметры облачного хранилища».
Для MySQL Enterprise Backup 4.1.2 и более поздних версий: Теперь поддерживается OAuth для проверки подлинности клиента Oracle Cloud Infrastructure Object Storage. Для этой цели были добавлены два новых параметра: --cloud-storage-url и --cloud-oauth-token. Подробности см. в Разделе 16.15 «Параметры облачного хранилища».
Для MySQL Enterprise Backup 4.1.2 и более поздних версий: Журнал двоичных логов для резервируемого сервера вместо всегда восстановления в каталог данных на целевом сервере теперь по умолчанию восстанавливается в то же расположение, где он был найден на резервируемом сервере. Его также можно восстановить в другое место, указанное с помощью нового параметра --log-bin.
Для MySQL Enterprise Backup 4.1.2 и более поздних версий: Журнал реле для резервируемого сервера-реплики, вместо всегда восстановления в каталог данных на целевом реплицируемом сервере, теперь по умолчанию восстанавливается в то же расположение, где он был найден на резервируемом реплицируемом сервере. Его также можно восстановить в другое место, указанное с помощью нового параметра --relay-log.
Для MySQL Enterprise Backup 4.1.2 и более поздних версий: При работе с mysqlbackup теперь делает историю бэкапов доступной для всех членов группы серверов, обеспечивая обновление таблицы backup_history на узле-лидере после каждой операции mysqlbackup. Подробности, включая новое требование к привилегиям пользователя для mysqlbackup для подключения к серверу, независимо от того, принадлежит ли сервер к группе репликации, см. в Главе 8 «Использование MySQL Enterprise Backup с групповой репликацией».
Для MySQL Enterprise Backup 4.1.2 и более поздних версий: Системный движок таблицы mysql.backup_history на резервируемом сервере перешёл от CSV к InnoDB. Подробности о специальных правах доступа пользователя, необходимых mysqlbackup для миграции таблиц, см. здесь.
Для MySQL Enterprise Backup 4.1.3 и более поздних версий: В дополнение к требованию, что целевой каталог данных для восстановления, указанный параметром --datadir, должен быть не существующим или пустым, mysqlbackup теперь применяет это же правило к параметрам --innodb_data_home_dir, --innodb_log_group_home_dir и --innodb_undo_directory (параметр --force не может быть использован для отмены требования к трём параметрам).
Для MySQL Enterprise Backup 4.1.4 и более поздних версий:
- Новый параметр --lock-wait-retry-count теперь можно использовать для указания максимального числа попыток повтора, которые будет предпринимать mysqlbackup после выполнения оператора FLUSH TABLES WITH READ LOCK, выданного на заключительном этапе бэкапа для временного перевода базы данных в режим только для чтения, если произошла ошибка из-за таймаута. Подробнее см. описание параметра.
- Параметр --uncompress теперь поддерживается для операции extract, поэтому файлы из сжатого бэкапа в единственном файле теперь можно извлечь и распаковать одной командой.

Для MySQL Enterprise Backup 4.1.5 и более поздних версий:
- Для copy-back-and-apply-log и других операций с отдельными файлами, за исключением backup-to-image, при указании относительного пути для опции --backup-image, mysqlbackup интерпретирует путь как относительный к текущей рабочей директории, в которой выполняется команда mysqlbackup.
- Опция --rename теперь работает как с полными, так и с частичными восстановлениями:
  - Если опции --include-tables и --exclude-tables не используются, все таблицы в резервной копии восстанавливаются, при этом таблица, выбранная опцией --rename, переименовывается в соответствии с заданием.
  - Если опции --include-tables и --exclude-tables используются, восстанавливаются все таблицы, выбранные этими опциями вместе, а таблица, выбранная опцией --rename, переименовывается в соответствии с заданием.
- При резервном копировании сервера, использующего keyring_file, keyring_encrypted_file или keyring_aws, если он не содержал зашифрованных таблиц InnoDB, файл ключей не включался в резервную копию. Это создавало проблему, например, при обновлении сервера с помощью mysqlbackup, так как файл ключей не сохранялся в процессе. Теперь mysqlbackup всегда ищет файл данных ключей и копирует его, если на сервере активны упомянутые плагины для ключей.
- Теперь зашифрованные таблицы InnoDB могут быть включены в частичные резервные копии и восстановления с помощью .
- Файл backup_gtid_executed.sql не включался в TTS резервную копию для реплицирующего сервера, использующего GTID. Теперь файл включается в TTS резервную копию, если используется опция --slave-info.
- mysqlbackup теперь пропускает копирование бинарного лога для инкрементной резервной копии, когда резервная копия, на которой она основана, не включает бинарный лог. Кроме того, при восстановлении инкрементной резервной копии на сервер, которая не содержит бинарный лог, mysqlbackup теперь переименовывает любые файлы бинарного лога, которые уже были восстановлены на сервер, добавляя к ним расширение .old; то же самое происходит при восстановлении инкрементной резервной копии с помощью опции --skip-binlog.
- Теперь резервная копия завершается с ошибкой, если файл бинарного или релейного лога удаляется во время выполнения резервного копирования; также происходит ошибка, если mysqlbackup находит отсутствующий файл бинарного лога на сервере (однако, если отсутствует файл релейного лога, резервная копия продолжается).
- Опция --incremental-base теперь принимает новое значение history:last_full_backup, что упрощает создание . Подробности см. в описании опции --incremental-base.