LINUX.ORG.RU

Бэкап mysql с помощью снапшотов lvm

 , , ,


2

1

Доброго времени суток. Есть одно высоконагруженное приложение (zabbix), использующее базу данных mysql. Сейчас, база данных выросла до 10G. То, что бэкапы с использованием mysqldump длятся по 10-20 минут, ещё можно стерпеть. Но, восстановление из бэкапа 6-8 часов - перебор.

Прочитал про очень интересный метод. Поднимается lvm, утилитой mylvmbackup делается снапшот.

Вопрос вот в чем: zabbix использует innodb, допустим, я делаю так:

mylvmbackup --user=root --password=pass --innodb_recover --skip_flush_tables \ --mycnf=/etc/mysql/my.cnf --vgname=test --lvname=part1 --backuptype=tar --backupdir=/backup

/base смонтирована в /dev/test/part1

В итоге получаю архив с базой данных и всеми файлами наодящимися в директории /base. Если остановить mysql и заменить содержимое папки /base/mysql всё вроде бы работает. Однако, все пишут, что раздел с котрого снят снапшот начинает работать в разы медленее. Что с этим можно сделать? Как-то возможно снимать снапшот только с конкретной папки в разделе? Приблизительно, как долго будет длитя снапшот, с 10-15 G базы?

И вообще, больше вопросов, чем ответов на данный момент. По данной тематики достаточно статей и примеров, но информация рознится.

Кто-то пользуется подобной схемой? Какие есть «подводные камни»?

★★

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

Только на время существования снапшота и только при записи на раздел. После бекапа и удаления снапшота всё возвращается к исходному состоянию (по быстродействию).

sdio ★★★★★
()

а при использовании mylvmbackup мускул не уходит в кому?

vxzvxz ★★★
()

Насчет подводных камней... Такой бэкап может не завестись на другом сервере. Дамп развернется где угодно.

afanasiy ★★★★
()
Ответ на: комментарий от sdio

А совсем глупый вопрос: как только снапшот создается mylvmbackup, он отчишает после себя всё ненужно и быстродействие приходит в норму. Или, требуется что-то дополнительно сделать?

nixit ★★
() автор топика
Ответ на: комментарий от King_Carlo

Я же написал - временем восстановления.

nixit ★★
() автор топика
Ответ на: комментарий от nixit

Бывает так: сервер умер неожиданно, восстановлению не подлежит. Поднимаешь новый, ставишь новую ось с новым мускулем, вспоминаешь, что старый сервер не обновлял пару лет, потому что всё работало, и трогать зря не хотелось. Подпихиваешь новому мускулю старые файлы, а он на них ругается.

Про lvm: после того как ты забэкапил базу со снапшота, снапшот нужно размонтировать и удалить. Тогда производительность вернется к исходной.

Если тебе так важно время восстановления, лучше делай 2 бэкапа, один mysqdump другой lvm.

afanasiy ★★★★
()
Ответ на: комментарий от afanasiy

Про два бэкапа тоже начал подумывать. Однако, если версия mysql будет одинаковой, он должен восстановится.

Про снапшот не совсем понял:

Вот, у меня есть lvm раздел, допустим /dev/test/part1. Примонтирован он, допустим в /base, там же хранятся базы mysql.

Я запускаю mylvmbackup, он отрабатывает. Что я должен удалить?

Или, при использовании mylvmbackup нужно создавать новый пустой lvm раздел, монтировать его, а затем удалять? Ключи --vgname и --lvname указывают на раздел с базами же?

nixit ★★
() автор топика
Последнее исправление: nixit (всего исправлений: 1)
Ответ на: комментарий от nixit

Про mylvmbackup ничего не могу сказать, я этой тулзой не пользовался. Надо смотреть в доках, что и как она делает.

afanasiy ★★★★
()
Ответ на: комментарий от nixit

Заинтересовался, почитал здесь: http://nikmy.ru/index.php/stati/linux/sudb/120-rezervnoe-kopirovanie-baz-dann...

Насколько я понял mylvmbackup сама создает, монтирует, размонтирует и удаляет снапшоты.

Посмотри свой лог, если там в конце есть

Logical volume "название твоего снашота" successfully removed
значит снапшот удален и производительность вернулась в норму.

