Comments 49
UFO just landed and posted this here
Репликация идет в один поток и slave будет отставать от мастера
тут палка о двух концах:
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)
1. заблокировать бд и получить скорее мёртвое, чем живое приложение
2. отцепить от репликации слейва и снять дамп с актуальностью «10 минут назад»
в зависимости от условий выбирается одно из решений.
что не так? :-)
В смылсе? На совсем хай-лоаде может и будет, при штатных нагрузках — не отстает.
Тем более в 5.1 есть row-based репликация.
Тем более в 5.1 есть row-based репликация.
У меня mysqldump почему-то из-под крона не желает исполнятся. Уже голову себе всю сломал :(
mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log
Причем руками все работает ок…
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
/usr/local/bin/mysqldump --user=юзернейм --default-character-set=cp1251 --password='пасс' датабейз-нейм > file.log
Никаких сообщений в логе крона не появлялось. Прописал полный путь — посмотрим.
Спасибо за помощь.
Спасибо за помощь.
Раз уж сказали про репликацию и LVM хорошо было бы упомянуть drbd и кластеры.
А так заметка в самый раз.
А так заметка в самый раз.
UFO just landed and posted this here
> LVM — дополнительный слой между файловой системой и самым жестким диском
А на основании чего проводится ранжирование дисков по жесткости? ;)
А на основании чего проводится ранжирование дисков по жесткости? ;)
Не знаю как сейчас, но раньше mysqlhotcopy был платным инструментом.
ЕДИНСТВЕННЫЙ вариант на самом деле «горячего» бекапа это реплика и снятие бекапа с нее. Любые другие методы либо требуют блокировки таблиц (а вы побекапте 4-5 миллионов строк с блокировкой, время ощутимое), либо не гарантируют целостности. Говорить о бекапе через LVM это приблизительно то же самое что о бекапе через RAID или Norton Ghost.
На самом деле — в случае если у вас таблицы, не поддерживающие транзакции(MyISAM тот же), даже используя реплику вы можете остановить slave в неподходящее время и оставить какую-нибудь запись без связки с другой таблицей. Я это к тому, что очень многое зависит от реализации конкретно взятого сервера.
В то же время, например в случае с маленьким форумом у вас вероятнее всего ничего не случится если вы поймаете момент минимальной нагрузки на сервер. С действительно большими базами такой фокус не прокатит, да — к слову, я об этом писал. Думаю, по аналогии с первым пунктом, люди поймут, чем грозит блокировка живой базы.
Касательно RAID`а — сама по себе избыточность данных не спасает от главного момента(про который я уже говорил) — когда кто-то с похмелья выполняет на сервере DROP. RAID в этом случае покорно снесёт файлы со всех дисков, входящих в том. LVM же здесь упоминается именно из-за возможности налету сделать дамп раздела
В то же время, например в случае с маленьким форумом у вас вероятнее всего ничего не случится если вы поймаете момент минимальной нагрузки на сервер. С действительно большими базами такой фокус не прокатит, да — к слову, я об этом писал. Думаю, по аналогии с первым пунктом, люди поймут, чем грозит блокировка живой базы.
Касательно RAID`а — сама по себе избыточность данных не спасает от главного момента(про который я уже говорил) — когда кто-то с похмелья выполняет на сервере DROP. RAID в этом случае покорно снесёт файлы со всех дисков, входящих в том. LVM же здесь упоминается именно из-за возможности налету сделать дамп раздела
а вам не кажется, что термин «на лету» и «горячий бекап» подразумевает бекап без какого-либо влияния на сервер? т.е. никаких flush, lock etc.
Бэкап при помощи LVM занимает считанные секунды (а иногда и считанные миллисекунды). По сравнению с репликацией он имеет то преимущество, что не ломается без конца (а репликация — конструкция достаточно шаткая) и не требует отдельной машины (и почти не требует ресурсов). Вот примерная последовательность команд:
mysql: flush (5-10 секунд, не блокирует ничего, так что не считается)
— mysql: lock (мгновенно)
mysql: flush (меньше секунды)
lvm: сделать snapshot (меньше секунды)
mysql: unlock (мгновенно)
lvm: отпустить snapshot
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 ни разу, просто думаю что на таком объеме это не миллисекунды.
14.1G.
я честно говоря не делал lvcreate --snapshot ни разу, просто думаю что на таком объеме это не миллисекунды.
Насколько я понимаю, операция создания снапшота в него ничего не записывает. Это просто указание системе «начиная с этого момента все данные записывай, пожалуйста, не на основной диск, а в снапшот». Поэтому создается снапшот очень быстро. Ну а flush выполняется быстро потому, что он идет почти сразу после первого (долгого) flush-а.
Каким образом подбирается размер снапшота?
Обязательно ли он должен быть таким же размером как и база?
Обязательно ли он должен быть таким же размером как и база?
UFO just landed and posted this here
В статье обойдён вниманием самый интересный вариант бэкапа — инкрементальный. Базу в несколько гигабайт никакими методами быстро не пробэкапить, да и хранить полные копии сложно. Возможно, поможет какое-то средство типа использования бинарных логов (если есть транзакции) или какого-то прокси типа NDB или mysqlproxy?
ИМХО инкрементность на основе бинлога — слишком неустойчиво.
rdiff-backup.nongnu.org не спасет ли?
rdiff-backup.nongnu.org не спасет ли?
Как раз только на основе бинарных логов инкрементальное копирование и можно сделать по-настоящему, но классический mysql пообще без транзакций живёт, так что это отпадает. А вот на proxy вполне можно было бы включить журнал изменений.
rduff-backup я пробовал на маленьких базах, работает. Но если он должен найти отличия в гигабайтных файлах — это само по себе долго, если на время сравнения включать блокировку базы, то можно выйти за таймауты.
rduff-backup я пробовал на маленьких базах, работает. Но если он должен найти отличия в гигабайтных файлах — это само по себе долго, если на время сравнения включать блокировку базы, то можно выйти за таймауты.
каким образом наличие транзакций влияет на binlog? Туда все равно (для транзакционных engines) только закоммиченые транзакции попадают.
В первом пункте все же три ключевых момента, а не два. Время выполнения операции, думаю, стоит считать важным фактором.
если размер БД не очень большой, можно попробовать Sypex Dumper
Репликация может быть и master-master.
А для особых извращенцев: master-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 не будет копировать, так что придётся наверно их в связке использовать.
Странно, почему до сих пор не сделали общую тулзу которая сразу всё умеет бекапить ;(
Но xtrabackup по-моему наоборот myisam не будет копировать, так что придётся наверно их в связке использовать.
Странно, почему до сих пор не сделали общую тулзу которая сразу всё умеет бекапить ;(
Sign up to leave a comment.
Средства создания горячих BackUp`ов MySQL