Pull to refresh

Comments 49

UFO just landed and posted this here
Если честно, с кластером еще поработать не успел, хотя тема мне крайне интересна(как и любой HighLoad). С альфой 6й ветки тоже. Как только опробую технологию — могу отписаться о содеянном, заодно и тему бэкапа освещу :)
Репликация идет в один поток и slave будет отставать от мастера
тут палка о двух концах:
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)
В смылсе? На совсем хай-лоаде может и будет, при штатных нагрузках — не отстает.
Тем более в 5.1 есть row-based репликация.
У меня mysqldump почему-то из-под крона не желает исполнятся. Уже голову себе всю сломал :(
mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log
Причем руками все работает ок…
mysqldump лежит вне PATH с которым работает крон?
А разве крон не говорит, почему?
надо указать полный путь для mysqldump. В кроне будет выглядеть вот так (путь для FreeBSD):

/usr/local/bin/mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log
Или дописать в строку PATH файла /etc/crontab путь до бинарника
А еще желательно указывать полный путь к файлу, куда будет дамп литься.
Никаких сообщений в логе крона не появлялось. Прописал полный путь — посмотрим.
Спасибо за помощь.
Раз уж сказали про репликацию и LVM хорошо было бы упомянуть drbd и кластеры.
А так заметка в самый раз.
UFO just landed and posted this here
Да, только надо хорошо мониторить работу слейва — чтобы не получить дамп с кривыми данными.
> LVM — дополнительный слой между файловой системой и самым жестким диском

А на основании чего проводится ранжирование дисков по жесткости? ;)
Не знаю как сейчас, но раньше mysqlhotcopy был платным инструментом.
Никогда не был. Вы путаете с инструментом от innodb. да и тот потерял актуальность в связи с недавним появлением xtrabackup
Совершенно верно. В свое время еще пришлось написать свой аналог mysqlhotcopy для innodb. Запамятовал за давностью лет, бывает.
аналог? :) или вы просто глобальную блокировку ставили и .ibd копировали?
ЕДИНСТВЕННЫЙ вариант на самом деле «горячего» бекапа это реплика и снятие бекапа с нее. Любые другие методы либо требуют блокировки таблиц (а вы побекапте 4-5 миллионов строк с блокировкой, время ощутимое), либо не гарантируют целостности. Говорить о бекапе через LVM это приблизительно то же самое что о бекапе через RAID или Norton Ghost.
На самом деле — в случае если у вас таблицы, не поддерживающие транзакции(MyISAM тот же), даже используя реплику вы можете остановить slave в неподходящее время и оставить какую-нибудь запись без связки с другой таблицей. Я это к тому, что очень многое зависит от реализации конкретно взятого сервера.
В то же время, например в случае с маленьким форумом у вас вероятнее всего ничего не случится если вы поймаете момент минимальной нагрузки на сервер. С действительно большими базами такой фокус не прокатит, да — к слову, я об этом писал. Думаю, по аналогии с первым пунктом, люди поймут, чем грозит блокировка живой базы.
Касательно RAID`а — сама по себе избыточность данных не спасает от главного момента(про который я уже говорил) — когда кто-то с похмелья выполняет на сервере DROP. RAID в этом случае покорно снесёт файлы со всех дисков, входящих в том. LVM же здесь упоминается именно из-за возможности налету сделать дамп раздела
а вам не кажется, что термин «на лету» и «горячий бекап» подразумевает бекап без какого-либо влияния на сервер? т.е. никаких flush, lock etc.
Бэкап при помощи LVM занимает считанные секунды (а иногда и считанные миллисекунды). По сравнению с репликацией он имеет то преимущество, что не ломается без конца (а репликация — конструкция достаточно шаткая) и не требует отдельной машины (и почти не требует ресурсов). Вот примерная последовательность команд:

mysql: flush (5-10 секунд, не блокирует ничего, так что не считается)
— mysql: lock (мгновенно)
mysql: flush (меньше секунды)
lvm: сделать snapshot (меньше секунды)
mysql: unlock (мгновенно)
lvm: отпустить snapshot
ghost@isolde:/var/lib/mysql# du -h --summarize
14.1G.

я честно говоря не делал lvcreate --snapshot ни разу, просто думаю что на таком объеме это не миллисекунды.
Насколько я понимаю, операция создания снапшота в него ничего не записывает. Это просто указание системе «начиная с этого момента все данные записывай, пожалуйста, не на основной диск, а в снапшот». Поэтому создается снапшот очень быстро. Ну а flush выполняется быстро потому, что он идет почти сразу после первого (долгого) flush-а.
кажется, снапшот — это слепок текущего состояния диска, и система при этом оставляет снап в нормальном состоянии и продолжает писать на диск.
когда кажется, надо креститься, а не комментировать
Каким образом подбирается размер снапшота?
Обязательно ли он должен быть таким же размером как и база?
экспериментально. 25% большинству хватает. если вы имеете ввиду зарезервированное место для блоков новой информации при использовании этих самых снапшотов.
UFO just landed and posted this here
В статье обойдён вниманием самый интересный вариант бэкапа — инкрементальный. Базу в несколько гигабайт никакими методами быстро не пробэкапить, да и хранить полные копии сложно. Возможно, поможет какое-то средство типа использования бинарных логов (если есть транзакции) или какого-то прокси типа NDB или mysqlproxy?
Как раз только на основе бинарных логов инкрементальное копирование и можно сделать по-настоящему, но классический mysql пообще без транзакций живёт, так что это отпадает. А вот на proxy вполне можно было бы включить журнал изменений.

rduff-backup я пробовал на маленьких базах, работает. Но если он должен найти отличия в гигабайтных файлах — это само по себе долго, если на время сравнения включать блокировку базы, то можно выйти за таймауты.
каким образом наличие транзакций влияет на binlog? Туда все равно (для транзакционных engines) только закоммиченые транзакции попадают.
На транзакционных СУБД бинарные логи — побочный продукт жизнедеятельности, они есть всегда, поэтому нет накладных расходов на их поддержку. MySQL поддерживает бинарные логи, и в частности для инкрементального копирования, но их надо включить и смириться с небольшой потерей производительности.
А о какой потере производительности вы говорите? Какие нибудь цифры можете привести?

Не могу, но это же в два раза больше операций записи на диск.
В первом пункте все же три ключевых момента, а не два. Время выполнения операции, думаю, стоит считать важным фактором.
Поправил, спасибо. Постил ночью — местами ляпы. Выше в комментах обсуждался «самый жесткий диск», например. :)
если размер БД не очень большой, можно попробовать Sypex Dumper
Насколько я помню, это более медленный аналог первого варианта.
Это не аналог, это уникальный живучий скрипт жизненно необходимый в условиях унылого виртуального хостинга с массой ограничений.
Я стыжусь его использовать, но приходится.
Репликация может быть и master-master.
А для особых извращенцев: master-master-master. :)
для lvm backup никаких новых скриптов писать не надо, они уже есть https://launchpad.net/mylvmbackup
есть еще решения для backup — например https://launchpad.net/percona-xtrabackup — non-blocking hot backup для innodb

Добавьте в статью рядом с mysqlhotcopy ещё xtrabackup, т.к. mysqlhotcopy насколько я понимаю криво будет копировать innodb таблицы, а xtrabackup как раз этот недостаток восполняет.
Но xtrabackup по-моему наоборот myisam не будет копировать, так что придётся наверно их в связке использовать.
Странно, почему до сих пор не сделали общую тулзу которая сразу всё умеет бекапить ;(
Прошло 5 лет, так и не сделали. Innodb правда стал побыстрее, но по прежнему занимает больше места на диске. Появился движок Toku с компрессией данных (и их уже купила Percona), но утилита бэкапа для него платная.
Sign up to leave a comment.

Articles