Jump to content
Калькуляторы

Backup базы UTM5

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

Ilya Evseev

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

Edited by mousus

Share this post


Link to post
Share on other sites
по результатам гугления еще появилась идея настроить на 2 серверах с базой данных master-slave репликацию и лить бэкапы уже со slave -- кто-нибудь такое делал и насколько это жизнеспособно?
Когда-то давно пробовали, отказались. Master-копия пишет данные в журнал репликации.

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

 

сейчас база лежит на зеркале zfs под 10 солярисом
Наверное, можно сделать снимок ФС и архивировать уже его.

Share this post


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

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

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

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

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

 

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

 

 

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

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

Edited by Dyr

Share this post


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

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

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

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

Share this post


Link to post
Share on other sites

Dyr

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

 

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

 

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

Share this post


Link to post
Share on other sites
кстати на тему моментальных снимков --- идея хороша, кто-нибудь такое делал?
Ищем в Гугле: "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

Share this post


Link to post
Share on other sites
Ну, собственно, ты её и делал, а я занимался настройкой ежедневного резервирования.
"Падла...падла...падлавил" (с) КВН :)

Не было у нас 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

 

Share this post


Link to post
Share on other sites

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

Share this post


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

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

 

Share this post


Link to post
Share on other sites
Сейчас также УТМ5 или что-то другое ?
utm4 с шестью вагонами костылей и внутренними патчами.

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

Edited by Ilya Evseev

Share this post


Link to post
Share on other sites

Stranix1979

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

 

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

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

 

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

 

FLUSH TABLES ;

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

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

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

 

Share this post


Link to post
Share on other sites
Mysqlhotcopy не работает для InnoDB-таблиц, как известно.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this