Средства создания горячих BackUp`ов MySQL

[mixermsk]

Если честно, с кластером еще поработать не успел, хотя тема мне крайне интересна(как и любой HighLoad). С альфой 6й ветки тоже. Как только опробую технологию — могу отписаться о содеянном, заодно и тему бэкапа освещу :)

[odessky]

Репликация идет в один поток и slave будет отставать от мастера

[zerkms]

тут палка о двух концах:
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)

[Veshij]

В смылсе? На совсем хай-лоаде может и будет, при штатных нагрузках — не отстает.
Тем более в 5.1 есть row-based репликация.

[DustCn]

У меня mysqldump почему-то из-под крона не желает исполнятся. Уже голову себе всю сломал :(
mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log
Причем руками все работает ок…

[zzeus]

mysqldump лежит вне PATH с которым работает крон?

[stasikos]

А разве крон не говорит, почему?

[stlaus]

надо указать полный путь для mysqldump. В кроне будет выглядеть вот так (путь для FreeBSD):

/usr/local/bin/mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log

[etz]

Или дописать в строку PATH файла /etc/crontab путь до бинарника

[mixermsk]

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

[DustCn]

Никаких сообщений в логе крона не появлялось. Прописал полный путь — посмотрим.
Спасибо за помощь.

[kyb27]

Раз уж сказали про репликацию и LVM хорошо было бы упомянуть drbd и кластеры.
А так заметка в самый раз.

[Veshij]

Да, только надо хорошо мониторить работу слейва — чтобы не получить дамп с кривыми данными.

[crocodile2u]

> LVM — дополнительный слой между файловой системой и самым жестким диском

А на основании чего проводится ранжирование дисков по жесткости? ;)

[mixermsk]

Пофиксил, спасибо :)

[Psixozzz]

Не знаю как сейчас, но раньше mysqlhotcopy был платным инструментом.

[pwlnw]

Никогда не был. Вы путаете с инструментом от innodb. да и тот потерял актуальность в связи с недавним появлением xtrabackup

[Psixozzz]

Совершенно верно. В свое время еще пришлось написать свой аналог mysqlhotcopy для innodb. Запамятовал за давностью лет, бывает.

[pwlnw]

аналог? :) или вы просто глобальную блокировку ставили и .ibd копировали?

[andrew_tch]

ЕДИНСТВЕННЫЙ вариант на самом деле «горячего» бекапа это реплика и снятие бекапа с нее. Любые другие методы либо требуют блокировки таблиц (а вы побекапте 4-5 миллионов строк с блокировкой, время ощутимое), либо не гарантируют целостности. Говорить о бекапе через LVM это приблизительно то же самое что о бекапе через RAID или Norton Ghost.

[mixermsk]

На самом деле — в случае если у вас таблицы, не поддерживающие транзакции(MyISAM тот же), даже используя реплику вы можете остановить slave в неподходящее время и оставить какую-нибудь запись без связки с другой таблицей. Я это к тому, что очень многое зависит от реализации конкретно взятого сервера.
В то же время, например в случае с маленьким форумом у вас вероятнее всего ничего не случится если вы поймаете момент минимальной нагрузки на сервер. С действительно большими базами такой фокус не прокатит, да — к слову, я об этом писал. Думаю, по аналогии с первым пунктом, люди поймут, чем грозит блокировка живой базы.
Касательно RAID`а — сама по себе избыточность данных не спасает от главного момента(про который я уже говорил) — когда кто-то с похмелья выполняет на сервере DROP. RAID в этом случае покорно снесёт файлы со всех дисков, входящих в том. LVM же здесь упоминается именно из-за возможности налету сделать дамп раздела

[andrew_tch]

а вам не кажется, что термин «на лету» и «горячий бекап» подразумевает бекап без какого-либо влияния на сервер? т.е. никаких flush, lock etc.

[DmitryKoterov]

Бэкап при помощи LVM занимает считанные секунды (а иногда и считанные миллисекунды). По сравнению с репликацией он имеет то преимущество, что не ломается без конца (а репликация — конструкция достаточно шаткая) и не требует отдельной машины (и почти не требует ресурсов). Вот примерная последовательность команд:

