Эта глава подчеркивает новые особенности в MySQL Enterprise Backup 8.0, а также любые существенные изменения, внесенные в MySQL Enterprise Backup.
Офлайновые резервные копии больше не поддерживаются.
Используование старых опций --no-connection
и
--connect-if-online
с MySQL Enterprise Backup
приведет к ошибке. Надлежащие
варианты связи должны поставляться MySQL Enterprise Backup,
делая резервную копию. Следующие опции, используемые во время офлайновых
резервных копий, были также удалены:
--innodb_data_file_path
--innodb_log_files_in_group
--innodb_log_file_size
--innodb_page_size
--innodb_checksum_algorithm
--keyring_file_data
--keyring_okv_conf_dir
--relay-log-info-file
--master-info-file
--backup_innodb_log_files_in_group
--backup_innodb_log_file_size
--backup_innodb_undo_tablespaces
--backup_innodb_undo_logs
--backup_innodb_page_size
--backup_innodb_checksum_algorithm
Двоичная регистрация для поддержанного сервера вместо того, чтобы
всегда вернуться в каталог данных на целевом сервере, теперь вернется по
умолчанию к тому же самому местоположению, в котором это было найдено на
поддержанном сервере. Это может также вернуться к иному местоположению,
определенному новой опцией
--log-bin
.
Журнал реле для поддержанного сервера точной копии вместо того, чтобы
всегда вернуться в каталог данных на целевом сервере, теперь вернется по
умолчанию к тому же самому местоположению, в котором это было найдено на
поддержанном сервере точной копии. Это может также вернуться к иному
местоположению, определенному опцией
--relay-log
.
Файл теперь отслеживает информацию внешних табличных пространств для резервной копии или восстановления в формате JSON. См. описание для tablespace_tracker в таблице 1.1.
Новая опция
--tls-version
определяет протоколы
для зашифрованных связей с серверами MySQL.
MySQL Enterprise Firewall Overview теперь поддерживается.
Опции --ssl
и --ssl-verify-server-cert
устарели еще в MySQL Enterprise Backup 4.1 и теперь удалены. Используйте
--ssl-mode
, чтобы
сформировать режим безопасности вашей связи с сервером.
HTTP Basic Authentication и передача non-chunked теперь поддерживаются для резервной копии и восстановления с использованием OpenStack Swift-совместимых сервисов хранения объектов. См. раздел 20.15.
Размер буфера для передач облака может теперь быть определен,
используя опцию
cloud-buffer-size
. См.
раздел 20.15.
Использование серверных плагинов keyring_encrypted_file и keyring_aws теперь поддерживается. Кроме того, независимо от типа плагина брелка, который используется на сервере, данные о брелке теперь хранятся в резервной копии в зашифрованном файле. См. главу 6.
Опция сервера --secure-auth
больше не поддерживается.
Таблица backup_history
теперь включает столбец
server_uuid
, который хранит значение
server_uuid
поддержанного сервера.
Из-за новых особенностей и функций MySQL Enterprise Backup 8.0, больше привилегий теперь требуется для пользователя, от которого mysqlbackup соединяется с MySQL Server. См. раздел 4.1.2.
MySQL Enterprise Backup 8.0.12 и позже:
Когда работает с установкой
Group Replication, mysqlbackup
теперь делает историю резервного копирования доступной для всех
членов группы сервера удостоверяясь что таблица
backup_history
обновляется на основном узле после каждого
действия mysqlbackup. См.
главу 9 для получения дополнительной информации
включая новое требование полномочий пользователя для
mysqlbackup, чтобы соединиться с сервером,
независимо от того, принадлежит ли сервер к Group Replication.
Механизм хранения таблицы mysql.backup_history
переключился с CSV на InnoDB. Посмотрите
здесь
для привилегий специального пользователя, теперь требуемых
mysqlbackup, которые связаны с этим изменением.
MySQL Enterprise Backup 8.0.13 и позже:
mysqlbackup теперь поддерживает
transparent page compression для таблиц InnoDB.
Поддержка позволена, установив опцию
--compress-method=punch-hole
,
см. описание для возможности для деталей.
mysqlbackup
теперь поддерживает сжатие (то есть, использование опций
--compress
и
--uncompress
)
для возрастающих резервных копий (за исключением возрастающих резервных
копий, созданных с опцией
--incremental-with-redo-log-only
).
MySQL Enterprise Backup 8.0.14 и позже:
mysqlbackup теперь поддерживает
опцию
--ssl-fips-mode
, которая управляет, работает ли
mysqlbackup в режиме FIPS, см.
FIPS Support.
mysqlbackup теперь поддерживает зашифрованные журналы, см. раздел 8.4.
MySQL Enterprise Backup 8.0.16 и позже:
Около конца процесса резервного копирования вместо того, чтобы заблокировать сервер в течение краткого промежутка времени, mysqlbackup теперь применяет эти блокировки последовательно:
Резервная блокировка, которая блокирует DDL (кроме созданных пользователями временных таблицах), но не DML на таблицах InnoDB.
FLUSH TABLES
на всех не-InnoDB таблицах для копирования соответствующих из них в резервную
копию. Этот шаг пропускается, если нет не-InnoDB таблиц.
tbl_name [, tbl_name]
... WITH READ LOCK
Краткое блокирование регистрирующих действий по серверу для сбора связанной с регистрацией информации.
См. раздел 1.4. Удаление блокировки на сервере уменьшает воздействие операции резервного копирования.
Изменение требует привилегий
BACKUP_ADMIN
и
SELECT
на всех таблицах пользователю, от
которого работает mysqlbackup
(BACKUP_ADMIN
автоматически предоставляют пользователям с привилегией
RELOAD
, когда оперативная модернизация
до MySQL Server 8.0 от более ранней версии выполняется).
В дополнение к требованию, чтобы целевой каталог данных, указанный
для того, чтобы восстанавливать, с помощью
--datadir
,
должен не существовать или быть пустым,
mysqlbackup
теперь проводит в жизнь то же самое правило для опций
--innodb_data_home_dir
,
--innodb_log_group_home_dir
и
--innodb_undo_directory
(опция --force
не
может использоваться, чтобы отвергнуть требование к
этим трем опциям).
mysqlbackup теперь поддерживает
динамические изменения табличных пространств отмены на
поддержанном сервере. Во время восстановления табличных пространств
отмены не по умолчанию они вернутся к местоположению, на которое указывает
опция
innodb_undo_directory
. Внешние табличные пространства отмены
не по умолчанию вернутся к местоположениям, которыми они были найдены на
поддержанном сервере. См. здесь
.
mysqlbackup теперь поддерживает зашифрованные журналы отмены InnoDB. Зашифрованные табличные пространства отмены обработаны тем же самым путем, как зашифрованные табличные пространства для таблиц InnoDB. См. главу 6.
MySQL Enterprise Backup 8.0.17 и позже:
mysqlbackup теперь поддерживает зашифрованные журналы отката InnoDB. Зашифрованные табличные пространства отката обработаны тем же самым путем, как зашифрованные табличные пространства для таблиц InnoDB. См. главу 6.
Чтобы mysqlbackup был
в состоянии догнать растущий журнал отката во время операции резервного
копирования и не пропускал данные журнала отката,
mysqlbackup теперь использует
архивирование журнала отката, новую особенность, доступную
в MySQL Server 8.0.17. Архивирование журнала отката может быть пропущено,
используя новую опцию
--no-redo-log-archive
. См.
главу 7.
Опция
--incremental-base
теперь принимает новое значение
history:last_full_backup
, которое облегчает создание
дифференциального
резервного копирования. См.
--incremental-base
.
MySQL Enterprise Backup 8.0.18 и позже:
mysqlbackup
теперь поддерживает более быстрый способ создать возрастающие резервные копии
при помощи функциональности отслеживания страницы MySQL Server.
Чтобы использовать эту новую функцию, надо установить
--incremental=page-track
. См.
здесь.
Опция
--uncompress
теперь поддерживается для
действия extract
,
чтобы файлы от сжатого однофайлового резервного копирования теперь могли быть
извлечены единственной командой.
Две новых опции
--compression-algorithms
и
--zstd-compression-level
были введены для формирования
сжатия для связей сервера. См.
раздел 20.2 и
здесь.
Команда
image-to-backup-dir
теперь псевдоним для
extract
.
MySQL Enterprise Backup 8.0.19 и позже:
Теперь можно безопасно начать операции DDL
(CREATE TABLE,
RENAME TABLE,
DROP TABLE,
ALTER TABLE и операции, отображенные на
ALTER TABLE, например,
CREATE INDEX) на сервере параллельно с
операцией резервного копирования, посмотрите детали, описанные
здесь
для некоторых ограничений. Из-за этой новой особенности
пользователю, под которым mysqlbackup
соединяется с сервером MySQL, нужно теперь предоставить привилегию
SELECT ON *.*
, см.
раздел 4.1.2.
Ротация главного ключа для шифрования двоичного журнала
на сервере, между полным и инкрементным резервными копированиями, а также
между двумя возрастающими резервными копиями, выполненными
mysqlbackup, теперь поддерживается. Во время
инкрементного резервного копирования mysqlbackup
теперь делает запись информации о шифровании для всех зашифрованных
двоичных файлов журнала (включая уже поддержанных в более ранних полных или
возрастающих резервных копиях), если использована опция
--skip-binlog
,
в этом случае надо учитывать, что более старые двоичные файлы журнала могли
бы стать невосстанавливаемыми.
Кроме того, опция
--skip-binlog
теперь делает двоичную регистрацию, которая
будет пропущена не только для операции по актуальной резервной копии, но
также и для всех последующих возрастающих резервных копий, которые основаны
на актуальной резервной копии.
Регистрация для восстановления резервной копии улучшена: в шагах для урегулирования размеров файлов журнала теперь включены названия файлов журнала.
mysqlbackup теперь печатает трассировку стека, будучи закончен сигналом.
Когда mysqlbackup не соединяется с сервером, предупреждение, возвращенное mysqlbackup, теперь включает имя хоста и номер порта для соединений по протоколу TCP и информацию о сокете для сокетных соединений. Это особенно полезно для Group Replication, для которой mysqlbackup мог бы попытаться соединиться больше, чем с одним хостом.
Механизм хранения для таблицы mysql.backup_progress
на поддержанном сервере переключился с CSV на InnoDB, сводный индекс теперь
создается на столбцах backup_id
и current_timestamp
.
Кроме того, когда работает с Group Replication,
mysqlbackup теперь делает таблицу
backup_progress
доступной всем членам группы сервера
удостоверяясь, что она обновляется на основном узле во время каждого действия
mysqlbackup.
Когда MySQL Enterprise Backup 8.0.19 или более поздняя пытается выполнить
ее первое полное резервное копирование на базе данных, это автоматически
проверяет формат таблицы mysql.backup_progress
. Если это
обнаруживает, что таблица находится в старом формате (что означает, что
сервер был модернизирован от 8.0.18 или ранее и был поддержан MySQL
Enterprise Backup), это пытается выполнить обновление автоматически.
Новые привилегии для mysqlbackup
на сервере требуются для
модернизации, см. приложение F.
mysqlbackup теперь включает
конфигурационные файлы auto.cnf
и
mysqld-auto.cnf
в резервную копию (за
исключением резервной копии TTS). Они вернутся в каталог
данных целевого сервера как backup-auto.cnf
и
backup-mysqld-auto.cnf
, соответственно.
Чтобы использовать эти файлы, чтобы сформировать ваш восстановленный сервер,
переименуйте их к настоящим именам прежде, чем запустить сервер.
Для
backup-to-image
,
extract
,
list-image
и
copy-back-and-apply-log
любой
относительный путь, определенный с
--backup-image
, теперь взят относительно текущего каталога,
в котором запущена команда.
MySQL Enterprise Backup 8.0.20 и выще:
Файл
tablespace_tracker был упрощен: это теперь содержит только две области
для каждого внешнего табличного пространства: server_file_path
и space_id
. mysqlbackup
больше не полагается на файл для получения информации о
backup_file_path
и типе табличного пространства, это означает,
что пользователи больше не должны обновлять файл
tablespace_tracker, когда
они перемещают директивную резервную копию в новое местоположение.
Table-Level Recovery (TLR) теперь позволяет выборочное восстановление, см. раздел 5.1.4.
Устаревшая опция
--include
не используется. Вместо нее применяются
--include-tables
и
--exclude-tables
.
MySQL Enterprise Backup 8.0.21 и выше:
Для
backup-to-image
, когда относительный путь определяется для
--backup-image
, mysqlbackup интерпретирует путь к файлу,
данный относительно
резервного каталога.
Зашифрованные таблицы InnoDB могут теперь быть включены в частичные резервные копии и восстановлены с применинем transportable tablespaces (TTS).
Зашифрованные таблицы InnoDB теперь проверяются в действии
validate
.
Сжатые файлы InnoDB теперь проверяются в действиях
validate
,
backup
и
backup-to-image
.
Механизм хранения для таблицы mysql.backup_sbt_history
на поддержанном сервере переключился с CSV на InnoDB. Кроме того, первичный
ключ auto-increment id
добавлен к таблице. При работе с Group
Replication mysqlbackup теперь делает таблицу
backup_sbt_history
доступной всем членам группы сервера
удостоверяясь, что она обновляется на основном узле во время каждого действия
mysqlbackup.
Когда MySQL Enterprise Backup 8.0.21 или позже пытается
выполнить первое полное резервное копирование на базе данных, используя SBT
API, это автоматически проверяет формат таблицы
mysql.backup_sbt_history
. Если это обнаруживает, что таблица
находится в старом формате (что означает, что сервер был модернизирован от
8.0.20 или ранее и был поддержан MySQL Enterprise Backup с использованием SBT
API), это пытается выполнить обновление таблицы автоматически.
Новые привилегии для пользователя mysqlbackup
на сервере требуются для модернизации, см.
приложение E.
Команды для операций на сжатых резервных копиях
(copy-back
,
copy-back-and-apply-log
,
apply-log
и т.д.)
были упрощены: опция
--uncompress
теперь не нужна, кроме
extract
и
image-to-backup-dir
, которые
не используют
--src-entry
.
Команды для операций на возрастающих резервных копиях
(copy-back
,
copy-back-and-apply-log
,
apply-log
)
были упрощены:
--incremental
больше не требуется.
Резервная копия теперь терпит неудачу, когда файл двоичного журнала
или реле очищен в то время, как резервная копия продолжается, это также
терпит неудачу, когда mysqlbackup
находит двоичный файл журнала,
отсутствующий на сервере (однако, если файл журнала реле отсутствует,
резервная копия продолжается).
Столбец tool_name
таблицы
backup_progress
на сервере MySQL теперь наполнен полной командой
mysqlbackup.
Файл backup_gtid_executed.sql
не был включен в резервную копию TTS для сервера точной копии,
используя GTID. Файл теперь включается в резервную копию TTS
при использовании опции the
--slave-info
.
MySQL Enterprise Backup 8.0.22 и позже:
MySQL Enterprise Backup теперь поддерживает облачную резервную
копию с использованием сервиса Object Storage Oracle Cloud Infrastructure
(OCI) с Pre-Authorized Request (PAR) URLs. Новая опция
--cloud-par-url
добавлена. См.
раздел 4.3.1.3.
Кроме того, OAuth больше не поддерживается MySQL Enterprise Backup для идентификации с сервисом OCI Object Storage.
MySQL Enterprise Backup теперь поддерживает услуги облачного
хранилища S3 с новой опцией
--cloud-host
, которой пользователи могут определить
имя хоста хранения.
MySQL Enterprise Backup теперь поддерживает аутентификацию
пользователя сервером, используя LDAP. Две новых опций
--plugin-dir
и
--enable-cleartext-plugin
были введены, чтобы поддерживать эту функцию. См.
главу 16.
MySQL Enterprise Backup 8.0.23 и позже:
MySQL Enterprise Backup расширил типы услуг облачного хранилища, которые поддерживает, посмотрите раздел 20.15.
Журналирование операций по облаку с хранением объектов OCI теперь предоставляет больше информации.
Новая опция
--cloud-chunk-size
была введена для определения размера
куска, когда передача кусками позволена для операций по облаку. См. описание
для
--cloud-chunk-size
.
Для операции по облачной резервной копии с сервисом хранения Amazon S3 проверка того, существует ли объект в сервисе хранения, была добавлена к началу операции. Если указанный объект не существует, mysqlbackup бросает ошибку и прерывает операцию.