Итак, я изучал моментальные снимки LVM, и мне показалось, что это возможный метод резервного копирования mysql, чтобы он, по крайней мере, был устойчив к сбоям.
Моя проблема в том, что у меня есть серверы mysql, где каталоги данных mysql находятся в сети SAN, и я хотел бы использовать возможность создания моментальных снимков массивов для mysql LUN.
Я думал, что могу добавить второй LUN, создать на нем PV, добавить его в VG на сервере, создать LV, который будет моментальным снимком mysql LV, и смонтировать его.
На этом этапе я мог скопировать данные туда, где мне нужно было их скопировать.
Эта часть хороша, но это требует времени и зависит от размера базы данных, потому что мне нужно фактически копировать данные.
После создания снимка могу ли я сделать снимок массива LUN mysql, а затем выпустить снимок LVM и удалить его?
кто-нибудь пробовал это?
Насколько я понимаю, изменения, внесенные после снимка LVM, хранятся в снимке LV. Это верно?
Спасибо!
Я вообще не вижу в этом проблемы. Просто убедитесь, что у вас достаточно свободного места в 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) Удерживая соединение open run:
lvcreate -L16G -s -n dbbackup /dev/Main/Data
- Это создаст моментальный снимок с именем dbbackup для логического тома Main / Data. Вы должны указать достаточно места для отмены операций для хранения изменений во время процесса резервного копирования - в данном случае я указал 16 ГБ. Если размер отмены недостаточно велик, моментальный снимок станет недействительным и резервное копирование будет прервано.Иногда вы можете столкнуться с ошибками на этом этапе. Самая распространенная из них, которую я недавно видел: моментальный снимок: Требуемые цели сопоставления устройств не обнаружены в вашем ядре - это означает, что модуль моментального снимка не загружен в ваше ядро по умолчанию. и вам нужно загрузить его, что можно сделать, запустив
modprobe dm-snapshot
3) Теперь вы создали логический том и можете разблокировать таблицы, но перед этим вам, вероятно, следует записать позицию двоичного журнала, что выполняется путем запуска
SHOW MASTER STATUS
- Это положение двоичного журнала, в котором вы должны указать своих подчиненных MySQL, созданных из этого снимка.4) Снимок создан, теперь вы хотите, чтобы сервер MySQL продолжал работу, что можно сделать, запустив
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, чтобы указать ведомому устройству на сохраненную позицию двоичного журнала: измените ведущее устройство на
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.
* ОБНОВИТЬ *
План B:
настроить репликацию и использовать mysqldump
от ведомого, таким образом он не влияет на ваш главный сервер mysql.
Я также посмотрел вслед