Backup базы UTM5

[mousus]

Столкнулся с проблеммой при создании бэкапов базы utm5 --- при дампе базы весь биллинг встаёт колом и тормазит всё начиная с панели заканчивая радиусом. Как результат клиенты и техподдержка "просто счастливы". Сами нетаповцы в телефонном разговоре предложили останавливать биллинг на момент снятия резервных копий, что по понятным причинам неприемлемо. Подскажите пожалуйста кто как выкручивается в похожей ситуации?

[Ilya Evseev]

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

 

Второе. Сначала делается mysqlhotcopy на соседний диск, и уже полученная копия архивируется, копируется на резервный сервер и т.д.

[mousus]

по результатам гугления еще появилась идея настроить на 2 серверах с базой данных master-slave репликацию и лить бэкапы уже со slave -- кто-нибудь такое делал и насколько это жизнеспособно?

 

Ilya Evseev

сейчас база лежит на зеркале zfs под 10 солярисом

Edited February 24, 2010 by mousus

[Ilya Evseev]

по результатам гугления еще появилась идея настроить на 2 серверах с базой данных master-slave репликацию и лить бэкапы уже со slave -- кто-нибудь такое делал и насколько это жизнеспособно?

Когда-то давно пробовали, отказались. Master-копия пишет данные в журнал репликации.

Если slave не забирает их (например, выключен), этот журнал моментально раздувается и выедает весь диск.

 

сейчас база лежит на зеркале zfs под 10 солярисом

Наверное, можно сделать снимок ФС и архивировать уже его.

[Dyr]

Когда-то давно пробовали, отказались. Master-копия пишет данные в журнал репликации.

Если slave не забирает их (например, выключен), этот журнал моментально раздувается и выедает весь диск.

Значит, что-то вы неправильно делаете, у нас работает именно такая схема.

Более того, она наиболее правильная, поскольку позволяет а) моментально переключиться на другой сервер б) разнести операции чтения и записи на разные базы (запись на master, чтение со slave).

Кроме того, рекомендую использовать (если бекап идёт на том же сервере) пользоваться mysqldump с ключом "--tab=" и, соответственно, mysqlimport для restore, это существенно быстрее обычного дампа и, главное, restore. Mysqlhotcopy не работает для InnoDB-таблиц, как известно.

 

нетаповцы в телефонном разговоре предложили останавливать биллинг

Идиоты.

 

 

Наверное, можно сделать снимок ФС и архивировать уже его.

Сомневаюсь, хотя не пробовал.

Снимки, напомню, есть не только в ZFS, но и в UFS2.

Edited February 24, 2010 by Dyr

[Ilya Evseev]

Когда-то давно пробовали, отказались. Master-копия пишет данные в журнал репликации.

Если slave не забирает их (например, выключен), этот журнал моментально раздувается и выедает весь диск.

Значит, что-то вы неправильно делаете, у нас работает именно такая схема.

Ну, собственно, ты её и делал, а я занимался настройкой ежедневного резервирования.

[mousus]

Dyr

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

 

в принципе на тему выедания всего диска ---- там два терабайтника в зеркале, и база пока 5 гигов весит

 

кстати на тему моментальных снимков --- идея хороша, кто-нибудь такое делал?

[Ilya Evseev]

кстати на тему моментальных снимков --- идея хороша, кто-нибудь такое делал?

Ищем в Гугле: "zfs snapshot mysql backup"

 

Находим:

http://dev.mysql.com/doc/refman/5.0/en/ha-...eplication.html

http://forums.mysql.com/read.php?28,204761,204761

[Dyr]

Ну, собственно, ты её и делал, а я занимался настройкой ежедневного резервирования.

"Падла...падла...падлавил" (с) КВН :)

Не было у нас master-slave копирования, были только bin-log. Вопрос занятия всего диска решается удушением жабы начальства и покупкой нормального массива, выставлением expire_logs_days в my.cnf и исправлением дебилизма UTM с внесением ничего не значащих записей в balance_history ( посмотри, сколько там записей с gm_in=gm_out=0 ;) ).

 

mousus, у меня от "разработчиков" Netup до сих пор воспоминания с содроганием. Была у нас история, когда мы купили UTM5, имея работающих клиентов в UTM4, и попросили перевести нас с 4 на 5. Эти...гм...умельцы перекосячили БД так, что перестало работать вообще всё, кроме админского входа в интерфейс. :D

 

кстати на тему моментальных снимков --- идея хороша, кто-нибудь такое делал?

Похоже, делали: http://dev.mysql.com/doc/refman/5.0/en/ha-...eplication.html

 

[mousus]

в общем исходя из того что есть под рукой --- основной сервер БД под солярисом с zfs и более слабой машиной с freebsd в качестве slave на случай "экстерменатуса" на основном сервере можно тогда периодически делать снимки zfs (раз в день например) и жать их в архив складывая на хранение и изредка делать mysqldump со слейва например раз в неделю

[Stranix1979]

mousus, у меня от "разработчиков" Netup до сих пор воспоминания с содроганием. Была у нас история, когда мы купили UTM5, имея работающих клиентов в UTM4, и попросили перевести нас с 4 на 5. Эти...гм...умельцы перекосячили БД так, что перестало работать вообще всё, кроме админского входа в интерфейс. :D

Сейчас также УТМ5 или что-то другое ?

 

[Ilya Evseev]

Сейчас также УТМ5 или что-то другое ?

utm4 с шестью вагонами костылей и внутренними патчами.

utm5 тоже есть, поставлен с нуля на небольшую подсеть, часть костылей адаптирована.

Edited February 26, 2010 by Ilya Evseev

[mousus]

Stranix1979

да, как не прискорбно но таки УТМ5, грабли везде....

 

в общем вести с полей:

основной сервер БД ----> реплика (slave) ------> медленный сетевой клиент забирающий бэкап со slave

 

была симитирована самая поганая ситуация когда клиент лочит таблицы, то есть репликация ставится в ожидание, и очень медленно забирает данные, 5 гиговая база выливалась со слэйва в течении почти часа, после чего за считаные секунды mysql на слэйве реплицировал почти час разницы с мастером и всё продолжило работать в штатном режиме, выполнялось в 2 часа ночи, и похоже можно сделать вывод что часть проблемы решена, другая часть --- как грамотно реализовать снапшоты с zfs --- ведь не все данные mysql записывает в ФС сразу, то есть логика примерно следующая:

 

FLUSH TABLES ;

снятие снимка

архивация снимка

удаление снимка

 

[YuryD]

Mysqlhotcopy не работает для InnoDB-таблиц, как известно.

Есть innodbhotcopy, и если у вас есть hex-editor то она легко становится недемо...