afanasiy ★★★★
()
Ответ на: комментарий от nixit

какой смысл использовать mylvmbackup если мускул заблокирует на время бекапа свои таблицы, т.е. просто напросто его работа будет в дауне, не легче ли остановить мускул и тем же таром без сжатия сделать бекап.

После бекапа в lvm удаляется сам снапшот, в который при бекапе вытесняются старые (перезаписанные) данные с бекапируемого логического тома

Про два бэкапа тоже начал подумывать

вот это правильно.

vxzvxz ★★★
()
Ответ на: комментарий от nixit

при снятии бекапа c тома lvm позволяет в него писать (Copy-on-write) и если не залочить таблицы, то из директории мускула получите мусор внутри бекапа.

vxzvxz ★★★
()
Последнее исправление: vxzvxz (всего исправлений: 1)
Ответ на: комментарий от afanasiy

Спасибо за ссылку. Да, есть такая строка.

nixit ★★
() автор топика
Ответ на: комментарий от vxzvxz

Процесс создания бэкапа состоит из следующих фаз: установка блокировки на таблицы, инициирование сброса кэшей на диск, создание LVM снапшота директории с MySQL таблицами, снятие блокировки. Так как время создания снапшота очень мало, простой базы сводится к минимуму при полном сохранении целостности.

mysqldump блокирует на гораздо большее время.

nixit ★★
() автор топика
Ответ на: комментарий от vxzvxz

самый минимальный простой при таком файловом бекапе залоченного мускула может обеспечить только zfs.

vxzvxz ★★★
()
Ответ на: комментарий от nixit

mysqldump блокирует на гораздо большее время.

это понятно. но какой смысл использовать прокладку в виде mylvmbackup (кроме безосновательной дополнительной нагрузки на дисковую подсистему) если он для бекапа использует тот же tar.

vxzvxz ★★★
()
Ответ на: комментарий от vxzvxz

при снятии бекапа c тома lvm позволяет в него писать (Copy-on-write)

чтобы это не происходило можно запускать lvcreate с разрешениям только на чтение

-p r
но не знаю как там делает mylvmbackup.

afanasiy ★★★★
()
Ответ на: комментарий от vxzvxz

А что делает сея утилита? Снапшот. Или, имеется ввиду lvm вцелом?

nixit ★★
() автор топика
Последнее исправление: nixit (всего исправлений: 3)
Ответ на: комментарий от afanasiy

Сейчас почитал повнимательнее, и вычитал, что сея утилита блокирует доступ на чтение. А как же запись...

nixit ★★
() автор топика
Ответ на: комментарий от nixit

посмотри в сторону того, что мне советовал главный задрот по мускулю и zfs, а так же бывший самый злой модер лоре тазит, а именно xtrabackup

erzent ☆☆
()
Ответ на: комментарий от erzent

Интересно. Нашел статью на хабре, ушел изучать.

nixit ★★
() автор топика
Ответ на: комментарий от afanasiy

Это здорово. Не знал. Однако, восстанавливать всё равно проблематично.

nixit ★★
() автор топика
Ответ на: комментарий от erzent

Почитал, довольно интересно. А как обстоят дела со временем восстановления инкрементного бэкапа?

nixit ★★
() автор топика
Ответ на: комментарий от nixit

честно, пока не приходилось это делать, я этим репликацию настроил и бэкапы, а затем ушёл из конторы.

erzent ☆☆
()
Ответ на: комментарий от Komintern

Выше посоветовали, как раз присматриваюсь к ней. Вопрос вот в чем. Стоит ли в таком случае делать бэкапы ещё и с использование mysqldump?

nixit ★★
() автор топика
Ответ на: комментарий от afanasiy

На сколько мне известно глабли там только а архитектурой CPU, точнее c big-endian/little-endian. Или там ещё какие-то грабли?

MrClon ★★★★★
()
Ответ на: комментарий от nixit

а зачем?
если хочется именно дампы, то типичная схема бекапа через mysqldump - это с использованием read only replication. ставится односторонняя репликация, на время бекапа процесс репликации приостанавливается, дамп снимается с реплики. затем возобновляем и реплика догоняет состояние мастера.

Komintern ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.