В предыдущей статье мы рассмотрели вопрос создания горячей резервной копии MySQL с одновременным копированием на удаленный сервер, но скопировать это часть задачи, ведь на удаленном сервере может потребоваться запустить рабочий MySQL из этой горячей копии. Ниже я расскажу как это сделать.
Исходные данные: Ubuntu 18.04 (bionic), Oracle MySQL 5.7.29
Задача: Восстановить MySQL из горячей (hotbackup) резервной копии.
В предыдущей статье мы сохранили hotbackup в каталоге /root/mysqlbackup на удаленном сервере. Теперь нам нужно восстановить ее и запустить MySQL.
Предполагается, что на сервере уже установлен Oracle MySQL 5.7.29 в базовом виде, произведена его настройка конкретного для этого сервера, а так же установлен набор утилит от Percona (xtrabackup, qpress). Процедура восстановления состоит из нескольких простых шагов:
1. Подготовка нашей горячей резервной копии для восстановления.
Смысл подготовки в том, что файлы данных, которые мы копировали с исходного сервера, не согласованы на определенный момент времени, потому что они копировались в разное время во время работы xtrabackup и они могли быть изменены, когда это происходило. Если Вы попытаетесь запустить InnoDB с этими файлами данных, то он обнаружит повреждение и не запустится.
Поэтому нужно запустить xtrabackup с опцией —prepare для подготовки и согласования файлов на один момент времени.
Вы можете запустить операцию подготовки на любом сервере. Не обязательно это делать на исходном сервере или сервере, на котором вы собираетесь восстановить данные. Вы можете скопировать резервную копию на служебный сервер и подготовить ее там.
На этапе подготовки xtrabackup запускает встроенный в нее движок InnoDB с некоторыми отключенными опциями и запускает восстановление после сбоя скопированных файлов данных и журналов.
Если резервная копия была в сжатом виде, то в процессе подготовки все файлы будут распакованы, для этого используется утилита qpress. Следует знать, что на распаковку потребуется дополнительное место на сервере, поэтому будьте внимательны если у Вас большая резервная копия.
Так же следует знать, что если Вы намерены подготовить резервную копию которая основана на дополнительных инкрементных резервных копий, то Вам следует использовать xtrabackup с опцией —apply-log-only при подготовке, иначе Вы не сможете применять инкрементные резервные копии к ней. Более подробно про инкрементных резервных копиях можно почитать в официальной документации.
ВАЖНО! В процессе подготовки не рекомендуется прерывать работу xtrabackup, т.к. это приведет к повреждению вашей горячей резервной копии и в дальнейшем к невозможности восстановления. Именно поэтому запускать xtrabackup лучше в сессии screen, чтобы в случае потери связи с сервером ваш сеанс работы xtrabackup не завершился. Итак запускаем:
# screen
xtrabackup --prepare --target-dir=/root/mysqlbackup
в конце работы вы получите примерно такой вывод:
InnoDB: FTS optimize thread exiting.
InnoDB: Starting shutdown...
InnoDB: Shutdown completed; log sequence number 11306536
200408 22:28:31 completed OK!
Где цифра11306536 будет уникальна для вашей системы — это LSN (log sequence number).
2. Далее нам нужно остановить MySQL на сервере-приемнике, переименовать каталог /var/lib/mysql, создать новый, выставить права, запустить восстановление и далее запустить уже восстановленный MySQL:
Останавливаем MySQL:
# systemctl stop mysqlПроверим отсутствие процесса mysqld:
# ps -auxw | grep [m]ysqldПереименуем каталог /var/lib/mysql, после восстановления его можно будет удалить:
# mv /var/lib/mysql /var/lib/mysql_oldСоздаем пустой каталог /var/lib/mysql и выставляем права:
# mkdir -p /var/lib/mysql
# chmod 750 /var/lib/mysq
Запускаем процедуру восстановления из горячей резервной копии (hotbackup):
# xtrabackup --copy-back --target-dir=/root/mysqlbackupС опцией —copy-back утилита xtrabackup будет копировать резервную копию из /root/mysqlbackup в каталог /var/lib/mysql
Стоит отметить, что xtrabackup берет каталог-назначения (у нас это /var/lib/mysql) куда будет произведено копирование из файла настроек MySQL. Так же есть опция —move-back при использовании которой данные будут перемещены, а не скопированы — это полезно при больших размерах резервной копии, тем самым Вы сэкономить место на сервере и что еще лучше — ускорите процедуру восстановления, ведь перемещение в пределах одного раздела будет практически моментальным.
Процедура восстановления выглядит примерно так:
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --tmpdir=/tmp
xtrabackup: recognized client arguments: --copy-back=1 --target-dir=/root/mysqlbackup
xtrabackup version 2.4.19 based on MySQL server 5.7.26 Linux (x86_64) (revision id: c2d69da)
200408 22:29:44 [01] Copying ib_logfile0 to /var/lib/mysql/ib_logfile0
200408 22:29:45 [01] ...done
200408 22:29:46 [01] Copying ib_logfile1 to /var/lib/mysql/ib_logfile1
200408 22:29:46 [01] ...done
200408 22:29:48 [01] Copying ibdata1 to /var/lib/mysql/ibdata1
200408 22:29:50 [01] ...done
200408 22:29:51 [01] Copying ./ib_buffer_pool to /var/lib/mysql/ib_buffer_pool
200408 22:29:51 [01] ...done
...
200408 22:29:57 [01] ...done
200408 22:29:57 completed OK!
Вывод в конце completed OK! говорит о ее успешном завершении.
Если погрузиться чуть глубже, то —copy-back это аналог команды (не выполняйте ее ;) ):
#rsync -avrP /root/mysqlbackup/ /var/lib/mysql/Вариант с rsync как замена xtrabackup —copy-back полностью рабочий, он может пригодиться если Вы выполняете подготовку резервной копии (п.1) на промежуточном сервере, подключаете сетевую шару с подготовленной копией на целевой сервер и копируете ее в datadir. На этом сервере xtrabackup в принципе не нужен.
Далее устанавливаем владельца файлов, стандартно это пользователь mysql и группа mysql:
# chown -R mysql:mysql /var/lib/mysqlИ запускаем восстановленный MySQL:
# systemctl start mysqlПосмотрим последние 20 строк лога error.log:
# tail -n 20 /var/log/mysql/error.logВывод команды:
....
2020-04-08T17:30:17.391818Z 0 [Note] Generated uuid: '9d0e23cd-79be-11ea-ae96-000c29f8dd8e', server_start_time: 7308497771878576021, bytes_sent: 94787016996592
2020-04-08T17:30:17.391842Z 0 [Warning] No existing UUID has been found, so we assume that this is the first time that this server has been started. Generating a new UUID: 9d0e23cd-79be-11ea-ae96-000c29f8dd8e.
2020-04-08T17:30:17.423418Z 0 [Note] Found ca.pem, server-cert.pem and server-key.pem in data directory. Trying to enable SSL support using them.
2020-04-08T17:30:17.423441Z 0 [Note] Skipping generation of SSL certificates as certificate files are present in data directory.
2020-04-08T17:30:17.424811Z 0 [Warning] CA certificate ca.pem is self signed.
2020-04-08T17:30:17.424850Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory.
2020-04-08T17:30:17.425936Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2020-04-08T17:30:17.425978Z 0 [Note] IPv6 is available.
2020-04-08T17:30:17.425985Z 0 [Note] - '::' resolves to '::';
2020-04-08T17:30:17.426022Z 0 [Note] Server socket created on IP: '::'.
2020-04-08T17:30:17.492994Z 0 [Note] InnoDB: Buffer pool(s) load completed at 200408 22:30:17
2020-04-08T17:30:17.495342Z 0 [Note] Event Scheduler: Loaded 0 events
2020-04-08T17:30:17.496230Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Мы видим, что MySQL успешно запустился, был создан новый UUID экземпляра и он может принимать подключения.
Cпасибо автору!
Источник:
https://blog.programs74.ru/how-to-restore-mysql-from-hot-backup/
Конец!