WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 4. Резервирование сервера базы данных Эта секция объясняет приготовления, в которых вы нуждаетесь для создания резервных копий с MySQL Enterprise Backup, типичный цикл backup-verify-restore и различные сценарии для использования MySQL Enterprise Backup. Это также включает типовые команды и вывод показывая вам, как использовать mysqlbackup в различных ситуациях. 4.1. Перед первой резервной копией Эта секция обрисовывает в общих чертах некоторые приготовления, необходимые, прежде чем можно будет начать работать с MySQL Enterprise Backup. 4.1.1. Соберите информацию о базе данных Перед поддержкой конкретного сервера базы данных впервые, соберите некоторую информацию и используйте ее, чтобы принять некоторые решения планирования, как обрисовано в общих чертах в следующей таблице. Таблица 4.1. Необходимая информация, чтобы зарезервировать базу данных Информация Где найти Как ее использовать Путь к конфигурационному файлу MySQL. Системные местоположения по умолчанию, жестко заданные параметры приложений по умолчанию или опция --defaults-file в стартовом скрипте mysqld. Предпочтительный способ передать конфигурационную информацию базы данных mysqlbackup состоит в том, чтобы использовать опцию --defaults-file. Когда информация о связи и формате данных доступна от конфигурационного файла, вы больше не должны предоставлять отдельно большую часть упомянутой ниже информации. Порт MySQL. Конфигурационный файл MySQL или стартовый скрипт mysqld. Используется, чтобы соединиться с экземпляром базы данных во время операций резервного копирования. Определен через опцию --port mysqlbackup. Спецификация не необходима, если информация доступна от конфигурационного файла MySQL. Путь к каталогу данных MySQL. Конфигурационный файл MySQL или стартовый скрипт mysqld. Используется, чтобы восстановить файлы от экземпляра базы данных во время операций резервного копирования и скопировать файлы назад в базу данных во время операции восстановления. Автоматически восстановлен от соединения с базой данных. ID и пароль привилегированного пользователя MySQL. Вы делаете запись этого во время установки ваших собственных баз данных или получаете ее от DBA, поддерживая базы данных, которыми вы не владеете. Определен опцией --password mysqlbackup. Запрошен на терминале, если опция --password дана без аргумента пароля. Путь, под которым можно сохранить данные резервного копирования или метаданные, временно или постоянно. Вы выбираете это. Посмотрите раздел 4.1.3. В целом этот каталог должен быть пустым для mysqlbackup, чтобы писать данные в него. Владелец и данные полномочий для файлов (для систем Linux, Unix и OS X). В каталоге данных MySQL. Если вы выполняете резервную копию и восстанавливаете с использованием другого пользователя OS, чем тот, который управляет сервером, эта информация могла бы стать важной. Посмотрите раздел 4.2.1. Размер файлов журнала отката InnoDB. Вычислен из значений переменных конфигурации innodb_log_file_size и innodb_log_files_in_group. Используйте технику, объясненную для опции --incremental-with-redo-log-only. Нужно только, если вы выполняете возрастающие резервные копии, используя опцию --incremental-with-redo-log-only вместо --incremental. Размер журнала отката InnoDB и уровень поколения диктуют, как часто необходимо выполнить возрастающие резервные копии. Уровень, по которому произведены данные журнала отката. Вычислено из числа последовательности логических операций InnoDB в различных моментах времени. Используйте технику, объясненную для опцию --incremental-with-redo-log-only. Надо только, если вы выполняете возрастающие резервные копии, используя --incremental-with-redo-log-only вместо --incremental. Размер журнала отката InnoDB и уровень поколения диктуют, как часто необходимо выполнить возрастающие резервные копии. 4.1.2. Предоставьте привилегии администратору резервного копирования MySQL mysqlbackup соединяется с сервером MySQL, используя параметры, поставляемые опциями --user и --password. Указанный user нуждается в определенных привилегиях. Можно создать нового пользователя с ограниченным набором привилегий или использовать административную учетку, например, root. Вот привилегии, требуемые mysqlbackup: Минимальные привилегии для пользователя MySQL, с которым mysqlbackup работает с сервером, включают: SELECT на всех базах данных и таблицах для блокировок таблицы, которые защищают резервные копии от несоответствия, вызванного параллельными операциями DDL. BACKUP_ADMIN на всех базах данных и таблицах. RELOAD на всех базах данных и таблицах. SUPER, чтобы включить и отключить регистрацию и оптимизировать блокировку, чтобы минимизировать разрушение обработки базы данных. REPLICATION CLIENT, чтобы получить позицию двоичного журнала, которая сохранена резервной копией. PROCESS, чтобы обработать запросы с ALGORITHM = INPLACE. CREATE, INSERT, DROP и UPDATE на таблицах mysql.backup_progress и mysql.backup_history, а также SELECT и ALTER на mysql.backup_history. Чтобы создать пользователя MySQL (mysqlbackup в этом примере) и задать вышеупомянутые привилегии для пользователя, соединяющегося от localhost, сделайте в mysql: CREATE USER 'mysqlbackup'@'localhost' IDENTIFIED BY 'password'; GRANT SELECT, BACKUP_ADMIN, RELOAD, PROCESS, SUPER, REPLICATION CLIENT ON *.* TO `mysqlbackup`@`localhost`; GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE, SELECT, ALTER ON mysql.backup_history TO 'mysqlbackup'@'localhost'; Следующие дополнительные привилегии требуются для того, чтобы использовать определенные функции MySQL Enterprise Backup: Для использования transportable tablespaces (TTS), чтобы резервировать и восстановить таблицы InnoDB: LOCK TABLES для поддержки таблиц. CREATE для восстановления таблиц. DROP для удаления таблиц, если восстановление терпит неудачу по некоторым причинам. FILE для восстановления таблиц во внешних табличных пространствах за пределами каталога данных сервера. Для создания резервных копий на магнитную ленту, используя System Backup to Tape (SBT) API: CREATE, INSERT, DROP и UPDATE на таблице mysql.backup_sbt_history. Для работы с зашифрованными таблицыми InnoDB: ENCRYPTION_KEY_ADMIN, чтобы позволить ротацию ключа шифрования InnoDB. Для поддержки и восстановления созданных пользователями таблиц не-InnoDB: LOCK TABLES на всех схемах, содержащих созданные пользователями не-InnoDB таблицы. Для применения архивирования журнала отката для резервных копий: INNODB_REDO_LOG_ARCHIVE, чтобы вызвать определенную пользователями функцию innodb_redo_log_archive_start(). Установите эти дополнительные привилегии, если вы используете функции, которые их требуют. Чтобы установить их все, сделайте в mysql: GRANT LOCK TABLES, CREATE, DROP, FILE ON *.* TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, UPDATE ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost'; GRANT ENCRYPTION_KEY_ADMIN ON *.* TO 'mysqlbackup'@'localhost'; GRANT INNODB_REDO_LOG_ARCHIVE ON *.* TO 'mysqlbackup'@'localhost'; Для привилегий, требуемых для использования MySQL Enterprise Backup с Group Replication, см. главу 9. Следующие дополнительные привилегии могли бы также требоваться после модернизации сервера: Используя MySQL Enterprise Backup 8.0.19 или позже впервые на MySQL Server, который был модернизирован от 8.0.18 или ранее и был поддержан MySQL Enterprise Backup : ALTER на mysql.backup_progress. CREATE, INSERT и DROP на mysql.backup_progress_old. CREATE, INSERT, DROP и ALTER на mysql.backup_progress_new. Предоставьте эти привилегии, делая эти типовые запросы в mysql: GRANT ALTER ON mysql.backup_progress TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_progress_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_progress_new TO 'mysqlbackup'@'localhost'; Если вы работаете с Group Replication с несколькими ведущими, удостоверьтесь, что эти привилегии предоставляют на всех основных узлах, см. также главу 9. Эти привилегии для попытки мигрировать таблицу mysql.backup_progress к более новому формату (см. приложение F), они больше не необходимы после первой операции резервного копирования MySQL Enterprise Backup 8.0.19 или позже на сервере, поэтому они могут быть отменены. Используя MySQL Enterprise Backup 8.0.12 или позже впервые на MySQL Server, который был модернизирован от 8.0.11 или ранее и был поддержан MySQL Enterprise Backup : CREATE, INSERT и DROP на mysql.backup_history_old. CREATE, INSERT, DROP и ALTER на mysql.backup_history_new. Предоставьте эти привилегии, делая эти типовые запросы в mysql: GRANT CREATE, INSERT, DROP ON mysql.backup_history_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_history_new TO 'mysqlbackup'@'localhost'; Если вы работаете с Group Replication с несколькими ведущими, удостоверьтесь, что эти привилегии предоставляют на всех основных узлах, см. также главу 9. Эти привилегии нужны для попытки мигрировать таблицу mysql.backup_history к более новому формату (см. приложение D), и они больше не необходимы после первой операции резервного копирования MySQL Enterprise Backup 8.0.12 или позже, поэтому они могут быть отменены. Выполняя впервые резервную копию через SBT API с MySQL Enterprise Backup 8.0.21 или позже на MySQL Server, который был модернизирован от 8.0.20 или ранее и был поддержан MySQL Enterprise Backup через SBT API : ALTER на mysql.backup_sbt_history . CREATE, INSERT и DROP на mysql.backup_sbt_history_old. CREATE, INSERT, DROP и ALTER на mysql.backup_sbt_history_new. Предоставьте эти привилегии, делая эти типовые запросы в mysql: GRANT ALTER ON mysql.backup_sbt_history TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP ON mysql.backup_sbt_history_old TO 'mysqlbackup'@'localhost'; GRANT CREATE, INSERT, DROP, ALTER ON mysql.backup_sbt_history_new TO 'mysqlbackup'@'localhost'; Если вы работаете с Group Replication, удостоверьтесь, что эти привилегии предоставляют на всех основных узлах, см. также главу 9. Эти привилегии нужны для попытки мигрировать таблицу mysql.backup_sbt_history к более новому формату (см. приложение E), они больше не необходимы после первой операции резервного копирования MySQL Enterprise Backup 8.0.21 или позже с использованием SBT API на сервере, поэтому они могут быть отменены. Удостоверьтесь что предел MAX_QUERIES_PER_HOUR не установлен для пользователя mysqlbackup, чтобы получить доступ к серверу, или операции резервного копирования могут неожиданно потерпеть неудачу. 4.1.3. Определите местоположение для резервного каталога Большинство операций mysqlbackup, резервное копирование файлов, запись данных или метаданных, обращаются к определяемому каталогу, называемому резервным каталогом. См. описание для --backup-dir. Выберите заранее для этого каталога местоположение в файловой системе с достаточным местом, это может быть даже удаленный сервер. Вы определяете путь к этому каталогу с помощью опции --backup-dir. При использовании резервного каталога в качестве местоположения, чтобы сохранить ваши резервные копии, предпочтительно держать каждую резервную копию в подкаталоге с меткой времени под главным резервным каталогом. Чтобы заставить mysqlbackup создать эти подкаталоги автоматически, определите опцию --with-timestamp при запуске mysqlbackup. 4.2. Типичный цикл Backup/Verify/Restore Чтобы иллюстрировать основные шаги в создании и использовании резервной копии, рассмотрим как выполнить полное резервное копирование, проверим его, а затем вернем его на сервер. 4.2.1. Пользователь OS для управления mysqlbackup Linux и Unix-системы: mysqlbackup не делает запись принадлежности файла или разрешений файлов, которые резервируются. Чтобы гарантировать отсутствие проблемы разрешения файла и то, что сервер, который зарезервирован, будет восстановлен и перезапущен успешно, настоятельно рекомендовано выполнять mysqlbackup тем же самым пользователем OS, который управляет сервером MySQL (как правило, это mysql). Если это невозможно, обратите внимание на следующие рекомендации: Для резервных копий mysqlbackup должен управлять пользователь, который может прочитать все каталоги и файлы сервера. Чтобы удовлетворить это требование, пользователь OS, который управляет mysqlbackup, должен, например, быть владельцем группы файлов сервера и каталогов (как правило, mysql) как его основной или вторичной группы. Для восстановления, если mysqlbackup не управляет тот же самый пользователь, который управляет сервером, может быть очень трудно гарантировать, что у сервера есть доступ ко всем восстановленным файлам сервера, особенно в случае онлайн-восстановления, где сервер должен быть в состоянии получить доступ к файлам немедленно после того, как они восстановлены. Для офлайнового восстанавления вы, возможно, должны были бы, например, задать umask пользователю перед тем, как восстанавливать и урегулировать разрешения восстановленных файлов, используя серию команд chmod и chown, чтобы оригинальные разрешения для файлов были воспроизведены. 4.2.2. Поддержка всего экземпляра MySQL В следующем примере мы поддерживаем весь MySQL к единственному файлу, используя команду backup-to-image, которая появляется в конце типовой команды. Мы определяем часть информации о связи для базы данных, используя опции --user и --host (и --password, чтобы mysqlbackup запросил пароль). Местоположение и имя файла для единственного резервного копирования файлов определяются, используя опцию --backup-image, а местоположение пустого каталога, чтобы хранить временные файлы поставляется опцией --backup-dir. Вывод повторяет все параметры, используемые операцией резервного копирования, включая несколько, которые восстанавливаются, автоматически используя соединение с базой данных. Уникальный идентификатор для этого задания резервного копирования зарегистрирован в специальных таблицах, которые mysqlbackup составляет в экземпляре MySQL, позволяя вам контролировать продолжительные резервные копии и информацию о предыдущих резервных копиях. Секция окончательного результата повторяет местоположение данных резервного копирования и предоставляет значения LSN, которые вы могли бы использовать, когда вы выполняете инкрементное резервное копирование в следующий раз после полного резервного копирования, которое было сделано. $ mysqlbackup --user=mysqlbackup --password --host=127.0.0.1 \ --backup-image=/home/mysqlbackup/backups/my.mbi \ --backup-dir=/home/mysqlbackup/backup-tmpbackup-to-image MySQL Enterprise BackupVer 8.0.16-commercial for linux-glibc2.12 on x86_64 (MySQL Enterprise - Commercial) Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Starting with following command line ... mysqlbackup --user=mysqlbackup --password --host=127.0.0.1 --backup-image=/home/mysqlbackup/backups/my.mbi --backup-dir=/home/mysqlbackup/backup-tmp backup-to-image IMPORTANT: Please check that mysqlbackup run completes successfully. At the end of a successful 'backup-to-image' run mysqlbackup prints "mysqlbackup completed OK!". 190402 12:56:04 MAININFO: Starting to log actions. Enter password: 190402 12:56:09 MAININFO: No SSL options specified. 190402 12:56:09 MAININFO: MySQL server version is '8.0.16-commercial' 190402 12:56:09 MAININFO: MySQL server compile os version is 'linux-glibc2.12' 190402 12:56:09 MAININFO: Got some server configuration information from running server. 190402 12:56:09 MAININFO: Backup directory exists: '/home/mysqlbackup/backup-tmp' 190402 12:56:09 MAININFO: MySQL server version_comment is 'MySQL Enterprise Server - Commercial' 190402 12:56:09 MAININFO: Server is not a community server. 190402 12:56:09 MAININFO: KEF target path: '/home/mysqlbackup/backup-tmp/meta/keyring_kef' 190402 12:56:09 MAININFO: TDE Keyring service initialized. 190402 12:56:09 MAININFO: MEB logfile created at /home/mysqlbackup/backup-tmp/meta/MEB_2019-04-02.12-56-09_image_backup.log -------------------------------------------------------------------- Server Repository Options: -------------------------------------------------------------------- datadir= /home/admin/bin/mysql-commercial-8.0.16/datadir/ innodb_data_home_dir = innodb_data_file_path = ibdata1:12M:autoextend innodb_log_group_home_dir = /home/admin/bin/mysql-commercial-8.0.16/datadir/ innodb_log_files_in_group = 2 innodb_log_file_size = 50331648 innodb_undo_directory = /home/admin/bin/mysql-commercial-8.0.16/datadir/ innodb_undo_tablespaces = 2 innodb_buffer_pool_filename = ib_buffer_pool innodb_page_size = 16384 innodb_checksum_algorithm = crc32 -------------------------------------------------------------------- Backup Config Options: -------------------------------------------------------------------- datadir = /home/mysqlbackup/backup-tmp/datadir innodb_data_home_dir = /home/mysqlbackup/backup-tmp/datadir innodb_data_file_path = ibdata1:12M:autoextend innodb_log_group_home_dir = /home/mysqlbackup/backup-tmp/datadir innodb_log_files_in_group = 2 innodb_log_file_size = 50331648 innodb_undo_directory = /home/mysqlbackup/backup-tmp/datadir innodb_undo_tablespaces = 2 innodb_buffer_pool_filename = ib_buffer_pool innodb_page_size = 16384 innodb_checksum_algorithm = crc32 Backup Image Path = /home/mysqlbackup/backups/my.mbi 190402 12:56:09 MAININFO: Unique generated backup id for this is 15542241696070511 190402 12:56:09 MAININFO: Creating 14 buffers each of size 16777216. 190402 12:56:09 MAININFO: Full Image Backup operation starts with following threads 1 read-threads6 process-threads1 write-threads 190402 12:56:09 MAININFO: Found checkpoint at lsn 19840686. 190402 12:56:09 MAININFO: Starting log scan from lsn = 19840512 at offset = 32256 and checkpoint = 19840686 in file /home/admin/bin/mysql-commercial-8.0.16/datadir/ib_logfile0. 190402 12:56:09 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/backup-my.cnf. 190402 12:56:09 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/meta/backup_create.xml. 190402 12:56:09 RDR1INFO: Starting to copy all innodb files... 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/ibdata1. 190402 12:56:09 RDR1INFO: Starting to copy all undo files... 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/undo_002. 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/undo_001. 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/sys/sys_config.ibd. 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/pets/cats.ibd. 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/mysql/backup_history.ibd. 190402 12:56:09 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/mysql.ibd. 190402 12:56:10 RDR1INFO: Completing the copy of innodb files. 190402 12:56:10 RDR1INFO: Requesting a dump of the InnoDB buffer pool 190402 12:56:10 RDR1INFO: Waiting for the dump of the InnoDB buffer pool to complete 190402 12:56:10 RDR1INFO: The dump of the InnoDB buffer pool completed 190402 12:56:10 RDR1INFO: Binary Log Basename: '/home/admin/bin/mysql-commercial-8.0.16/datadir/binlog' 190402 12:56:10 RDR1INFO: Binary Log Index:'/home/admin/bin/mysql-commercial-8.0.16/datadir/binlog.index' 190402 12:56:10 RDR1INFO: Relay Channel:'group_replication_applier' 190402 12:56:10 RDR1INFO: Relay Log Basename: '/home/admin/bin/mysql-commercial-8.0.16/datadir/admin-XuBox-relay-bin-group_replication_applier' 190402 12:56:10 RDR1INFO: Relay Log Index:'/home/admin/bin/mysql-commercial-8.0.16/datadir/admin-XuBox-relay-bin-group_replication_applier.index' 190402 12:56:10 RDR1INFO: Relay Channel:'group_replication_recovery' 190402 12:56:10 RDR1INFO: Relay Log Basename: '/home/admin/bin/mysql-commercial-8.0.16/datadir/admin-XuBox-relay-bin-group_replication_applier-group_replication_recovery' 190402 12:56:10 RDR1INFO: Relay Log Index:'/home/admin/bin/mysql-commercial-8.0.16/datadir/admin-XuBox-relay-bin-group_replication_recovery.index' 190402 12:56:10 RDR1INFO: Starting to copy Binlog files... 190402 12:56:10 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/binlog.000001. 190402 12:56:10 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/binlog.000002. 190402 12:56:10 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/binlog.000003. 190402 12:56:10 RDR1INFO: Starting to lock instance for backup... 190402 12:56:10 RDR1INFO: No SSL options specified. 190402 12:56:10 RDR1INFO: The server instance is locked for backup. 190402 12:56:10 RDR1INFO: Starting to read-lock tables... 190402 12:56:10 RDR1INFO: No tables to read-lock. 190402 12:56:10 RDR1INFO: Opening backup source directory '/home/admin/bin/mysql-commercial-8.0.16/datadir' 190402 12:56:10 RDR1INFO: Starting to copy non-innodb files in subdirs of '/home/admin/bin/mysql-commercial-8.0.16/datadir' 190402 12:56:10 WTR1INFO: Adding database directory: datadir/mysql 190402 12:56:10 WTR1INFO: Adding database directory: datadir/performance_schema 190402 12:56:10 RDR1INFO: Completing the copy of all non-innodb files. 190402 12:56:10 WTR1INFO: Adding database directory: datadir/pets 190402 12:56:10 WTR1INFO: Adding database directory: datadir/sys 190402 12:56:10 RDR1INFO: Requesting consistency information... 190402 12:56:10 RDR1INFO: Locked the consistency point for 3089 microseconds. 190402 12:56:10 RDR1INFO: Consistency point server_uuid 'a01aa59f-5567-11e9-ad69-08002759ceb5'. 190402 12:56:10 RDR1INFO: Consistency point gtid_executed ''. 190402 12:56:10 RDR1INFO: Consistency point binary_log_file 'binlog.000004'. 190402 12:56:10 RDR1INFO: Consistency point binary_log_position 379. 190402 12:56:10 RDR1INFO: Consistency point InnoDB lsn 19840686. 190402 12:56:10 RDR1INFO: Consistency point InnoDB lsn_checkpoint 19840686. 190402 12:56:10 RDR1INFO: Requesting completion of redo log copy after LSN 19840686. 190402 12:56:10 RLR1INFO: Redo log reader waited = 0.00 ms for logs to generate. 190402 12:56:10 RLW1INFO: A copied database page was modified at 19840686. (This is the highest lsn found on a page) 190402 12:56:10 RLW1INFO: Scanned log up to lsn 19840686. 190402 12:56:10 RDR1INFO: Copying /home/admin/bin/mysql-commercial-8.0.16/datadir/binlog.000004. 190402 12:56:10 RDR1INFO: Completed the copy of binlog files... 190402 12:56:10 RDR1INFO: The server instance is unlocked after 0.085 seconds. 190402 12:56:10 RDR1INFO: Reading all global variables from the server. 190402 12:56:10 RDR1INFO: Completed reading of all 548 global variables from the server. 190402 12:56:10 RDR1INFO: Writing server defaults files 'server-my.cnf' and 'server-all.cnf' for server '8.0.16-commercial' in '/home/mysqlbackup/backup-tmp'. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/meta/backup_variables.txt. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/datadir/ibbackup_logfile. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/server-all.cnf. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/server-my.cnf. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/meta/backup_content.xml. 190402 12:56:10 RDR1INFO: Copying meta file /home/mysqlbackup/backup-tmp/meta/image_files.xml. 190402 12:56:10 MAININFO: Full Image Backup operation completed successfully. 190402 12:56:10 MAININFO: Backup image created successfully. 190402 12:56:10 MAININFO: Image Path = /home/mysqlbackup/backups/my.mbi 190402 12:56:10 MAININFO: MySQL binlog position: filename binlog.000004, position 379 ------------------------------------------------------------- Parameters Summary ------------------------------------------------------------- Start LSN: 19840512 End LSN: 19840686 ------------------------------------------------------------- mysqlbackup completed OK! 4.2.3. Проверка резервной копии Можно проверить целостность резервной копии, используя команду validate. Следующее это типовая команда для проверки образа резервной копии и вывод для успешной проверки: $ mysqlbackup --backup-image=/home/mysqlbackup/backups/my.mbi validate MySQL Enterprise BackupVer 8.0.16-commercial for linux-glibc2.12 on x86_64 (MySQL Enterprise - Commercial) Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Starting with following command line ... bin/mysqlbackup --backup-image=/home/mysqlbackup/backups/my.mbi validate IMPORTANT: Please check that mysqlbackup run completes successfully. At the end of a successful 'validate' run mysqlbackup prints "mysqlbackup completed OK!". 190401 17:27:14 MAININFO: Starting to log actions. 190401 17:27:14 MAININFO: Backup Image MEB version string: 8.0.16 [2019-03-2618:51:33] 190401 17:27:14 MAININFO: MySQL server version is '8.0.16' 190401 17:27:14 MAININFO: TDE Keyring service initialized. 190401 17:27:14 MAININFO: Creating 14 buffers each of size 16777216. 190401 17:27:14 MAININFO: Validate operation starts with following threads 1 read-threads6 process-threads 190401 17:27:14 MAININFO: Validating image ... /home/mysqlbackup/backups/my.mbi 190401 17:27:14 PCR1INFO: Validate: [Dir]: meta 190401 17:27:14 PCR1INFO: Validate: [Dir]: datadir/mysql 190401 17:27:14 PCR1INFO: Validate: [Dir]: datadir/performance_schema 190401 17:27:14 PCR1INFO: Validate: [Dir]: datadir/pets 190401 17:27:14 PCR1INFO: Validate: [Dir]: datadir/sys 190401 17:27:14 MAININFO: Total files as specified in image: 137 190401 17:27:14 MAININFO: datadir/ibdata1 validated. 190401 17:27:14 MAININFO: datadir/undo_002 validated. 190401 17:27:14 MAININFO: datadir/undo_001 validated. 190401 17:27:14 MAININFO: datadir/sys/sys_config.ibd validated. 190401 17:27:14 MAININFO: datadir/pets/cats.ibd validated. 190401 17:27:14 MAININFO: datadir/mysql/backup_history.ibd validated. 190401 17:27:14 MAININFO: datadir/mysql.ibd validated. 190401 17:27:14 MAININFO: Validate operation completed successfully. 190401 17:27:14 MAININFO: Backup Image validation successful. 190401 17:27:14 MAININFO: Source Image Path = /home/mysqlbackup/backups/my.mbi mysqlbackup completed OK! Кроме того, можно также проверить, что резервная копия была успешна, восстановив данные резервного копирования на ином сервере и запустив демон MySQL (mysqld) на новом каталоге данных. Можно тогда выполнить запросы SHOW, чтобы проверить базу данных и структуры таблиц и выполнить запросы, чтобы проверить более подробную информацию базы данных. Посмотрите раздел 4.2.4 для основных шагов для восстановления резервной копии и см. главу 5 для более подробных инструкций. Не пытайтесь проверить резервную копию при помощи резервного каталога как каталога данных, чтобы запустить сервер MySQL. Это грохнет сервер и могло бы также испортить вашу резервную копию. См. детали в приложении A. 4.2.4. Восстановление базы данных Чтобы восстановить MySQL из резервной копии на сервер базы данных: Закройте сервер базы данных. Удалите все файлы в каталоге данных сервера. Также удалите все файлы в каталогах, определенных опциями --innodb_data_home_dir, --innodb_log_group_home_dir и --innodb_undo_directory, если каталоги отличаются от каталога данных. Используйте, например, команду copy-back-and-apply-log, которая преобразовывает сырую резервную копию в подготовленную резервную копию, обновляя ее к последовательному статусу, а затем копирует таблицы, индексы, метаданные и любые другие необходимые файлы на целевой сервер. Для различных опций, которые можно определить для этой операции, посмотрите раздел 19.3. В примере ниже единственное резервное копирование файлов, созданное в примере, данном в разделе 4.2.2, восстановлено, используя команду copy-back-and-apply-log. Следующие опции используются: --datadir задает местоположение каталога данных для восстановления данных. Необходимо определить это для любой операции восстановления в командной строке или в файле по умолчанию. --backup-image обеспечивает путь к резервной копии файлов. --backup-dir обеспечивает местоположение пустого каталога, чтобы хранить некоторые временные файлы, созданные во время восстановления. $ mysqlbackup --datadir=/home/admin/bin/mysql-commercial-8.0.16/datadir \ --backup-image=/home/mysqlbackup/backups/my.mbi \ --backup-dir=/home/mysqlbackup/backup-tmp \ copy-back-and-apply-log MySQL Enterprise BackupVer 8.0.16-commercial for linux-glibc2.12 on x86_64 (MySQL Enterprise - Commercial) Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Starting with following command line ... mysqlbackup --datadir=/home/admin/bin/mysql-commercial-8.0.16/datadir --backup-image=/home/mysqlbackup/backups/my.mbi --backup-dir=/home/mysqlbackup/backup-tmp copy-back-and-apply-log IMPORTANT: Please check that mysqlbackup run completes successfully. At the end of a successful 'copy-back-and-apply-log' run mysqlbackup prints "mysqlbackup completed OK!". 190402 16:56:37 MAININFO: Starting to log actions. 190402 16:56:37 MAININFO: Backup directory exists: '/home/mysqlbackup/backup-tmp' 190402 16:56:37 MAININFO: Backup Image MEB version string: 8.0.16 [2019-03-2618:51:33] 190402 16:56:37 MAININFO: MySQL server version is '8.0.16' 190402 16:56:37 MAIN WARNING: If you restore to a server of a different version, the innodb_data_file_path parameter might have a different default. In that case you need to add 'innodb_data_file_path=ibdata1:12M:autoextend' to the target server configuration. 190402 16:56:37 MAIN WARNING: If you restore to a server of a different version, the innodb_log_files_in_group parameter might have a different default. In that case you need to add 'innodb_log_files_in_group=2' to the target server configuration. 190402 16:56:37 MAIN WARNING: If you restore to a server of a different version, the innodb_log_file_size parameter might have a different default. In that case you need to add 'innodb_log_file_size=50331648' to the target server configuration. 190402 16:56:37 MAININFO: Server is not a community server. 190402 16:56:37 MAININFO: KEF source path: '/home/mysqlbackup/backup-tmp/meta/keyring_kef' 190402 16:56:37 MAININFO: KEF target path: '/home/admin/bin/mysql-commercial-8.0.16/datadir/keyring_kef' 190402 16:56:37 MAININFO: TDE Keyring service initialized. 190402 16:56:37 MAININFO: MEB logfile created at /home/mysqlbackup/backup-tmp/meta/MEB_2019-04-02.16-56-37_copy_back_img_to_datadir.log -------------------------------------------------------------------- Server Repository Options: -------------------------------------------------------------------- datadir= /home/admin/bin/mysql-commercial-8.0.16/datadir innodb_data_home_dir = /home/admin/bin/mysql-commercial-8.0.16/datadir innodb_data_file_path= ibdata1:12M:autoextend innodb_log_group_home_dir= /home/admin/bin/mysql-commercial-8.0.16/datadir innodb_log_files_in_group= 2 innodb_log_file_size = 50331648 innodb_undo_directory= /home/admin/bin/mysql-commercial-8.0.16/datadir innodb_undo_tablespaces= 2 innodb_buffer_pool_filename= ib_buffer_pool innodb_page_size = Null innodb_checksum_algorithm= crc32 -------------------------------------------------------------------- Backup Config Options: -------------------------------------------------------------------- datadir= /home/mysqlbackup/backup-tmp/datadir innodb_data_home_dir = /home/mysqlbackup/backup-tmp/datadir innodb_data_file_path= ibdata1:12M:autoextend innodb_log_group_home_dir= /home/mysqlbackup/backup-tmp/datadir innodb_log_files_in_group= 2 innodb_log_file_size = 50331648 innodb_undo_directory= /home/mysqlbackup/backup-tmp/datadir innodb_undo_tablespaces= 2 innodb_buffer_pool_filename= ib_buffer_pool innodb_page_size = 16384 innodb_checksum_algorithm= crc32 190402 16:56:37 MAININFO: Creating 14 buffers each of size 16777216. 190402 16:56:37 MAININFO: Copy-back-and-apply-log operation starts with following threads 1 read-threads6 process-threads1 write-threads 190402 16:56:37 PCR1INFO: Copying database directory: meta 190402 16:56:37 RDR1INFO: Copying ibdata1. 190402 16:56:37 RDR1INFO: Copying undo_002. 190402 16:56:37 RDR1INFO: Copying undo_001. 190402 16:56:37 RDR1INFO: Copying sys/sys_config.ibd. 190402 16:56:37 RDR1INFO: Copying pets/cats.ibd. 190402 16:56:37 RDR1INFO: Copying mysql/backup_history.ibd. 190402 16:56:37 RDR1INFO: Copying mysql.ibd. 190402 16:56:37 RDR1INFO: Copying binlog.000001. 190402 16:56:37 RDR1INFO: Copying binlog.000002. 190402 16:56:37 RDR1INFO: Copying binlog.000003. 190402 16:56:37 PCR3INFO: Copying database directory: mysql 190402 16:56:37 PCR3INFO: Copying database directory: performance_schema 190402 16:56:37 PCR3INFO: Copying database directory: pets 190402 16:56:37 PCR3INFO: Copying database directory: sys 190402 16:56:37 RDR1INFO: Copying binlog.000004. 190402 16:56:37 MAININFO: Total files as specified in image: 138 190402 16:56:37 MAININFO: MySQL server version is '8.0.16-commercial' 190402 16:56:37 MAININFO: Restoring ...8.0.16-commercial version 190402 16:56:37 MAININFO: Copy-back operation completed successfully. 190402 16:56:37 MAININFO: Source Image Path = /home/mysqlbackup/backups/my.mbi 190402 16:56:37 MAININFO: MySQL server version is '8.0.16-commercial' 190402 16:56:37 MAININFO: Restoring ...8.0.16-commercial version 190402 16:56:37 MAININFO: Creating 14 buffers each of size 65536. 190402 16:56:37 MAININFO: Apply-log operation starts with following threads 1 read-threads1 process-threads6 apply-threads 190402 16:56:37 MAININFO: Using up to 100 MB of memory. 190402 16:56:37 MAININFO: ibbackup_logfile's creation parameters: start lsn 19841024, end lsn 19841405, start checkpoint 19841405. 190402 16:56:37 MAININFO: Loading the space id : 0, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/ibdata1. 190402 16:56:37 MAININFO: Apply log: Loading the undo space id : 4294967278, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/undo_002. 190402 16:56:37 MAININFO: Apply log: Loading the undo space id : 4294967279, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/undo_001. 190402 16:56:37 MAININFO: Loading the space id : 3, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/mysql/backup_history.ibd. 190402 16:56:37 MAININFO: Loading the space id : 2, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/pets/cats.ibd. 190402 16:56:37 MAININFO: Loading the space id : 1, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/sys/sys_config.ibd. 190402 16:56:37 MAININFO: Loading the space id : 4294967294, space name : /home/admin/bin/mysql-commercial-8.0.16/datadir/mysql.ibd. 190402 16:56:37 PCR1INFO: Starting to parse redo log at lsn = 19841394, whereas checkpoint_lsn = 19841405. 190402 16:56:37 PCR1INFO: Doing recovery: scanned up to log sequence number 19841405. 190402 16:56:37 PCR1INFO: Starting to apply a batch of log records to the database.... InnoDB: Progress in percent: 190402 16:56:37 PCR1INFO: Updating last checkpoint to 19841405 in redo log/ 190402 16:56:37 PCR1INFO: Setting log file size to 50331648 190402 16:56:37 PCR1INFO: Setting log file size to 50331648 190402 16:56:37 PCR1INFO: Log file header: format = 3 pad1 = 0 start lsn = 19841024 checkpoint lsn = 19841405 checksum = 2051460933 creator = MEB 8.0.16 190402 16:56:37 PCR1INFO: We were able to parse ibbackup_logfile up to lsn 19841405. 190402 16:56:37 PCR1INFO: Last MySQL binlog file position 0 379, file name binlog.000004 190402 16:56:37 PCR1INFO: The first data file is '/home/admin/bin/mysql-commercial-8.0.16/datadir/ibdata1' and the new created log files are at '/home/admin/bin/mysql-commercial-8.0.16/datadir' 190402 16:56:37 MAININFO: No Keyring file to process. 190402 16:56:37 MAININFO: Apply-log operation completed successfully. 190402 16:56:37 MAININFO: Full Backup has been restored successfully. mysqlbackup completed OK! with 3 warnings Теперь оригинальный каталог базы данных восстановлен из резервной копии. Старт восстановленного сервера. Когда следующие параметры настройки InnoDB отличаются на поддерживаемом и восстановленном сервере, важно сформировать восстановленный сервер с параметрами настройки от поддержанного сервера (иначе, ваш восстановленный сервер не может запуститься): innodb_data_file_path. innodb_log_file_size. innodb_log_files_in_group. innodb_page_size. innodb_checksum_algorithm. Если вы не уверены в тех параметрах настройки для вашего поддержанного сервера, они были на самом деле сохранены в файле backup-my.cnf во время резервной копии, можно найти файл во временном каталоге, который вы определили с --backup-dir, когда вы восстановили образ резервной копии, или в резервном каталоге, который вы могли создать, распаковав образ резервной копии, используя команду extract. Если значения этих опций отличаются от их значений в целевом сервере, добавьте их к конфигурационному файлу, который вы используете, чтобы запустить целевой сервер впоследствии, альтернативно можно также передать их как параметры командной строки mysqld. В зависимости от того, как вы собираетесь запустить восстановленный сервер, вы, возможно, должны были бы приспособить значение собственность восстановленного каталога данных. Например, если сервер будет запущен пользователем mysql, используйте следующую команду, чтобы изменить признак владельца каталога данных и файлов под ним к mysql и атрибут группы к mysql. $ chown -R mysql:mysql /path/to/datadir Вы теперь готовы запустить восстановленный сервер базы данных. Для большего количества обсуждений того, как выполнить различные варианты восстановления, посмотрите раздел 5.1. 4.3. Резервные сценарии и примеры 4.3.1. Создание однофайловой резервной копии Чтобы избежать получения большого количества резервных файлов, чтобы отслеживать, сохранить и транспортировать, mysqlbackup удобно создает резервные копии в единственном файле. Это может также упаковать существующий резервный каталог в единственный файл, распаковать единственный файл назад к резервному каталогу, перечислить содержание резервной копии, проверить содержание единственного резервного файла по вложенным контрольным суммам или извлечь единственный файл в дерево каталогов. Для синтаксиса соответствующих опций mysqlbackup см. раздел 20.9. Дополнительно: В то время как mysqlbackup может также создать директивную резервную копию (см. описание команды backup) вместо однофайловой резервной копии, однофайловый формат предпочтителен в большинстве случаев: с ним легче обращаться и определенные функции mysqlbackup не поддерживаются для директивных резервных копий, например, резервная копия в облако или на ленту с использованием System Backup to Tape (SBT) API. Всюду по руководству директивную резервную копию главным образом рассматривают как продвинутую тему, информация и примеры для директивных резервных копий отмечены тэгом дополнительно, как этот параграф. Поскольку резервное копирование файлов может передаваться по каналу к другому процессу, такому как резервное копирование на магнитную ленту или команда, можно использовать технику, чтобы поместить резервную копию на другое устройство хранения данных или сервер и избежать значительных издержек хранения на оригинальном сервере базы данных. Чтобы создать резервное копирование файлов, используйте команду backup-to-image . Следующие примеры иллюстрируют, как выполнить резервное копирование файлов и другие связанные операции. Пример 4.1. Резервное копирование файлов в абсолютный путь Эта команда создает единственный образ резервной копии на данном абсолютном пути. Это все еще требует --backup-dir, который используется, чтобы хранить временный вывод, статус и файлы метаданных. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --backup-image=/backups/sales.mbi --backup-dir=/backup-tmp \ backup-to-image Пример 4.2. Резервное копирование файлов в относительный путь Когда относительный путь вместо абсолютного пути поставлялся опцией --backup-image, путь взят относительно резервного каталога. Поэтому в этом примере получающееся резервное копирование файлов создается как /backups/sales.mbi. mysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-image=sales.mbi \ --backup-dir=/backups backup-to-image Пример 4.3. Резервное копирование файлов на стандартный вывод Следующая команда сбрасывает вывод на стандартный вывод. Каталог, определенный с опцией --backup-dir, используется в качестве временного каталога. mysqlbackup --defaults-file=/home/dbadmin/my.cnf --backup-dir=/backups \ --backup-image=- backup-to-image > /backup/mybackup.mbi Пример 4.4. Преобразовывает существующий резервный каталог в единственный образ Каталог backup-dir архивирован в файл /backup/my.mbi. mysqlbackup --backup-image=/backup/my.mbi --backup-dir=/var/mysql/backup \ backup-dir-to-image Пример 4.5. Извлекает существующий образ, чтобы сделать копию каталога Содержимое образа распаковано в backup-dir. mysqlbackup --backup-dir=/var/backup --backup-image=/backup/my.mbi \ image-to-backup-dir Пример 4.6. Список файлов из резервной копии Содержимое образа перечисляется в текстовом виде. Каждая строка указывает на запись файла или каталога. mysqlbackup --backup-image=/backup/my.mbi list-image Пример 4.7. Проверка резервного копирования файлов Следующая команда проверяет, что резервное копирование файлов не испорчено, не усечено и не повреждено, сверяя значение контрольной суммы для каждой страницы данных в резервной копии. mysqlbackup --backup-image=/logs/fullimage.mivalidate Пример 4.8. Извлечение резервной копии файлов в текущий каталог Следующая команда извлекает все содержание из однофайловой резервной копии файлов в текущий рабочий каталог. mysqlbackup --backup-image=/var/my.mbi extract Пример 4.9. Извлечение резервной копии файлов в резервный каталог Следующая команда извлекает все содержание из однофайловой резервной копии файлов в каталог, заданный опцией --backup-dir. mysqlbackup --backup-image=/var/my.mbi --backup-dir=/var/backup extract Пример 4.10. Выборочная распаковка Да, так можно! Следующая команда извлекает единственный файл meta/comments.txt из образа резервной копии my.mbi в локальный путь ./meta/comments.txt. mysqlbackup --backup-image=/var/my.mbi \ --src-entry=meta/comments.txt extract Следующая команда извлекает файл meta/comments.txt из образа резервной копии my.mbi в указанный путь /tmp/mycomments.txt с помощью опции --dst-entry. mysqlbackup --backup-image=/var/my.mbi \ --src-entry=meta/comments.txt \ --dst-entry=/tmp/mycomments.txt extract Следующая команда сбрасывает содержание meta/comments.txt (из файла резервной копии my.mbi) на стандартный вывод. mysqlbackup --backup-image=/var/my.mbi --src-entry=meta/comments.txt \ --dst-entry=- extract Пример 4.11. Выборочное извлечение единственного каталога Следующая команда извлекает единственный каталог meta из образа резервной копии my.mbi в путь локальной файловой системы ./meta. Все содержание каталога meta извлечено, включая любые подкаталоги. Заметьте слэш (/) в конце значения meta/ для --src-entry, без которого все файлы или каталоги, содержащие последовательность meta в их путях, будут извлечены. mysqlbackup --backup-image=/backup/my.mbi --src-entry=meta/ extract Пример 4.12. Работа с абсолютными путями Так как абсолютные пути извлечены к тем же самым путям в местной системе, это могло быть проблемой, если вы не имеете разрешение на запись для этого пути. Можно переотобразить абсолютные пути следующим образом: mysqlbackup --backup-image=/backup/my.mbi --src-entry=/ \ --dst-entry=/myroot extract mysqlbackup --backup-image=/backup/my.mbi --src-entry=. extract Первая команда извлекает все абсолютные пути к каталогу /myroot в местной системе. Вторая команда извлекает все относительные пути к текущему каталогу. 4.3.1.1. Трансляция данных резервного копирования к другому устройству или серверу Чтобы ограничить издержки хранения на сервере базы данных, можно передать данные резервного копирования иному серверу, никогда не храня их в местном масштабе. Можно достигнуть этого с однофайловым резервным копированием. Чтобы послать резервную копию файлов в стандартный вывод, используйте команду backup-to-image без опции --backup-image. Можно также определить --backup-image=-, чтобы сделать очевидным то, что данные посылают в stdout. Чтобы передать данные, вы используете резервное копирование файлов в сочетании с особенностями операционной системы, такими как каналы, ssh или что-то вроде этого, которые берут запись от стандартного вывода и создают эквивалентный файл в удаленной системе. Можно сохранить резервную копию файлов непосредственно в удаленной системе или вызвать с командой copy-back-and-apply-log на другом конце, чтобы вернуть резервную копию удаленному серверу MySQL. Пример 4.13. Резервное копирование файлов на удаленный хост Следующая команда передает резервную копию как вывод удаленному хосту, чтобы записать под именем файла my_backup.img (--backup-dir=/tmp определяет каталог для того, чтобы хранить временные файлы, а не файл окончательного результата): mysqlbackup --defaults-file=~/my_backup.cnf --backup-image=- \ --backup-dir=/tmp backup-to-image | \ ssh <user name>@<remote host name> \ 'cat > ~/backups/my_backup.img' Для простоты вся связь и другие необходимые опции, как предполагается, определяются в конфигурационном файле по умолчанию. ssh может быть заменен другим протоколом связи, например, ftp, cat может быть заменена другой командой (например, dd или tar для нормального архивирования). Пример 4.14. Резервное копирование файлов на удаленный сервер MySQL Следующая команда передает резервную копию как единственный резервный файл, который будет восстановлен на удаленном сервере MySQL: mysqlbackup--backup-dir=backup --backup-image=---compress backup-to-image | \ ssh <user name>@<remote host name> \ 'mysqlbackup --backup-dir=backup_tmp --datadir=/data \ --innodb_log_group_home_dir=. --uncompress --backup-image=- \ copy-back-and-apply-log' Пример 4.15. Передача резервного каталога удаленному серверу MySQL Следующая команда передает резервный каталог как единственный резервный файл, который будет восстановлен на удаленном сервере MySQL: mysqlbackup --backup-image=- --backup-dir=/path/to/my/backup \ backup-dir-to-image | \ ssh <user name>@<remote host name> \ 'mysqlbackup --backup-dir=backup_tmp --datadir=/data --backup-image=- \ copy-back-and-apply-log' 4.3.1.2. Резервирование, чтобы записать на ленту Лентопротяжные устройства это доступные устройства хранения данных большой емкости для данных резервного копирования. MySQL Enterprise Backup может взаимодействовать с программным обеспечением управления (MMS), например, Oracle Secure Backup (OSB) для резервирования и восстановления. Программное обеспечение управления должно поддерживать интерфейс System Backup To Tape (SBT) Version 2 или выше. Для получения информации о выполнении резервных копирований на магнитную ленту в сочетании с продуктами MMS, такими как Oracle Secure Backup, см. главу 11. 4.3.1.3. Резервирование в облачное хранилище MySQL Enterprise Backup поддерживает облачное резервирование. Только однофайловое резервное копирование может быть создано и восстановлено от облачного хранилища. Все опции mysqlbackup, совместимые с операциями единственного файла (включая, например, incremental, compression, partial и encryption), могут использоваться с облачными резервными копиями. См. приложение B для некоторых ограничений относительно поддержки облачного хранилища mysqlbackup. MySQL Enterprise Backup понимает следующие типы облачных хранилищ: Oracle Cloud Infrastructure (OCI) Object Storage. OpenStack Swift или совместимые услуги хранения объектов. Amazon Simple Storage Service (S3) или совместимые услуги хранения объектов. GCP object storage. Облачная резервная копия создается, используя возможности облака для mysqlbackup, которые детально описаны в разделе 20.15. Вот некоторые типовые команды для создания облачной резервной копии: Пример 4.16. Создания облачной резервной копии на Oracle Cloud Infrastructure Object Storage Этот пример создает облачную резервную копию в Oracle Cloud Infrastructure (OCI) Object Storage, используя Pre-Authenticated Request (PAR) URL. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --backup-dir=/home/dbadmin/backuptmp \ --with-timestamp --backup-image=- --cloud-service=OCI \ --cloud-par-url=<bucket_PAR_URL> \ --cloud-object=backup.bk backup-to-image Пример 4.17. Создания инкрементного облачного резервного копирования в Oracle Cloud Infrastructure Этот пример создает возрастающую облачную резервную копию в Oracle Cloud Infrastructure (OCI) Object Storage с применением Pre-Authenticated Request (PAR) URL. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --backup-dir=/home/dbadmin/backuptmp --with-timestamp \ --backup-image=- --cloud-service=OCI \ --cloud-par-url=<bucket_PAR_URL> --cloud-object=backup-inc.bk \ --incremental --incremental-base=history:last_backup \ backup-to-image Пример 4.18. Создание облачной резервной копии на OpenStack Этот пример создает облачную резервную копию на OpenStack, используя сервис Keystone identity service, чтобы подтвердить подлинность учетных данных пользователя. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --include-tables=testdb.t1 --use-tts=with-full-locking \ --cloud-service=openstack--cloud-container=<swift container> \ --cloud-user-id=<keystone user> \ --cloud-password=<keystone password> \ --cloud-region=<keystone region> \ --cloud-tenant=<keystone tenant> \ --cloud-identity-url=<keystone url>\ --cloud-trace=1 --cloud-object=image_800.mbi \ --backup-dir=/home/dba/opbackuptmpdir \ --backup-image=- backup-to-image Пример 4.19. Создание облачной резервной копии на Amazon S3 Bucket Этот пример создает облачную резервную копию в Amazon S3 bucket. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --cloud-service=s3 --cloud-aws-region=<aws region> \ --cloud-access-key-id=<aws access key id> \ --cloud-secret-access-key=<aws secret access key> \ --cloud-bucket=<s3 bucket name> \ --cloud-object-key=<aws object key> \ --backup-dir=/home/dba/s3backupdir --with-timestamp \ --backup-image=- backup-to-image Пример 4.20. Создание инкрементного резервного копирования в облаке Amazon S3 Bucket Этот пример создает инкрементное резервное копирование в облаке на Amazon S3 bucket. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --cloud-service=s3 --cloud-aws-region=<aws region> \ --cloud-access-key-id=<aws access key id> \ --cloud-secret-access-key=<aws secret access key> \ --cloud-bucket=<s3 bucket name> \ --cloud-object-key=<aws object key> \ --backup-dir=/home/dba/s3backupdir --with-timestamp \ --backup-image=- --incremental \ --incremental-base=history:last_backup backup-to-image Пример 4.21. Создание облачной резервной копии в GCP Storage Service Этот пример создает облачную резервную копию в GCP storage service. mysqlbackup --defaults-file=/home/dbadmin/my.cnf --cloud-service=GCP \ --cloud-bucket=<bucket name> \ --cloud-object=<object name> \ --cloud-access-key=<access name> \ --cloud-secret-key=<secret key> \ --backup-dir=/home/dba/backupdir --with-timestamp \ --backup-image=- backup-to-image Облачная резервная копия всегда использует один поток записи. Кроме того, backup-to-image, все другие операции mysqlbackup для однофайлового резервного копирования ( backup-dir-to-image, list-image, validate, image-to-backup-dir, extract, copy-back и copy-back-and-apply-log) также могут быть выполнены с облачным хранилищем (см. приложение B для некоторых ограничений). См. раздел 5.2 о том, как восстановить образ резервной копии из облачного хранилища. 4.3.2. Создание полного резервного копирования Большинство стратегий резервного копирования начинается с полной резервной копии сервера MySQL, из которой можно восстановить все базы данных и таблицы. После того, как вы создали полное резервное копирование, вы могли бы выполнить возрастающие резервные копии (которые меньше и быстрее) для следующих нескольких резервных задач. Вы делаете полное резервное копирование периодически, чтобы начать цикл снова. Для типовых команд для того, чтобы сделать полное резервное копирование, посмотрите раздел 4.2.2. Эта секция обрисовывает в общих чертах некоторые вещи, которые надо рассмотреть, выбирая стратегию создания полного резервного копирования. Как мы будем видеть, такие факторы как скорость и удобство важны для ваших решений. Опции в командной строке или в конфигурационном файле? Для ясности примеры в этом руководстве часто показывают некоторые параметры командной строки, которые используются с командами mysqlbackup. Для удобства и последовательности можно включить те варианты, которые остаются неизменными для большинства заданий резервного копирования в секцию [mysqlbackup] конфигурационного файла MySQL, который вы поставляете mysqlbackup. mysqlbackup также берет опции из секции [mysqld], если они присутствуют там. Помещение вариантов в конфигурационный файл может упростить управление, например, помещая информацию о порте в конфигурационный файл, можно избежать потребности редактировать скрипты каждый раз, когда экземпляр базы данных переключается на иной порт. См. главу 21 для получения дополнительной информации об использовании конфигурационных файлов. Использовать единственный резервный каталог или подкаталоги с меткой времени? Для удобства опция --with-timestamp создает исключительно подкаталоги, названные в соответствии с резервным каталогом, чтобы хранить данные резервного копирования (постоянные или временные) и метаданные. Подкаталоги с меткой времени делают более простым установку периодов хранения, позволяя легкое удаление и архивацию данных резервного копирования, которые превысили определенный возраст. Если вы действительно используете единственный резервный каталог (то есть, если вы опускаете опцию --with-timestamp), определите новое уникальное имя каталога для каждого задания резервного копирования. Для возрастающих резервных копий, которые используют опцию --incremental-base, чтобы определить каталог, содержащий предыдущую резервную копию, чтобы сделать имена каталогов предсказуемыми, вы могли бы предпочесть не использовать опцию --with-timestamp и производить последовательность имен каталогов вашим скриптом резервирования вместо этого. Всегда полное резервное копирование или полное резервное копирование плюс возрастающие резервные копии? Если ваш объем данных InnoDB небольшой или если ваша база данных так занята, что высокий процент данных изменяется между резервными копиями, вы могли бы хотеть делать полное резервное копирование каждый раз. Однако, можно обычно сэкономить время и память, делая полное резервное копирование, а затем несколько возрастающих промежуточных резервных копий, как описано в разделе 4.3.3. Использовать сжатие или нет? Создание сжатой резервной копии может сэкономить вам значительное место и уменьшить использование I/O. С методом сжатия LZ4 издержки обработки сжатия довольно низкие. В случаях, когда резервные копии базы данных перемещаются от более быстрой дисковой системы, где активные файлы базы данных находятся, к возможно более медленному хранилищу, сжатие будет часто значительно ниже полного времени резервного копирования. Это может закончиться уменьшением времени восстановления. В целом мы рекомендуем сжатие LZ4 для большинства пользователей, поскольку основанные на LZ4 резервные копии часто делаются быстрее. Однако, проверьте MySQL Enterprise Backup в своей среде, чтобы определить то, что является самым эффективным подходом. Для большего количества обсуждений сжатых резервных копий посмотрите раздел 4.3.4. 4.3.3. Создание дифференциального или инкрементного резервного копирования Если объем данных по вашему серверу MySQL остается неизменным со временем, можно увеличить скорость и уменьшить необходимое место в памяти для регулярных резервных копий, поддержав не все данные сервера каждый раз, а только изменения данных, которые происходили со временем. Для этого после создания сначала полного резервного копирования, которое содержит все данные, можно сделать одно из следующего: Выполнение дифференциального резервного копирования. Каждое дифференциальное резервное копирование включает все изменения, внесенные в данные, начиная с последнего полного резервного копирования. Чтобы восстановить данные до, например, времени t, вы просто восстанавливаете сначала полное резервное копирование, затем поверх него дифференциальное резервное копирование, взятое в течение времени t. Выполните серию инкрементных резервных копий Каждая инкрементная резервная копия включает только изменения начиная с предыдущей резервной копии, которая самостоятельно может быть полным резервным копированием или инкрементным резервным копированием. Первая резервная копия в возрастающем ряду это всегда дифференциальное резервное копирование, но после этого каждая инкрементная резервная копия содержит только изменения, внесенные начиная с того последнего инкрементного резервного копирования. Каждое последующее инкрементное резервное копирование таким образом обычно меньше в размере, чем дифференциальное резервное копирование и быстрее, это позволяет вам делать очень частые возрастающие резервные копии, а затем позволяет вам вернуть базу данных более точному моменту времени при необходимости. Однако восстановление данных с возрастающими резервными копиями могло бы занять больше времени и больше работы: в целом, чтобы восстановить данные до, например, времени t, вы начинаете с восстановления полного резервного копирования, затем восстанавливаете возрастающие резервные копии по порядку, пока не дойдете до инкрементной резервной копии, взятой в течение времени t. MySQL Enterprise Backup понимает возрастающее и дифференциальное резервное копирование. Необходимо выбрать, какую стратегию резервного копирования принять, смотря на такие факторы как то, сколько памяти вы имеете, как быстро необходимо быть в состоянии восстановить данные и так далее. MySQL Enterprise Backup рассматривает дифференциальное резервное копирование как особый случай инкрементного резервного копирования, у которого есть полное резервное копирование как его основа. Чтобы создать дифференциальное резервное копирование, просто следуйте инструкциям ниже для выполнения возрастающих резервных копий и удостоверьтесь, что вы определяете полное резервное копирование как основу вашего инкрементного резервного копирования, необходимо также проигнорировать любые инструкции, которые относятся только к обработке многочисленных возрастающих резервных копий. MySQL Enterprise Backup 8.0.17 и позже : можно создать дифференциальное резервное копирование, используя опцию --incremental-base=history:last_full_backup. См. раздел 20.7 для описаний опций mysqlbackup, используемых для возрастающих резервных копий. Инкрементное резервное копирование позволено с одним из этих двух вариантов: --incremental и --incremental-with-redo-log-only. См. здесь описание их различий. Создавая инкрементное резервное копирование, необходимо указать mysqlbackup на момент времени предыдущего полного резервного копирования или инкрементного резервного копирования. Для удобства можно использовать опцию --incremental-base , чтобы автоматически получить необходимый log sequence number (LSN) из метаданных, сохраненных в предыдущем резервном каталоге или на сервере. Или можно определить явное значение LSN, используя параметр --start-lsn, предоставляя mysqlbackup последний LSN из предыдущего полного резервного копирования или инкрементного резервного копирования (см. ограничения, которые применяются, используя опцию --start-lsn). Чтобы подготовить данные резервного копирования, которые будут восстановлены, вы объединяете все возрастающие резервные копии с оригинальным полным резервным копированием. Как правило, вы выполняете новое полное резервное копирование после определенного промежутка времени, после которого можно отказаться от более старых данных об инкрементном резервном копировании. Создание возрастающих резервных копий, используя только журнал отката Опция --incremental-with-redo-log-only может предложить некоторые выгоды по сравнению с --incremental для создания инкрементного резервного копирования: Изменения таблиц InnoDB определяются на основе содержания журнала отката InnoDB. Так как у файлов журнала отката есть фиксированный размер, который вы знаете заранее, он может потребовать меньше I/O, чтобы прочитать изменения из них, чем просмотр файлов табличного пространства InnoDB, чтобы определить местонахождение измененных страниц, в зависимости от размера вашей базы данных, объема деятельности DML и размера файлов журнала отката. Файлы журнала отката работают как кольцевой буфер с более старыми изменениями, переписываемыми по мере того, как происходят новые операции DML. Поэтому необходимо взять новые возрастающие резервные копии по предсказуемому графику, продиктованному размером файлов журнала и размером данных, произведенных для рабочей нагрузки. Иначе журнал отката не мог бы уйти назад достаточно далеко, чтобы сделать запись всех изменений с предыдущего инкрементного резервного копирования, в этом случае mysqlbackup решит, что не может продолжать и возвратит ошибку. Ваш резервный сценарий должен быть в состоянии зафиксировать эту ошибку и затем выполнить инкрементное резервное копирование с опцией --incremental. Например, вот так: Чтобы вычислить размер журнала отката, дайте команду SHOW VARIABLES LIKE 'innodb_log_file%' и на основе ее вывода, увеличьте innodb_log_file_size значением innodb_log_files_in_group. Чтобы вычислить размер журнала отката на физическом уровне, изучите каталог datadir MySQL и сложите размеры файлов, соответствующих образцу ib_logfile*. Значение InnoDB LSN соответствует числу байтов, написанных в журнал отката. Чтобы проверить LSN в какой-то момент времени, дайте команду SHOW ENGINE INNODB STATUS и посмотрите заголовок LOG. Планируя вашу стратегию резервного копирования, делайте запись значений LSN периодически и вычитайте более раннее из текущего, чтобы вычислить, сколько данных производится каждый час, день и так далее. Этот тип инкрементного резервного копирования не настолько игнорирует низкие значения --start-lsn как обычная опция --incremental. Например, вы не можете сделать полное резервное копирование и затем сделать серию резервных копий --incremental-with-redo-log-only с использованием того же самого значения --start-lsn. Удостоверьтесь, что определили точный конец LSN предыдущей резервной копии как начало LSN следующего инкрементного резервного копирования, не используйте произвольные значения. Чтобы гарантировать, что значения LSN совпадают точно между последовательными возрастающими резервными копиями, рекомендуется, чтобы вы всегда использовали опцию --incremental-base , когда вы используете опцию --incremental-with-redo-log-only. Чтобы определить, практичен ли этот тип инкрементного резервного копирования и эффективен ли он для конкретного случая MySQL: Измерьте, как быстро данные изменяются в файлах журнала отката InnoDB. Проверьте периодически LSN, чтобы решить, сколько данных накапливается в течение некоторого числа часов или дней. Сравните темп накопления журнала отката с размером файлов журнала отката. Используйте это отношение, чтобы видеть, как часто взять инкрементное резервное копирование, чтобы избежать вероятности провала резервной копии, потому что исторические данные недоступны в журнале отката. Например, если вы производите 1 ГБ данных журнала отката в день и объединенный размер ваших файлов журнала отката составляет 7 ГБ, вы намечали бы возрастающие резервные копии более часто, чем один раз в неделю. Вы могли бы выполнять возрастающие резервные копии каждый день или два, чтобы избежать потенциальной проблемы, когда внезапный всплеск обновлений произвел больше данных журнала отката, чем обычно. Определите эффективность времени инкрементного резервного копирования, используя опции --incremental и --incremental-with-redo-log-only, чтобы подтвердить, работает ли метод резервной копии журнала отката быстрее и с меньшими издержками, чем традиционный метод инкрементного резервного копирования. Результат может зависеть от размера ваших данных, объема деятельности DML и размера ваших файлов журнала отката. Сделайте свое тестирование на сервере с реалистическим объемом данных и реалистической рабочей нагрузкой. Например, если у вас есть огромные файлы журнала отката, их чтение в ходе инкрементного резервного копирования могло бы занять больше времени, чем чтение файлов данных InnoDB, используя традиционную возрастающую технику. С другой стороны, если ваш объем данных большой, читать все файлы данных, чтобы найти несколько измененных страниц, могло бы быть менее эффективным, чем обработка намного меньших файлов журнала отката. Резервное сжатие (то есть использование опций сжатия) не поддерживается, когда вы выполняете возрастающие резервные копии только с журналом отката. Если резервное сжатие важно для вас, не используйте опцию --incremental-with-redo-log-only. Инкрементное резервное копирование, используя отслеживание страницы For MySQL Enterprise Backup 8.0.18 и выше: mysqlbackup понимает создание возрастающих резервных копий, используя функциональность отслеживания страницы MySQL Server, которой mysqlbackup ищет измененные страницы в файлах данных InnoDB, которые были изменены, начиная с последней резервной копии и затем копирует их. В целом возрастающие резервные копии, используя отслеживание страницы быстрее, чем другие виды возрастающих резервных копий, выполненных mysqlbackup, если большинство данных в базе данных не было изменено. Использование этой функции требует, чтобы следующее было сделано на сервере, прежде чем основная резервная копия для инкрементного резервного копирования будет сделана: Установите компонент mysqlbackup, который идет с MySQL Enterprise Server 8.0, этой командой в mysql: INSTALL COMPONENT "file://component_mysqlbackup"; Начните отслеживание страницы со следующей определенной пользователями функцией (UDF): SELECT mysqlbackup_page_track_set(true); Значение LSN, начиная с которого были прослежены измененные страницы, возвращено этой UDF: SELECT mysqlbackup_page_track_get_start_lsn(); Можно остановить отслеживание страницы со следующим UDF: SELECT mysqlbackup_page_track_set(false); Вышеупомянутые UDF для отслеживания страницы требуют привилегии BACKUP_ADMIN. Когда опция --incremental используется без любого определенного значения, mysqlbackup выполняет инкрементное резервное копирование, используя функциональность отслеживания страницы. Пользователь может также определять --incremental=page-track, чтобы заставить mysqlbackup использовать функциональность отслеживания страницы. Однако, для использования функциональности отслеживания страницы для возрастающих резервных копий нужно соответствовать ряду требований: Отслеживание страницы функционирует правильно на сервере, и это было позволено (с помощью SELECT mysqlbackup_page_track_set(true)) прежде, чем основная резервная копия была создана, если это не так mysqlbackup бросает ошибку, когда --incremental=page-track , или выполняет инкрементное резервное копирование полного просмотра вместо этого, когда не задана --incremental. Число измененных страниц составляет меньше 50% общего количества страниц, если это не так mysqlbackup бросает ошибку, когда --incremental=page-track , или выполняет инкрементное резервное копирование полного просмотра вместо этого, когда не задана --incremental. mysqlbackup должен быть запущен с достаточной памятью, чтобы обработать все отслеженные страницы в памяти. Если недостаточно памяти, mysqlbackup бросает ошибку и затем завершается. Вот некоторые рекомендации для проверки наличия достаточной памяти для операции: Значение по умолчанию 400 [MB] для опции --limit-memory позволяет mysqlbackup обрабатывать приблизительно 800 ГБ измененных данных. Приспособьте значение опции согласно вашему размеру данных. Отслеживание страниц использует буферы памяти, формируемые для mysqlbackup для сортировки страниц. Определите количество буферов, необходимых для сортировки страницы: Прежде, чем запустить резервирование, выполните следующий запрос на сервере, чтобы определить end_lsn для основной резервной копии: SELECT end_lsn FROM mysql.backup_history WHERE exit_state = 'SUCCESS' AND backup_type != 'TTS' AND server_uuid = @@server_uuid ORDER BY end_time DESC, end_lsn DESC LIMIT 0,1; Выполните такой запрос на сервере, чтобы получить число измененных страниц, с того момента, когда основная резервная копия была создана (повторите вопрос, если это возвращает отрицательную величину): SELECT mysqlbackup_page_track_get_changed_page_count(<the above end_lsn>, 0); Каждой измененной странице нужны 8 байтов в буфере сортировки. Так что умножьте changed_page_count, полученное на последнем шаге, на 8, чтобы получить число байтов, необходимых для буфера сортировки. У каждого буфера есть предел в 16 мегабайтов (16777216 байтов). Так что разделите число байтов, необходимых для буферов сортировки, вычисленное на последнем шаге, на 16777216 и округлите результат до следующего целого числа, чтобы получить количество буферов, необходимых для сортировки. Удостоверьтесь, что для опции --number-of-buffers не меньше, чем количество необходимых буферов сортировки вычисленное на последнем шаге. Помните, что могут быть более измененные страницы, созданные в то время, как вы делаете это вычисление, таким образом, может быть надо дать mysqlbackup еще несколько дополнительных буферов. Предел памяти по умолчанию 400 МБ должен быть в состоянии поддержать до 25 буферов (до 18 буферов только для облачных резервных копий), увеличьте предел памяти, если вам нужно больше буферов, чем это, изменяя значение --limit-memory. Полный просмотр против оптимистического инкрементного резервного копирования Когда опция --incremental установлена в full-scan, mysqlbackup выполняет инкрементное резервное копирование полного просмотра, в котором просматривает все файлы данных InnoDB в каталоге данных сервера, чтобы найти страницы, которые были изменены после того, как последняя резервная копия была сделана, а затем копирует те страницы. Инкрементное резервное копирование полного просмотра не может быть очень эффективным, если мало таблиц были изменены с последнего резервирования. Оптимистическое инкрементное резервное копирование, с другой стороны, ищет только измененные страницы в файлах данных InnoDB, которые были изменены, начиная с последней резервной копии, таким образом сэкономив некоторое ненужное время просмотра. Оптимистическое инкрементное резервное копирование может быть выполнено, определив --incremental=optimistic. В то время как оптимистическая резервная копия могла бы сократить время резервного копирования, у нее есть следующие ограничения: Так как эта особенность использует время изменения файлов в каталоге данных сервера, две вещи должны оставаться неизменными, начиная с предыдущей резервной копии: (1) системное время на сервере и (2) местоположение каталога данных. Иначе резервная копия могла бы потерпеть неудачу или могло бы быть произведено непоследовательное инкрементное резервное копирование. Оптимистические возрастающие резервные копии не могут быть выполнены с --incremental-with-redo-log-only, для которого mysqlbackup читает файлы журнала отката вместо того, чтобы просмотреть файлы в каталоге данных. Если применена опция --start-lsn, полный просмотр выполняется, даже если определяется --incremental=optimistic , в этом случае mysqlbackup не может определить момент времени, для которого предыдущая резервная копия последовательна, и таким образом нет временной структуры, чтобы определить, какие файлы были недавно изменены. Для этих и других случаев, в которых оптимистическое инкрементное резервное копирование нежелательно, выполните инкрементное резервное копирование полного просмотра или инкрементное резервное копирование, используя отслеживание страницы (для MySQL Enterprise Backup 8.0.18 и позже). Посмотрите раздел 4.1.2 для привилегий, требуемых для mysqlbackup, чтобы выполнить оптимистическое инкрементное резервное копирование. Также посмотрите здесь о том, как использовать две особенности вместе в расписании резервного копирования. For MySQL Enterprise Backup 8.0.17 и ранее : резервная копия полного просмотра это метод по умолчанию для возрастающих резервных копий, который используется, если никакое значение не определяется для --incremental. Другие соображения для возрастающих резервных копий Особенность инкрементного резервного копирования, прежде всего предназначается для таблиц InnoDB или не-InnoDB таблиц, которые используются только для чтения или редко обновлены. Возрастающие резервные копии обнаруживают изменения на уровне страниц в файлах данных InnoDB в противоположность строкам таблицы, каждая страница, которая изменилась, резервируется целиком. Таким образом экономии пространства и времени не точно пропорциональны проценту измененных строк или колонок InnoDB. Для не-InnoDB файлов весь файл всегда включается в инкрементное резервное копирование, это означает, что экономия ресурсов менее значительна, чем в случае с таблицами InnoDB. Никакие двоичные файлы журнала не копируются в инкрементное резервное копирование, если применена опция the --start-lsn. Чтобы включать файлы двоичного журнала в течение периода, покрытого инкрементным резервным копированием, используйте опцию --incremental-base , которая предоставляет необходимую информацию для mysqlbackup, чтобы гарантировать, что никакой промежуток не существует между данными, включенными в предыдущую резервную копию и текущим инкрементным резервным копированием. Примеры возрастающих резервных копий Эти примеры используют mysqlbackup, чтобы сделать инкрементное резервное копирование сервера MySQL, включая все базы данных и таблицы. Мы показываем две альтернативы: использование опции --incremental-base и опции --start-lsn. С опцией --incremental-base вы не должны отслеживать LSN между одной резервной копией и следующей. Вместо этого можно сделать одно из следующего: Скажите mysqlbackup запросить end_lsn из последней успешной резервной копии не-TTS, как зарегистрировано в таблице backup_history сервера, применив --incremental-base =history:last_backup или history:last_full_backup (для 8.0.17 и позже). Дополнительно: Для директивных резервных копий определите каталог предыдущей резервной копии (полной или возрастающей) с --incremental-base=dir: directory_path, mysqlbackup выяснит отправную точку для этой резервной копии на основе метаданных. Поскольку вам нужен известный набор имен каталогов, вы могли бы хотеть использовать жестко заданные имена или произвести последовательность имен в вашем собственном резервном скрипте вместо того, чтобы использовать опцию --with-timestamp. Если ваша последняя резервная копия была однофайловой, можно использовать --incremental-base=dir: directory_path, чтобы обеспечить местоположение временного каталога, заданного --backup-dir во время последней резервной копии. В следующем примере используется опция --incremental-base=history:last_backup, чтобы mysqlbackup получил LSN последней успешной (не-TTS) полной или частичной резервной копии из таблицы mysql.backup_history и выполнил инкрементное резервное копирование, базирующееся на этом. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --incremental --incremental-base=history:last_backup \ --backup-dir=/home/dbadmin/temp_dir \ --backup-image=incremental_image1.bi backup-to-image В следующем примере выполняется инкрементное резервное копирование, подобное показанному выше, но оптимистичное. mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/dbadmin/temp_dir \ --backup-image=incremental_image1.bi backup-to-image Дополнительно: Используйте следующую команду, чтобы создать возрастающую директивную резервную копию с использованием --incremental-base=dir: directory_path, резервная копия сохраняется в местоположении, определенном --incremental-backup-dir: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --incremental-base=dir:/incr-backup/wednesday \ --incremental-backup-dir=/incr-backup/thursday backup Можно также использовать опцию --start-lsn, чтобы определить, где инкрементное резервное копирование должно начаться. Необходимо сделать запись LSN предыдущей резервной копии, о которой сообщает mysqlbackup в конце резервной копии: mysqlbackup: Was able to parse the log up to lsn 2654255716 Число также зарегистрировано в файле meta/backup_variables.txt каталога, указанного --backup-dir во время изготовления резервной копии. Подставляйте это число mysqlbackup через опцию --start-lsn. Инкрементное резервное копирование тогда включает все изменения, которые были после указанного LSN. Чтобы создать образ инкрементного резервного копирования с --start-lsn, используйте следующую команду, определяя через --backup-dir резервный каталог, который, в этом случае, является каталогом для хранения метаданных для резервной копии и некоторых временных файлов: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --start-lsn=2654255716 --with-timestamp --backup-dir=/incr-tmp \ --backup-image=/incr-backup/incremental_image.bi \ backup-to-image В следующем примере --backup-image не предоставляет полный путь к файлу образа, который будет создан, образ инкрементного резервного копирования создается под каталогом, определенным --backup-dir: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --incremental \ --start-lsn=2654255716 --with-timestamp \ --backup-dir=/incr-images \ --backup-image=incremental_image1.bi backup-to-image Поддержание расписания резервного копирования: На регулярной основе, определенной по дате или объему деятельности базы данных, делайте больше возрастающего или дифференциального резервного копирования. Произвольно, периодически начинайте цикл снова, делая полную несжатую или сжатую резервную копию. Как правило, этот этап происходит, когда можно заархивировать и убрать самые старые данные резервного копирования. О том как восстановить вашу базу данных, используя возрастающие резервные копии, посмотрите раздел 5.1.3. 4.3.4. Создание сжатой резервной копии Чтобы сэкономить дисковое пространство, можно сжать резервные файлы данных InnoDB при помощи опции --compress. Сжатие позволяет вам держать больше данных резервного копирования или сэкономить время передачи, посылая данные резервного копирования на другой сервер. Кроме того, сжатие часто приводит к более быстрым резервным копиям из-за уменьшенного IO. Резервное сжатие работает только для таблиц InnoDB. После того, как файлы табличного пространства InnoDB сжаты во время резервной копии, они получают расширение .ibz. Чтобы избежать тратить впустую циклы CPU, не экономя дополнительное дисковое пространство, --compress не пытается сжать таблицы, которые были уже сжаты на сервере (см. Creating Compressed Tables), тем не менее, такие файлы табличного пространства также сохранены с расширением .ibz в резервной копии. Когда есть неиспользуемое место в файле табличного пространства InnoDB, весь файл копируется во время несжатой резервной копии. Выполните сжатую резервную копию, чтобы избежать издержек хранения для неиспользуемого места. Файлы журнала реле и двоичного журнала сжаты и сохранены с расширением .bz, будучи включенными в сжатую резервную копию. Вы не можете использовать опцию --compress для возрастающих резервных копий, созданных только с журналом отката (то есть с опцией --incremental-with-redo-log-only). Можно также выбрать алгоритм сжатия, чтобы использовать опцию --compress-method, а используя ZLIB или алгоритм сжатия LZMA, уровень сжатия опцией --compress-level. См. раздел 20.6. Это типовая команда для того, чтобы сделать сжатое однофайловое резервное копирование: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress \ --backup-image=backup.img backup-to-image Дополнительно: Это типовая команда для того, чтобы сделать сжатую директивную резервную копию: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress-method=zlib \ --compress-level=5 backup Это типовая команда для того, чтобы сделать сжатую и подготовленную директивную резервную копию: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress-method=zlib \ --compress-level=5 backup-and-apply-log См. ограничение, которое относится к сжатым резервным копиям в приложении B. 4.3.5. Создание частичной резервной копии По умолчанию все файлы в каталоге данных включены в резервную копию, чтобы резервная копия включала данные из всех механизмов хранения MySQL, любых сторонних механизмов хранения и даже любые файлы не базы данных в том каталоге. Эта секция объясняет варианты, которые можно использовать, чтобы резервировать выборочно или исключить данные. Есть различные способы создать различные виды частичной резервной копии с MySQL Enterprise Backup: Включая или исключая определенные таблицы по их именам. Это использует опции --include-tables или --exclude-tables. Каждая таблица сравнена с регулярным выражением, определенным --include-tables или --exclude-tables. Если регулярное выражение соответствует полностью полностью определенному имени таблицы (в форме db_name.table_name), таблица включена или исключена для резервной копии. Используемый синтаксис регулярного выражения является расширенной формой, определенной в стандарте POSIX 1003.2. Опции были осуществлены с библиотекой регулярных выражений RE2. Включая некоторые или все таблицы InnoDB, но не другие типы таблицы. Это использует опцию --only-innodb. Игнорирование файлов, которые присутствуют в каталоге данных MySQL, но на самом деле не части MySQL. Это использует опцию --only-known-file-types. Достижение кратного числа эффектов выбора при помощи комбинации вышеупомянутых вариантов. Выборочное резервирование таблиц InnoDB, используя transportable tablespaces (TTS). Это использует опции --use-tts и --include-tables или --exclude-tables (или обе). Для получения дополнительной информации синтаксиса обо всех включенных вариантах посмотрите раздел 20.8. Как правило, частичную резервную копию более трудно восстановить, чем полное резервное копирование, потому что данные резервного копирования не могли бы включать необходимые взаимосвязанные части, чтобы составить полный экземпляр MySQL. В частности у таблиц InnoDB есть внутренние ID и другие значения данных, которые могут вернуться только тому же самому экземпляру, но не иному серверу MySQL. Всегда полностью проверьте процедуру восстановления любых частичных резервных копий, чтобы понять соответствующие процедуры и ограничения. Следующее это некоторые образцы команды для частичных резервных копий. Включая все таблицы с именами, начинающимися с emp: mysqlbackup --host=localhost --user=mysqluser --protocol=TCP --port=3306 \ --backup-dir=$MEB_TEMP_BACKUP_DIR \ --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --include-tables="\.emp" backup-to-image Взятие резервной копии всех таблиц кроме таблиц из баз данных mysql и performance_schema: mysqlbackup --host=localhost --user=mysqluser --protocol=TCP --port=3306 \ --backup-dir=$MEB_TEMP_BACKUP_DIR \ --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --exclude-tables="^(mysql|performance_schema)\." backup-to-image Взятие резервной копии всех таблиц в базе данных sales, но исключая таблицу с именем hardware. mysqlbackup --host=localhost --user=mysqluser --protocol=TCP --port=3306 \ --backup-dir=$MEB_TEMP_BACKUP_DIR \ --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --include-tables="^sales\." --exclude-tables="^sales\.hardware$" \ backup-to-image Взятие резервной копии всех таблиц в базе данных sales reps, но исключая таблицу с именем euro-asia (специальные символы, например, пробелы или тире поддерживаются частичными резервными опциями): mysqlbackup --host=localhost --user=mysqluser --protocol=TCP --port=3306 \ --backup-dir=$MEB_TEMP_BACKUP_DIR \ --backup-image=$MEB_BACKUPS_DIR/my.mbi \ --include-tables="^sales reps\." \ --exclude-tables="^sales reps\.euro-asia" backup-to-image Резервирование всех таблиц InnoDB: mysqlbackup --host=localhost --user=mysqluser --protocol=TCP --port=3306 \ --backup-dir=$MEB_TEMP_BACKUP_DIR \ --backup-image=$MEB_BACKUPS_DIR/my.mbi --only-innodb \ backup-to-image Можно также сделать сжатые и другие виды резервных копий при помощи соответствующих вариантов команды. Создание частичной резервной копии с устаревшими опциями Информация в этом подразделе только для использования устаревшей опции --include. Для создания частичных резервных копий используйте опции --include-tables и --exclude-tables. Как правило, частичную резервную копию более трудно восстановить, чем полное резервное копирование, потому что данные резервного копирования не могут включать необходимые взаимосвязанные части, чтобы составить полный экземпляр MySQL. В частности у таблиц InnoDB есть внутренние ID и другие значения данных, которые могут вернуться только тому же самому экземпляру, но не иному серверу MySQL. Всегда полностью проверьте процедуру восстановления любых частичных резервных копий, чтобы понять соответствующие процедуры и ограничения. С опцией --include mysqlbackup может сделать резервную копию, которая включает некоторые таблицы InnoDB, но не все. Частичная резервная копия с --include всегда содержит системное табличное пространство InnoDB и все таблицы в нем. Для таблиц, хранимых InnoDB вне системного табличного пространства, частичная резервная копия включает только те таблицы, имена которых соответствуют регулярному выражению, определенному опцией --include. Эта операция требует таблиц, не учитываемых для сохранения в отдельных файлах table_name .ibd. Чтобы поместить таблица InnoDB вне системного табличного пространства, создайте его в то время, как опция innodb_file_per_table включена. Каждый файл .ibd хранит данные и индексы только одной таблицы. Таблицы InnoDB, составленные с выключенной опцией innodb_file_per_table, сохранены как обычно в системном табличном пространстве InnoDB и не могут быть исключены из резервной копии. Для каждой таблицы с файлом данных последовательность формы db_name.table_name сравнена с регулярным выражением, определенным опцией --include. Если регулярное выражение соответствует полной последовательности db_name.table_name, таблица включен в резервную копию. Используемый синтаксис регулярного выражения является расширенной формой, определенной в стандарте POSIX 1003.2. На Unix-системах укажите регулярное выражение соответственно, чтобы предотвратить интерпретацию метазнаков оболочкой. Эта опция была реализована с библиотекой регулярных выражений RE2. Резервный каталог содержит файл журнала резервного копирования и копии файлов данных InnoDB. ВАЖНО: Поскольку системное табличное пространство InnoDB содержит метаданные о таблицах InnoDB от всех баз данных, восстанавливая частичную резервную копию на сервере, который включает другие базы данных, можно заставить систему потерять след тех таблиц InnoDB в других базах данных. Всегда восстанавливайте частичные резервные копии на новом экземпляре сервера MySQL без любых других таблиц InnoDB, которые вы хотите сохранить. Пример 4.22. Создание несжатой частичной резервной копии таблиц InnoDB В этом примере мы формировали MySQL так, чтобы у некоторых таблиц InnoDB были свои собственные табличные пространства. Мы делаем частичную резервную копию включая только те таблицы InnoDB в базе данных test, имя которых начинается с ib. Содержание каталога базы данных для базы данных test показано ниже. Из этих 10 таблиц шесть (alex1, alex2, alex3, blobt3, ibstest0, ibstest09) сохранены в отдельных файлах данных (файлы .ibd). $ ls /sqldata/mts/test alex2.ibdibstest0.ibd alex1.ibdblobt3.ibdalex3.ibdibtest09.ibd Запустите mysqlbackup с опцией --include: # Back up some InnoDB tables. $ mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --include="^test\.ib.*" backup # Contents in the backup directory's subdirectory for the test database: $ ls /sqldata-backup/test ibstest0.ibd ibtest09.ibd Подкаталог резервного каталога для базы данных test содержит только резервные копии таблиц ibstest0 и ibtest09, потому что другие таблицы InnoDB не соответствуют образцу ^test\.ib.*. Пример 4.23. Создание сжатой частичной резервной копии Мы формировали MySQL так, чтобы у каждой таблицы InnoDB было свое собственное табличное пространство. Мы делаем частичную резервную копию включая только те таблицы InnoDB, имя которых начинается с alex или blob. Содержание каталога для базы данных test показано ниже. $ ls /sqldata/mts/test alex2.ibdibstest0.ibdalex1.ibdblobt3.ibdalex3.ibdibtest09.ibd Запустите mysqlbackup с опциями --compress и --include: $ mysqlbackup --defaults-file=/home/dbadmin/my.cnf --compress \ --include=".*\.(alex|blob).*" backup Резервный каталог для базы данных test показан ниже. Файлы .ibz это сжатые файлы данных таблиц. $ ls /sqldata-backup/test alex1.ibz alex2.ibz alex3.ibz blobt3.ibz 4.3.6. Создание оптимистической резервной копии Оптимистическая резервная копия это особенность улучшения работы для поддержки и восстановления огромных баз данных, в которых только небольшое количество таблиц часто изменяются. Во время горячего резервного копирования огромной базы данных огромные файлы журнала отката могли быть произведены на сервере, когда резервная копия происходит. Поскольку файлы журнала отката растут быстрее, чем они могут быть обработаны mysqlbackup, операция резервного копирования может на самом деле потерпеть неудачу, когда mysqlbackup не может догнать циклы журнала отката, и LSN переписаны сервером, прежде чем они будут прочитаны mysqlbackup. Кроме того, шаг apply-log для подготовки резервной копии для восстановления может занять очень долгое время, так как mysqlbackup имеет огромные файлы ibbackup_logfile (созданные из больших файлов журнала отката) для резервной копии. Проблемы усилены, когда ресурсы I/O, доступные для чтения и написания журналов отката, недостаточны во время процессов резервирования и восстановления. Оптимистическая резервная копия уменьшает проблемы, деля процесс резервного копирования на две внутренних фазы, которые очевидны для пользователей: Оптимистическая фаза: В этой первой фазе таблицы, которые вряд ли будут изменены во время процесса резервного копирования (называемые далее бездействующими таблицами), определенные пользователем с опцией optimistic-time или исключением с опцией optimistic-busy-tables), резервируются без блокировок. И потому что те таблицы, как ожидают, не будут изменены, прежде чем резервная копия будет закончена, журналы отката, отмены и системные табличные пространства не резервируются mysqlbackup в этой фазе вообще. Нормальная фаза: В этой второй фазе таблицы, которые не поддерживаются в первой фазе (называемые занятыми таблицыми), поддерживаются способом, подобным тому, как они обрабатываются в обычной резервной копии: файлы InnoDB копируются сначала, затем другие соответствующие файлы копируются или обрабатываются с различными блокировками, применяемыми к базе данных в разное время. Журналы отката, отмены и системное табличное пространство также поддерживается в этой фазе. Оптимистическая резервная копия происходит каждый раз, когда используется опция optimistic-time или optimistic-busy-tables. Как использовать варианты см. подробные описания для них в разделе 20.10. Если как ожидалось список бездействующих таблиц, определенных оптимистическими опциями, не изменится во время резервной копии (или даже если это изменится незначительно), большинство пользователей найдет, что полное время резервного копирования уменьшается значительно по сравнению с обычной резервной копией, поскольку размер данных о журнале отката, которые будут поддержаны, будет намного меньшим. Кроме того, восстановления время для резервной копии, будет также уменьшено, так как операция apply-log будет намного быстрее из-за меньшего журнала отката. Однако, если оказывается, что список бездействующих таблиц изменен значительно во время процесса резервного копирования, выгоды выполнения оптимистического метода станут ограниченными и в худшем случае оптимистическая резервная копия могла бы на самом деле занять больше времени, а для однофайлового резервного копирования, размер резервной копии будет больше, соответствуя обычной резервной копии. Поэтому пользователи должны быть осторожными в идентификации, какие таблицы бездействующие, а какие заняты, пытаясь выполнить оптимистическую резервную копию. Оптимистическая резервная копия не может быть выполнена для инкрементного резервного копирования или резервной копии, используя transportable tablespaces (TTS). Не выполняйте операцию DDL на сервере параллельно с оптимистической резервной копией или резервная копия потерпит неудачу. Следующие примеры иллюстрируют, как сделать оптимистическую резервную копию. Пример 4.24. Оптимистическая резервная копия, используя опцию optimistic-time=YYMMDDHHMMSS . В этом примере таблицы, которые были изменены с полудня 16 мая 2011, рассматривают как занятые таблицы и поддерживают в нормальной фазе оптимистической резервной копии, все другие таблицы поддерживаются в оптимистической фазе: mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --optimistic-time=110516120000 \ --backup-image=<image-name> \ --backup-dir=<temp-dir> \ backup-to-image Пример 4.25. Оптимистическая резервная копии, используя опцию optimistic-time=now В этом примере все таблицы рассматривают как бездействующие таблицы и поддерживают в оптимистической фазе оптимистической резервной копии: mysqlbackup --defaults-file=/home/dbadmin/my.cnf --optimistic-time=now \ --backup-image=<image-name> \ --backup-dir=<temp-dir> \ backup-to-image Пример 4.26. Оптимистическая резервная копии, используя опцию optimistic-busy-tables В этом примере таблицы в mydatabase с префиксом имени mytables- рассматриваются как занятые таблицы и поддерживаются в нормальной фазе оптимистической резервной копии, все другие таблицы поддерживаются в оптимистической фазе: mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --optimistic-busy-tables="^mydatabase\.mytables-.*" \ --backup-image=<image-name> \ --backup-dir=<temp-dir> backup Когда вы используете обе опции optimistic-time и optimistic-busy-tables и они вступают в конфликт при определении, какие таблицы должны быть занятыми, optimistic-busy-tables имеет приоритет перед optimistic-time, например: Пример 4.27. Оптимистические и частичные резервные копии, используя опции optimistic-busy-tables и optimistic-time совместно В этом примере таблицы в mydatabase с префиксом mytables- рассматриваются как занятые таблицы и поддерживаются в нормальной фазе, даже если они не были изменены с 16 мая 2010, времени, определенного optimistic-time: mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --optimistic-busy-tables="^mydatabase\.mytables-.*" \ --optimistic-time=100516--backup-image=<image-name> \ --backup-dir=<temp-dir> backup Используя оптимистические резервные копии и оптимистические возрастающие резервные копии вместе Используя совместно оптимистическое резервное копирование и оптимистическое инкрементное резервное копирование в вашем расписании резервного копирования, можно ускорить резервные копии для огромных баз данных, особенно когда только относительно небольшое количество таблиц было изменено с определенного времени и не много таблиц изменяется на частой основе. Ниже дана типовая последовательность команд, иллюстрирующих еженедельное расписание резервного копирования, которое использует эти две особенности, это также включает шаги для восстановления данных к определенному дню. # A full optimistic backup performed on 2017/02/04, Sat, at 1130 PM. # The --optimistic-time option is used to specify an optimistic time of 2016/08/16, 0800 PM mysqlbackup --defaults-file=/home/admin/my.cnf --optimistic-time=160816200000 \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_full_201702042330.bi \ --with-timestamp backup-to-image # A sequence of optimistic incremental backups are then performed on each the following six days at 1130 PM # On Sunday, 2017/02/05 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \ --with-timestamp backup-to-image # On Monday, 2017/02/06 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \ --with-timestamp backup-to-image # On Tuesday, 2017/02/07 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \ --with-timestamp backup-to-image # On Wednesday, 2017/02/08 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702082330.bi \ --with-timestamp backup-to-image # On Thursday, 2017/02/09 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702092330.bi \ --with-timestamp backup-to-image # On Friday, 2017/02/10 mysqlbackup --defaults-file=/home/admin/my.cnf \ --incremental=optimistic --incremental-base=history:last_backup \ --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_incremental__201702102330.bi \ --with-timestamp backup-to-image # Another full optimistic backup is performed on Saturday, 2017/02/11 mysqlbackup --defaults-file=/home/dbadmin/my.cnf \ --optimistic-time=110516200000 --backup-dir=/home/admin/temp_dir \ --backup-image=/home/admin/backups/mydb_full_201702112330.bi \ --with-timestamp backup-to-image # Restore the database to its state at Tuesday, 2017/02/07, at 11:30 PM # First, restore the full optimistic backup taken on the Saturday before, which was 2017/02/04: mysqlbackup --defaults-file=/etc/my.cnf \ --backup-image=/home/admin/backups/mydb_full_201702042330.bi \ --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \ --with-timestamp copy-back-and-apply-log # Next, restore the optimistic incremental taken on the Sunday, Monday, and Tuesday that follow: mysqlbackup --defaults-file=/etc/my.cnf \ --backup-image=/home/admin/backups/mydb_incremental__201702052330.bi \ --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \ --incremental --with-timestamp copy-back-and-apply-log mysqlbackup --defaults-file=/etc/my.cnf \ --backup-image=/home/admin/backups/mydb_incremental__201702062330.bi \ --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \ --incremental --with-timestamp copy-back-and-apply-log mysqlbackup --defaults-file=/etc/my.cnf \ --backup-image=/home/admin/backups/mydb_incremental__201702072330.bi \ --backup-dir=/home/admin/temp_dir --datadir=/var/lib/mysql \ --incremental --with-timestamp copy-back-and-apply-log 4.3.7. Резервирование из данных в памяти Опция --exec-when-locked позволяет вам определить команду (вместе с желаемыми аргументами команды), чтобы работать около конца резервной копии в то время, как не-InnoDB таблицы базы данных все еще заблокированы. Эта команда может скопировать или создать дополнительные файлы в резервном каталоге. Например, можно использовать этот выбор, чтобы зарезервировать таблицы MEMORY командой mysqldump, храня вывод в резервном каталоге. Чтобы задержать любое переназначение или подстановку переменных до окончания выполнения команды, приложите значение опции в одинарных кавычках. 4.3.8. Создание запланированного резервного копирования Поддержание графика регулярного резервного копирования является важной мерой для предотвращения потери данных. Эта секция обсуждает некоторые простые средства для подготовки графика для MySQL Enterprise Backup. Linux и Unix-платформы: можно настроить работу cron на системе для запланированного резервного копирования. Есть два типа задач cron. Чтобы настроить пользовательскую работу cron, которая принадлежит и управляется конкретным пользователем, делают следующее: Войдите в систему как пользователь, который управляет MySQL Enterprise Backup и используйте следующую команду, чтобы вызвать редактор для создания (или изменения) crontab: shell> crontab -e В редакторе добавьте запись, подобную этой, к crontab, затем сохраните свои изменения (удостоверьтесь, что содержание обеих строк ниже появляется в одной строке в crontab): @daily /path-to-mysqlbackup/mysqlbackup -uroot --backup-dir=/path-to-backup-folder/cronbackups --with-timestamp --backup-image=my.mib backup-to-image&>/dev/null Эта запись crontab вызывает mysqlbackup, чтобы создать резервную копию в каталоге cronbackups ежедневно в 00:00:00. Выводы из stderr и stdout перенаправляются в /dev/null/, таким образом, они не вызовут другие действия со стороны сервера Cron (например, уведомления по электронной почте пользователю). Чтобы настроить системную работу cron, которая принадлежит и управляется root, создайте файл в каталоге /etc/cron.d и поместите него подобную запись crontab, как показанная выше, добавляя пользователя (root в следующем примере) перед командой mysqlbackup: @daily root /path-to-mysqlbackup/mysqlbackup -uroot --backup-=/path-to-backup-folder/cronbackups \ --with-timestamp --backup-image=my.mib backup-to-image&>/dev/null Проверьте документацию своей платформы для получения дальнейшей информации относительно различных способов настроить задачи cron для различных типов графиков. Windows: используйте Task Scheduler. Проверьте документацию на свою платформу Windows для инструкций. 4.4. Создание резервных копий с распределенной файловой системой (DFS) или Storage Access Network (SAN) Когда системные администраторы пытаются настроить MySQL и MySQL Enterprise Backup в окружающей среде, которая использует распределенную файловую систему (DFS) или storage access network (SAN), сервер MySQL, каталог данных сервера, MySQL Enterprise Backup и резервный каталог могут существовать на различных физических серверах. Когда это происходит, на операции mysqlbackup можно было бы повлиять. Операция, которая, скорее всего, испытает негативное влияние, является горячим резервным копированием, успех которого зависит от: Каждая страница файла данных последовательно копируется, то есть, все байты на странице соответствуют тому же самому LSN. Никакая скопированная страница не более старая, чем время, которое отмечает начало временной продолжительности, которую резервная копия использует. Журнал отката последовательно копируется, означая, что непрерывный сегмент журнала отката копируется, а именно все изменения с начала временного периода, которого резервная копия должна касаться, до конца операции резервного копирования. Каждый блок скопированного журнала отката должен быть последовательным. Условие 1 легко достижимо с большей частью DFS или SAN. Условие 2 может остаться невыполненным, даже когда условие 1 было удовлетворено: например, mysqlbackup мог скопировать все страницы табличного пространства правильно за исключением одной страницы, для которой mysqlbackup включал старую версию в копию. Если LSN той старой версии страницы будет меньшим, чем LSN, увиденный в первый раз mysqlbackup в начале процесса резервного копирования, получающаяся резервная копия будет дефектной. Этот пример показывает, что mysqlbackup может быть проблемой при выполнении горячего резервного копирования, если это видит записи файловой системы, выполняемые в правильном порядке, то есть, порядке, в котором сервер выполнил их. Относительно условия 3, в отличие от страниц файла данных, блоки журнала отката написаны последовательно, что означает, что условие 3 легче выполнить, чем условия 1 и 2, особенно используя функцию архивации журнала отката, доступную в MySQL Server 8.0.17. Однако, если mysqlbackup достигает самого высокого LSN на скопированных страницах файла данных прежде, чем столкнуться с концом журнала отката, резервная копия терпит неудачу. Неудача происходит также, если mysqlbackup читает испорченный блок журнала когда-либо во время копирования журнала отката. Обе этих неудачи могут произойти, если mysqlbackup не видит ту же самую историю состояний файловой системы, как сервер MySQL. Поэтому, чтобы использовать mysqlbackup с DFS или SAN, важно удостовериться, что mysqlbackup видит все записи файловой системы в том же самом порядке, как сервер MySQL их делает. Условие, скорее всего, будет удовлетворено, когда mysqlbackup и сервер MySQL будут работать на том же самом сервере, но это условие вряд ли будет всегда выполняться, когда это не так.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.