mysql: flush (5-10 секунд, не блокирует ничего, так что не считается)
— mysql: lock (мгновенно)
mysql: flush (меньше секунды)
lvm: сделать snapshot (меньше секунды)
mysql: unlock (мгновенно)
lvm: отпустить snapshot

[andrew_tch]

ghost@isolde:/var/lib/mysql# du -h --summarize
14.1G.

я честно говоря не делал lvcreate --snapshot ни разу, просто думаю что на таком объеме это не миллисекунды.

[DmitryKoterov]

Насколько я понимаю, операция создания снапшота в него ничего не записывает. Это просто указание системе «начиная с этого момента все данные записывай, пожалуйста, не на основной диск, а в снапшот». Поэтому создается снапшот очень быстро. Ну а flush выполняется быстро потому, что он идет почти сразу после первого (долгого) flush-а.

[andrew_tch]

кажется, снапшот — это слепок текущего состояния диска, и система при этом оставляет снап в нормальном состоянии и продолжает писать на диск.

[2moderator]

когда кажется, надо креститься, а не комментировать

[mche]

Каким образом подбирается размер снапшота?
Обязательно ли он должен быть таким же размером как и база?

[pwlnw]

экспериментально. 25% большинству хватает. если вы имеете ввиду зарезервированное место для блоков новой информации при использовании этих самых снапшотов.

[Pilat]

В статье обойдён вниманием самый интересный вариант бэкапа — инкрементальный. Базу в несколько гигабайт никакими методами быстро не пробэкапить, да и хранить полные копии сложно. Возможно, поможет какое-то средство типа использования бинарных логов (если есть транзакции) или какого-то прокси типа NDB или mysqlproxy?

[DmitryKoterov]

ИМХО инкрементность на основе бинлога — слишком неустойчиво.
rdiff-backup.nongnu.org не спасет ли?

[Pilat]

Как раз только на основе бинарных логов инкрементальное копирование и можно сделать по-настоящему, но классический mysql пообще без транзакций живёт, так что это отпадает. А вот на proxy вполне можно было бы включить журнал изменений.

rduff-backup я пробовал на маленьких базах, работает. Но если он должен найти отличия в гигабайтных файлах — это само по себе долго, если на время сравнения включать блокировку базы, то можно выйти за таймауты.

[OdobenusRosmarus]

каким образом наличие транзакций влияет на binlog? Туда все равно (для транзакционных engines) только закоммиченые транзакции попадают.

[Pilat]

На транзакционных СУБД бинарные логи — побочный продукт жизнедеятельности, они есть всегда, поэтому нет накладных расходов на их поддержку. MySQL поддерживает бинарные логи, и в частности для инкрементального копирования, но их надо включить и смириться с небольшой потерей производительности.

[OdobenusRosmarus]

А о какой потере производительности вы говорите? Какие нибудь цифры можете привести?

[Pilat]

Не могу, но это же в два раза больше операций записи на диск.

[Decoy]

В первом пункте все же три ключевых момента, а не два. Время выполнения операции, думаю, стоит считать важным фактором.

[mixermsk]

Поправил, спасибо. Постил ночью — местами ляпы. Выше в комментах обсуждался «самый жесткий диск», например. :)

[deniamnet]

если размер БД не очень большой, можно попробовать Sypex Dumper

[JustLuckyGuy]

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

[pwlnw]

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

[z1nkum]

Репликация может быть и master-master.
А для особых извращенцев: master-master-master. :)

[OdobenusRosmarus]

для lvm backup никаких новых скриптов писать не надо, они уже есть https://launchpad.net/mylvmbackup

[OdobenusRosmarus]

есть еще решения для backup — например https://launchpad.net/percona-xtrabackup — non-blocking hot backup для innodb

[Murz]

Добавьте в статью рядом с mysqlhotcopy ещё xtrabackup, т.к. mysqlhotcopy насколько я понимаю криво будет копировать innodb таблицы, а xtrabackup как раз этот недостаток восполняет.
Но xtrabackup по-моему наоборот myisam не будет копировать, так что придётся наверно их в связке использовать.
Странно, почему до сих пор не сделали общую тулзу которая сразу всё умеет бекапить ;(

[DjOnline]

Прошло 5 лет, так и не сделали. Innodb правда стал побыстрее, но по прежнему занимает больше места на диске. Появился движок Toku с компрессией данных (и их уже купила Percona), но утилита бэкапа для него платная.