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

Глава 5. Восстановление базы данных Окончательная цель данных резервного копирования состоит в том, чтобы помочь восстановиться после проблемы базы данных или создать клон оригинальной базы данных в другом месте (как правило, управлять запросами или создать новую точную копию). Эта секция описывает процедуры, чтобы это сделать. После серьезной проблемы базы данных вы, возможно, должны были бы выполнить восстановление при серьезной нехватке времени. Очень важно подтвердить заранее: Сколько времени восстановление займет, включая любые шаги по передаче, распаковке и иной обработке данных. То, что вы практиковали и зарегистрировали все шаги процесса восстановления, чтобы можно было сделать это правильно с первого раза. Если аппаратная проблема требует восстановления данных к иному серверу, проверьте все привилегии, емкость памяти и так далее на том сервере загодя. То, что вы периодически проверяли точность и полноту данных резервного копирования, чтобы система была в порядке после восстановления. 5.1. Выполнение операции восстановления Команды mysqlbackup, чтобы выполнить восстановление, это copy-back-and-apply-log и copy-back (см. раздел 5.1.7). Обычно процесс восстановления требует, чтобы сервер базы данных был уже закрыт (или по крайней мере не воздействовал на каталог, в который вы вернули данные), за исключением частичного восстановления. Процесс копирует файлы данных, журналы и другие поддержанные файлы из резервного каталога назад к их исходным местоположениям и выполняет любую необходимую последующую обработку. Пример 5.1. Восстановление базы данных mysqlbackup --defaults-file=<my.cnf> -uroot \ --backup-image=<image_name> \ --backup-dir=<backupTmpDir> --datadir=<restoreDir> \ copy-back-and-apply-log Команда copy-back-and-apply-log достигает двух вещей: Извлекает резервную копию из файла образа и копирует к каталогу данных на сервере, который будет восстановлен. Выполняет apply log к восстановленным данным, чтобы их актуализировать. См. раздел 4.2.4 для объяснения важных вариантов, используемых в восстановлении, в частности --defaults-file, --datadir, --backup-image и --backup-dir . Восстановленные данные включают таблицу backup_history, где MySQL Enterprise Backup делает запись деталей каждой резервной копии. Это позволяет вам выполнять будущие возрастающие резервные копии, используя --incremental-base=history:last_backup. Выполняя восстановление удостоверьтесь, что целевые каталоги для восстанавливаемых данных все чистые, не содержат старых или нежелательных файлов данных (это могло бы потребовать ручного удаления файлов в местах, определенных --datadir, --innodb_data_home_dir, --innodb_log_group_home_dir и --innodb_undo_directory). Та же самая очистка не требуется для частичного восстановления, для которого применяются другие требования, описанные в разделе 5.1.4. После полного восстановления в зависимости от того, как вы собираетесь запустить восстановленный сервер, вы, возможно, должны были бы приспособить значение восстановленного каталога данных. Например, если сервер будет запущен от имени mysql, используйте следующую команду, чтобы изменить признак владельца каталога данных и файлов в нем на пользователя mysql и атрибут группы к mysql. $ chown -R mysql:mysql /path/to/datadir Следующие подразделы описывают много различных сценариев для восстановления резервной копии. 5.1.1. Восстановление сжатой резервной копии MySQL Enterprise Backup 8.0.21 и позже: опция --uncompress больше не необходима, восстанавливая сжатую резервную копию. Восстановите сжатый образ резервной копии <image_name>, используя опцию --backup-dir, чтобы определить временный каталог, в который будут сохранены файлы статуса и метаданные резервных копий: Пример 5.2. Восстановление сжатой резервной копии mysqlbackup --defaults-file=<my.cnf> -uroot \ --backup-image=<image_name> \ --backup-dir=<backupTmpDir> --datadir=<restoreDir> \ --uncompress copy-back-and-apply-log Дополнительно: сделайте то же самое для сжатого резервного каталога <backupDir> в <restoreDir> на сервере, применив copy-back-and-apply-log: Пример 5.3. Восстановление сжатой директивной резервной копии mysqlbackup --defaults-file=<my.cnf> -uroot \ --backup-dir=<backupDir> --datadir=<restoreDir> \ --uncompress copy-back-and-apply-log Чтобы восстановить сжатую и подготовленную директивную резервную копию, созданную командой backup-and-apply-log (поддерживается только для MySQL Enterprise Backup 4.0.1 и позже), используйте команду the copy-back и опцию --uncompress : Пример 5.4. Восстановление сжатой и подготовленной директивной резервной копии mysqlbackup --defaults-file=<my.cnf> -uroot \ --backup-dir=<backupDir> --datadir=<restoreDir> \ --uncompress copy-back См. разделы 4.3.4 и 20.6. 5.1.2. Восстановление зашифрованного образа резервной копии Восстановите зашифрованный образ резервной копии <image_name> в <restoreDir> на сервере с помощью copy-back-and-apply-log с использованием ключа шифрования, содержавшегося в файле <keyFile> : Пример 5.5. Восстановление зашифрованного образа резервной копии mysqlbackup --defaults-file=<my.cnf> --backup-image=<image_name> \ --backup-dir=<backupTmpDir> --datadir=<restoreDir> \ --decrypt --key-file=<keyFile> copy-back-and-apply-log См. раздел 20.13. 5.1.3. Восстановление инкрементного резервного копирования MySQL Enterprise Backup 8.0.21 и позже: опция --incremental больше не необходима, восстанавливая инкрементное резервное копирование. Есть различные способы использовать возрастающие резервные копии, чтобы восстановить базу данных согласно различным сценариям. Предпочтительный метод состоит в том, чтобы сначала восстановить полное резервное копирование и сделать его актуальным ко времени, в которое полное резервное копирование было выполнено, используя copy-back-and-apply-log (см. пример 5.1), затем использовать copy-back-and-apply-log снова, чтобы восстановить образ инкрементного резервного копирования сверху полного резервного копирования, которое было просто восстановлено: Пример 5.6. Восстановление образа инкрементного резервного копирования mysqlbackup --defaults-file=<my.cnf> -uroot \ --backup-image=<inc_image_name> \ --backup-dir=<incBackupTmpDir> \ --datadir=<restoreDir> --incremental \ copy-back-and-apply-log В этом примере образ инкрементного резервного копирования <inc_image_name> восстановлен в <restoreDir> на сервере (где полное резервное копирование, на основе которого был сделан образ инкрементного резервного копирования, было уже восстановлено). Опция --backup-dir используется, чтобы определить временный каталог, в который сохранены файлы статуса и метаданные резервных копий. Повторите шаг с другими образами инкрементного резервного копирования, которые вы имеете, пока данные не вернутся к желаемому моменту времени. Дополнительно: восстановление каталога инкрементного резервного копирования Возрастающие директивные резервные копии могут быть восстановлены в серии команд copy-back-and-apply-log, как иллюстрировано выше для однофайлового резервного копирования. Альтернативно в любое время после того, как инкрементное резервное копирование взято и прежде, чем данные будут восстановлены, можно сделать полное резервное копирование актуальным с инкрементным резервным копированием. Во-первых, примените к полному резервному копированию любые изменения, которые произошли в то время как, резервная копия делалась: $ mysqlbackup --backup-dir=/full-backup/2010-12-08_17-14-11 apply-log ..many lines of output... 101208 17:15:10 mysqlbackup: Full backup prepared for recovery successfully! 101208 17:15:10 mysqlbackup: mysqlbackup completed OK! Затем мы применяем изменения от инкрементного резервного копирования, используя apply-incremental-backup: $ mysqlbackup --incremental-backup-dir=/incr-backup/2010-12-08_17-14-48 \ --backup-dir=/full-backup/2010-12-08_17-14-11 \ apply-incremental-backup ...many lines of output... 101208 17:15:12 mysqlbackup: mysqlbackup completed OK! Теперь файлы данных в каталоге полного резервного копирования полностью актуальны по состоянию на время последнего инкрементного резервного копирования. Можно продолжать обновлять его с большим количеством возрастающих резервных копий, таким образом, это готово быть восстановленным в любое время. Восстановление журналов Когда инкрементное резервное копирование восстанавливается, используя любую из команд copy-back-and-apply-log или apply-incremental-backup, двоичная регистрация (а также журнал реле в случае сервера точной копии), если включена в инкрементное резервное копирование, также вернется целевому серверу по умолчанию. Это поведение по умолчанию отвергнуто, когда (1) опция --skip-binlog (или --skip-relaylog для журнала реле) используется с командой восстановления или (2) если у полного резервного копирования, на основе которого было инкрементное резервное копирование или любого предшествующего инкрементного резервного копирования, которое было между полным резервным копированием и этим инкрементным резервным копированием, есть двоичная регистрация (или журнал реле), в обоих случаях MySQL Enterprise Backup 8.0.19 и позже переименует любую двоичную регистрацию (но не журнал реле) и их индексные файлы, которые были уже восстановлены на сервере, добавив расширение .old к их именам файлов). Местоположение двоичной регистрации (или журнала реле) после инкрементного резервного копирования восстановлено по умолчанию как местоположение регистрации на поддержанном сервере, когда инкрементное резервное копирование было взято или как определено опцией --log-bin (или --relay-log) во время восстановления. См. разделы 4.3.3 и 20.7. 5.1.4. Table-Level Recovery (TLR) MySQL Enterprise Backup 8.0.20 и позже: Table-Level Recovery (TLR) позволяет отобранным таблицам (или схемам) быть восстановленными из резервной копии (будь это полное резервное копирование, частичная резервная копия или резервная копия, созданная, используя transportable tablespaces (TTS)) с опциями --include-tables и --exclude-tables. Особенность также известна как частичное восстановление. Вот некоторые общие требования для выполнения TLR: Сервер назначения должен работать. Обязательные параметры для соединения с сервером (номер порта, название сокета и т.д.) обеспечиваются как параметры командной строки для mysqlbackup или определяются в разделе [client] файла по умолчанию. Сервер назначения должен использовать тот же самый размер страницы, который использовался на сервере, на котором была сделана резервная копия. innodb_file_per_table должна быть позволена на сервере назначения. Для резервных копий не-TTS: восстанавливаемые таблицы должны уже существовать на сервере назначения в том же самом определении. Для резервных копий TTS: восстанавливаемые таблицы не должны существовать на сервере назначения. В то время как не надо определять опцию --datadir частично восстанавливая резервную копию, если опция определяется, значение должно соответствовать значению целевого сервера или операция восстановления потерпит неудачу (восстанавливая резервную копию TTS с выпуском 8.0.16 или ранее опция --datadir нужна). Вот некоторые ограничения для TLR: Отдельное разделение не может быть выборочно восстановлено. Таблицы, отобранные --include-tables и --exclude-tables , всегда восстанавливаются полностью. TLR не может быть выполнен с возрастающими резервными копиями. Журналы реле, регистрации и отмены не восстановлены. Для не-TTS резервных копий эти дополнительные ограничения применяются: После TLR таблицы могут содержать изменения от нейтральных транзакций. Значения auto-increment восстановленных таблиц для частичного восстанавливают не могут совпасть с тем, что было в конце процесса резервного копирования. Зашифрованные таблицы InnoDB не могут быть включены в частичное восстановление. Следующая команда восстанавливает таблицу cats в схеме pets: Пример 5.7. Восстановление отобранной таблицы из образа резервного копирования mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^pets\.cats" \ --backup-dir=/dba/backuptmp \ --backup-image=/dba/my.mbi copy-back-and-apply-log Следующая команда восстанавливает все таблицы в базе данных sales из резервной копии, но исключает таблицу hardware: Пример 5.8. Восстановление отобранной таблицы в схеме из образа резервного копирования mysqlbackup --socket=/tmp/restoreserver.sock --include-tables="^sales\." \ --exclude-tables="^sales\.hardware$" \ --backup-dir=/dba/backuptmp --backup-image=/dba/my.mbi \ copy-back-and-apply-log См. раздел 5.1.5 для получения дополнительной информации о частичном восстановлении с использованием резервных копий TTS. MySQL Enterprise Backup 8.0.19 и ранее: частичное восстановленин поддерживается только для резервных копий TTS. 5.1.5. Восстановление резервных копий, созданных с опцией --use-tts Требования для восстановления резервных копий, созданных с transportable tablespaces (TTS) (то есть, с опцией --use-tts) подобны перечисленным в разделе 5.1.4, с некоторыми различиями, отмеченными в секции. Следующее это некоторая дополнительная информация о частичном восстановлении с использованием резервных копий TTS. Чтобы сделать копию и восстановить резервные копии, созданные с использованием TTS, дополнительные привилегии требуются для пользователя, через которого mysqlbackup соединяется с сервером, посмотрите раздел 4.1.2. Когда восстановление резервного копирования выполняется с опцией --use-tts= with-minimum-locking, то каталог, определенный --backup-dir, помимо файлов статуса и метаданных также используется для извлечения временно всех таблиц в резервной копии и для выполнения apply-log, чтобы сделать данные актуальными прежде, чем вернуть их в каталог данных сервера. Можно переименовать таблицу, восстанавливая ее из резервной копии TTS при помощи опции --rename (не поддерживается для резервных копий не-TTS): Пример 5.9. Восстановление и переименование таблицы из резервной копии TTS # Using fully qualified table names: mysqlbackup --socket=/tmp/restoreserver.sock \ --backup-dir=/BackupDirTemp \ --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \ --include-tables="^sales\.cars" \ --rename="sales.cars to sales.autos" copy-back-and-apply-log # It works the same if database names are omitted in the argument for --rename: mysqlbackup --socket=/tmp/restoreserver.sock \ --backup-dir=/BackupDirTemp \ --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \ --include-tables="^sales\.cars" \ --rename="cars to autos" copy-back-and-apply-log # A table can be restored into another database; the target database is created if it is not existing on the server: mysqlbackup --socket=/tmp/restoreserver.sock \ --backup-dir=/BackupDirTemp \ --backup-image=/home/user/dbadmin/backups/tts-backup.mbi \ --include-tables="^sales\.cars" \ --rename="sales.cars to new_sales.autos" copy-back-and-apply-log 5.1.6. Восстановление внешних табличных пространств InnoDB к иным местоположениям Когда резервная копия содержит внешние табличные пространства InnoDB, которые находились за пределами каталога данных поддержанного сервера, можно вернуть их к местоположениям, отличающимся от оригинальных, обновив их пути в файле tablespace_tracker в резервной копии, см. описание файла в таблице 1.1. 5.1.7. Дополнительно: подготовка и восстановление директивной резервной копии Директивная резервная копия, точно так же как однофайловое резервное копирование, может быть подготовлена и восстановлена с использованием команды copy-back-and-apply-log как объяснено в начале раздела 5.1. Пример 5.10. Восстановление резервного каталога, используя copy-back-and-apply-log mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \ --backup-dir=/export/backups/full copy-back-and-apply-log Однако, две альтернативы существуют для директивных резервных копий: Выполните apply log на сырой резервной копии прямо после того, как резервная копия создана, или в любое время прежде восстановления, используя apply-log. Можно управлять этим шагом на том же самом сервере базы данных, где вы сделали резервную копию, или передать сырые резервные файлы сначала иной системе, чтобы ограничить издержки CPU и хранения на сервере базы данных. Вот некоторые примеры выполнения этого на различных видах директивных резервных копий: Пример 5.11. Применение регистрации к резервной копии Этот пример управляет mysqlbackup, чтобы продвинуть файлы данных так, чтобы данные были готовы быть восстановленными: mysqlbackup --backup-dir=/export/backups/2011-06-21__8-36-58 apply-log Эта команда создает файлы журнала InnoDB (ib_logfile*) в рамках резервного каталога и применяет записи журнала к файлам данных InnoDB (ibdata* и *.ibd). Пример 5.12. Применение регистрации к сжатой резервной копии Если резервная копия сжата, как в разделе 4.3.4, определите опцию --uncompress, применяя регистрацию к резервной копии (опция --uncompress требуется только для MySQL Enterprise Backup 8.0.20 и позже): mysqlbackup --backup-dir=/export/backups/compressed --uncompress apply-log Так как apply log не изменяет ни одного из оригинальных файлов в резервной копии, ничто не потеряно, если операция терпит неудачу по некоторым причинам (например, недостаточное дисковое пространство). После решения проблемы можно безопасно повторить apply-log определяя опцию --force, который позволяет переписать файлы данных и файлы журнала, созданные неудавшимся вызовом apply log. Для резервных копий, которые являются невозрастающими, можно объединить первоначальную резервную копию и выполнить шаги apply-log, применяя команду backup-and-apply-log. После того, как резервная копия была подготовлена, можно теперь восстановить ее, используя copy-back: mysqlbackup --defaults-file=/usr/local/mysql/my.cnf \ --backup-dir=/export/backups/full copy-back 5.2. Восстановление резервной копии с облачного хранилища на сервер MySQL Восстановить образ резервной копии от облачного хранилища в datadir на сервере можно, применив варианты облачного хранилища, а также опцию --backup-dir, чтобы определить временный каталог, в который будут сохранены файлы статуса и метаданные резервных копий: Пример 5.13. Восстановление однофайлового резервного копирования из хранилища объектов Oracle Cloud Infrastructure (OCI) на сервер MySQL mysqlbackup --defaults-file=<my.cnf> \ --backup-dir=/home/user/dbadmin/backuptmp \ --datadir=<server_datadir> \ --with-timestamp --backup-image=---cloud-service=OCI \ --cloud-par-url=<backup_PAR_URL> \ copy-back-and-apply-log Пример 5.14. Восстановление инкрементного резервного копирования из Oracle Cloud Infrastructure (OCI) на сервер MySQL mysqlbackup --defaults-file=<my.cnf> \ --backup-dir=/home/user/dbadmin/backuptmp \ --datadir=<server_datadir> \ --with-timestamp --backup-image=---cloud-service=OCI \ --cloud-par-url=<incremental-backup_PAR_URL> \ --incremental copy-back-and-apply-log Пример 5.15. Восстановление однофайлового резервного копирования из OpenStack Object Storage на MySQL Server mysqlbackup --defaults-file=<my.cnf> \ --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-object=image_800.mbi \ --backup-dir=/home/user/dba/swiftbackuptmpdir \ --datadir=/home/user/dba/datadir --backup-image=- \ copy-back-and-apply-log Пример 5.16. Восстановление однофайлового резервного копирования из Amazon S3 на MySQL Server mysqlbackup --defaults-file=<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/user/dba/s3backuptmpdir --with-timestamp \ --datadir=/home/user/dba/datadir --backup-image=- \ copy-back-and-apply-log Пример 5.17. Восстановление однофайлового резервного копирования из GCP Storage Service на MySQL Server mysqlbackup --defaults-file=<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/user/dba/backuptmpdir --with-timestamp \ --datadir=/home/user/dba/datadir \ --backup-image=- copy-back-and-apply-log 5.3. Восстановление момента времени Можно вернуть базу данных к ее состоянию в произвольное время, используя файлы двоичного журнала, включенные в резервные копии. Процесс предполагает, что следующие условия выполнены: У поддержанного MySQL Server был включен двоичный журнал (верно по умолчанию для MySQL 8.0). Чтобы проверить, было ли это условие удовлетворено, выполните этот запрос на сервере: mysql> SHOW VARIABLES LIKE 'log_bin'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | log_bin | ON | +---------------+-------+ 1 row in set (0.00 sec) Если log_bin = OFF, двоичная регистрация не была позволена. Посмотрите The Binary Log как позволить двоичную регистрацию для сервера. Ряд резервных копий, состоящий, как правило, из полного резервного копирования, сопровождаемого рядом возрастающих резервных копий, был создан для сервера. Последняя резервная копия в ряду касается предназначенного момента времени для восстановления. Пример ниже иллюстрирует такой типичный случай. Последняя резервная копия в резервном ряду, который вы взяли, включает соответствующие двоичные файлы журнала. Чтобы гарантировать, что это требование удовлетворено, не используйте ни одну из следующих опций MySQL Enterprise Backup, создавая резервную копию: --skip-binlog, --use-tts, --no-locking или --start-lsn. Это шаги для восстановления момента времени: Восстановите ряд резервных копий к серверу, за исключением последнего инкрементного резервного копирования в ряду (которое покрывает предназначенный момент времени для восстановления). По окончании отметьте двоичное положение регистрации, к которому вы вернули сервер. Информация доступна в файле backup_variables.txt в восстановленном каталоге данных сервера: ищите значение binlog_position, например: binlog_position=binlog.000012:426 Это означает, что после восстановления резервного ряда сервер будет в положении 426 регистрации, найденном в двоичном файле журнала binlog.000012. Вам будет нужна эта информация позже. В то время как последнее восстановленное двоичное положение регистрации также показано InnoDB после восстановления, оно не является надежным средством для получения заканчивающего положения регистрации вашего восстановления, поскольку могли быть события DDL и изменения не-InnoDB, которые произошли после времени, отраженного показанным положением. Извлеките двоичную регистрацию из последнего инкрементного резервного копирования в резервном ряду (то есть, резервной копии, которая касается предназначенного момента времени для восстановления). Вы делаете это, распаковывая образ инкрементного резервного копирования в резервный каталог, используя image-to-backup-dir: mysqlbackup --backup-dir=incr-backup-dir2 \ --backup-image=incremental_image2.bi image-to-backup-dir Затем войдите в получающийся резервный каталог (incr-backup-dir2 в этом примере) и в соответствии с каталогом данных внутри найдите файл двоичного журнала (binlog.000012 в этом примере): incr-backup-dir2$ ls datadir binlog.000012 ibbackup_logfilemysql petsundo_002 ... Накатите базу данных к ее состоянию в предназначенном моменте времени для восстановления, определенного как tR в этом примере, используя файл журнала, извлеченный на последнем шаге. Затем используя mysqlbinlog накатите к серверу действия SQL, зарегистрированные в файле журнала с позиции, на которой восстановлен сервер на шаге 1 (в нашем примере 426) полностью ко времени tR. Определите ряд событий двоичной регистрации, чтобы переиграть с использованием опций --start-position и --stop-position (которые указывают на соответствующее положение двоичной регистрации для tR) и перенаправьте вывод клиенту mysql: mysqlbinlog --start-position="binary-log-position-at-the-end-of-backup-restores" \ --stop-position="binary-log-position-corresponding-to-tR" \ binary-log-filename \ | mysql -uadmin -p Использовать --start-datetime или --stop-datetime, чтобы определить диапазон двоичного сегмента регистрации, чтобы переиграть не рекомендуется: есть высокий риск недостающих двоичных событий регистрации, используя опции. Надо использовать опции --start-position и --stop-position. Если у вас есть больше, чем один двоичной файл журнала в вашем инкрементном резервном копировании, и они все необходимы для обеспечения сервера до его состояния tR, необходимо перекачать всех их к серверу в единственной связи, например: mysqlbinlog --start-position="426" \ --stop-position="binary-log-position-corresponding-to-tR" \ binlog.000012 binlog.000013 binlog.000014 | mysql -u admin -p Можно также свалить весь вывод mysqlbinlog к единственному файлу сначала, а затем перенаправить файл mysql. Для большего количества объяснений при использовании двоичной регистрации для восстановления момента времени посмотрите Point-in-Time (Incremental) Recovery. Проверьте, что сервер вернулся к желаемому моменту времени. 5.4. Восстановление резервной копии с модернизацией базы данных Можно столкнуться с техническими проблемами во время модернизации сервера и это вне функций MySQL Enterprise Backup как резервного инструмента, чтобы гарантировать успешную модернизацию сервера. Пользователям, заинтересованным темой, рекомендуется проконсультироваться с серверным руководством MySQL, особенно с разделами Upgrading MySQL и Downgrading MySQL и обратить особое внимание на требования и ограничения, обсужденные там. Можно облегчить модернизацию сервера при помощи MySQL Enterprise Backup, чтобы сделать резервную копию данных из исходного сервера и восстановить их на целевом сервере, а затем после некоторых приготовлений запустить иную версию MySQL Server на восстановленных данных. Вот много вещей, на которые пользователи должны обратить внимание, восстанавливая резервную копию с модернизацией базы данных: Восстановление базы данных со снижением сервера должно быть выполнено только, когда серверы MySQL на источнике и цели находятся в том же самом ряду выпусков. Понижение до более низкого ряда (например, от 8.0.11 до 5.7.21) могло бы вызвать катастрофу сервера или повреждение данных. В настоящее время снижение сервера, даже в том же самом ряду выпусков, не поддерживается согласно политике, описанной в Downgrading MySQL. Восстановление базы данных с модернизацией сервера требует следующих шагов, пропуск любого из которых может обвалить восстановленный сервер: Поддержите данные по исходному серверу. Используя ту же самую версию MySQL Enterprise Backup, с которой была взята резервная копия, верните данные целевому серверу, выполняя copy-back-and-apply-log. Установите на целевом сервере ту же самую версию MySQL Server, которая работала на исходном сервере, когда ваша резервная копия была создана. Запустите MySQL Server, который вы просто установили. Ваши восстановленные данные проходят сокращенный процесс восстановления при подготовке к модернизации сервера. Выполните медленное закрытие MySQL Server, который вы только что запускали, с помощью SET GLOBAL innodb_fast_shutdown=0 и затем закройте сервер. Это гарантирует, что все грязные страницы сбрасываются, а следовательно не будет никакого журнала отката, обрабатываемого позже для модернизированного сервера. Установите более новую версию сервера MySQL на целевом сервере. Запустите более новую версию MySQL Server, которую вы установили, на каталоге данных, который вы восстановили и подготовили в предыдущих шагах. Выполните любые другие дополнительные upgrade steps, которые могли бы требоваться для вашей платформы или дистрибутива, как описано в документации MySQL. MySQL 8.0.15 и позже: удостоверьтесь, что mysql_upgrade который идет с вашей более новой версией сервера, применяется (нет никакой потребности выполнять mysql_upgrade после модернизации до MySQL 8.0.16 или позже). После выполнения этих шагов проверьте свои данные, чтобы удостовериться, что восстановление было успешным.

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

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