Резервное копирование MySQL, живущего в сети SAN, с использованием снимков LVM. это выполнимо?

Итак, я изучал снимки LVM, и это похоже на выполнимый способ резервного копирования mysql, чтобы он был по крайней мере устойчивым к сбоям.

Моя проблема в том, что у меня есть серверы mysql, где каталоги данных mysql живут в сети SAN, и я хотел бы использовать возможность создания снимков массивов для mysql LUN.

Я думал, что мог бы добавить второй LUN, создать PV на нем, добавить его в VG на сервере, создать LV, который будет снимком mysql LV, и смонтировать его.

На этом этапе я мог скопировать данные туда, куда мне нужно было их скопировать.

Эта часть хороша, но она требует времени и зависит от размера базы данных, потому что мне нужно копировать данные.

После создания снимка можно ли сделать снимок массива из mysql LUN, а затем выпустить снимок LVM и удалить его?

кто-нибудь пробовал это?

Насколько я понимаю, изменения, сделанные после снимка LVM, сохраняются в снимке LV. Это правильно?

Спасибо!

Источник

2 ответа

Решение

Я не вижу проблемы с этим вообще. Просто убедитесь, что у вас достаточно свободного места в lv удерживая снимок, чтобы у вас не осталось времени на копирование файлов в другое место (в противном случае снимок будет удален).

Типичный процесс создания резервных копий MySQL с помощью моментального снимка - сначала выполнить сброс с блокировкой чтения, затем запустить моментальный снимок, а затем снять блокировку чтения. В этот момент вы можете скопировать /var/lib/mysql каталог, куда вы хотите - и делать с ним все, что вы хотите.

Команда Percona сделала хорошую статью об этом здесь, http://www.mysqlperformanceblog.com/2006/08/21/using-lvm-for-mysql-backup-and-replication-setup/

Руководство Percona по резервным копиям LVM MySQL

1) Подключитесь к MySQL и запустите FLUSH TABLES WITH READ LOCK

2) Удерживая соединение открытым, запустите: lvcreate -L16G -s -n dbbackup /dev/Main/Data - Это создаст моментальный снимок с именем dbbackup для логического тома Main/Data . Вы должны указать достаточно места для отмены для хранения изменений в процессе резервного копирования - в этом случае я указал 16 ГБ. Если размер отмены недостаточно велик, снимок будет признан недействительным, а резервное копирование будет прервано.

Иногда вы можете столкнуться с ошибками на этом шаге. Самая распространенная, которую я недавно видел, это: снимок: требуемые цели устройства отображения не обнаружены в вашем ядре - это означает, что модуль снимка не загружен в ваше ядро ​​по умолчанию и вам нужно загрузить его, что делается путем запуска modprobe dm-snapshot

3) Теперь вы создали логический том и можете разблокировать таблицы, но перед этим вам, вероятно, следует записать двоичную позицию в журнале, которая выполняется путем запуска SHOW MASTER STATUS - Это двоичная позиция журнала, вам нужно указать ваши подчиненные MySQL, созданные из этого снимка.

4) Снимок создан, теперь вы хотите, чтобы MySQL Server продолжил работу, что выполняется путем запуска UNLOCK TABLES или просто закрытие соединения.

5) Смонтировать резервную копию файловой системы: mount /dev/Main/dbbackup /mnt/backup

6) Скопируйте данные в резервную копию. Обычно вы можете пропустить медленные журналы запросов и журналы ошибок при выполнении резервного копирования. Вы также можете пропустить большинство двоичных журналов - однако, если некоторые из ваших ведомых устройств сильно отстают, вы можете сохранить некоторые из последних двоичных журналов на всякий случай, или вы можете предположить, что в случае восстановления из резервной копии вам потребуется восстановить подчиненные ну и пропустите двоичные журналы в процессе резервного копирования.

7) Размонтировать файловую систему umount /mnt/backup

8) Удалить снимок: lvremove -f /dev/Main/dbbackup

Если вы хотите создать ведомое устройство на основе такого снимка, вам нужно выполнить пару более простых шагов

9) Извлечение / копирование базы данных в каталог ведомой базы данных.

10) Запустите MySQL Server. Подождите, пока он выполнит восстановление.

11) Используйте CHANGE MASTER TO, чтобы указать slave на сохраненную двоичную позицию журнала: измените master на master_host="master", master_user="user", master_password="password", master_log_file="host-bin.000335", master_log_pos=401934686;

12) Беги SLAVE START перезапустить репликацию.

Источник

Это не так, как работает снимок LVM, лучше всего использовать mysqldump делать резервные копии MySQL.

* ОБНОВИТЬ *

План б:

настроить репликацию и использовать mysqldump от ведомого, таким образом это не затрагивает Ваш главный сервер MySQL.

Я также посмотрел вверх после

Создание резервной копии с использованием снимков

Источник
Другие вопросы по тегам