Новая тема   Ответить

 DG
Объёмы от 100Gb. Если тупо делать mysqldump всех таблиц и tar всех файлов, то это занимает несколько часов, за которые сервак фактически лежит. Плюс забитый канал на время пересылки архивов в S3.

Есть ли более умные способы?

 A.Brain
Mysqldump + Incremental Backup c помощью Duplicity

Тут подробно: http://blog.damontimm.com/bash-script-incremental-encrypted-backups…amazon-s3/


ну или не заморачиваться и платить отдельному сервису за rsync backup на S3 http://www.s3rsync.com/

 Pentarh
Во-первых, надо настроить отдельный слейв mysql сервер. И делать бекап с него.

Во-вторых, mysqldump на таких объемах не эффективен. Надо лочить таблицы на запись (FLUSH TABLES WITH READ LOCK), снимать LVM-снепшот тома с таблицами, отпускать таблицы (UNLOCK TABLES). Дальше база продолжает работать, а бекапишь ты уже снапшот раздела с таблицами с помощью обычного dump.

Ну и постепенно дамп на S3 загонять. Или куда поближе.

 DG
Pentarh писал:
А на репликации не будет серьёзных потерь в производительности?
И как быть с файлами контента? rsync, csync, или что-то принципиально другое?

Спасибо за советы!

 Pentarh
Оч геморойно настроить репликацию. Особенно на таком объеме. Но проблем с производительностью на главном сервере репликация не вызовет. А на слейве пох. Пусть хоть ложится. Главное чтобы читал бинарные логи с мастера.

В принципе могу помочь не за спасибо если что.

 Pentarh
Sanman писал:
Саныч, инкрементальный бекап на таких объемах mysqldump не имеет смысла. Один и тот же контент будет копироваться в полном объеме.

А вот если дампать LVM снепшот тома обычным dump'ом, то там инкрементальный бекап (самого dump'а) в принципе может снизить нагрузку на канал.

Последний раз редактировалось: Pentarh (18/11/12 в 20:15), всего редактировалось 1 раз

 A.Brain
Pentarh: ТС же не говорил, что базы у него от 100 гиг, весь контент на сервере, как я понял Вот файлы до 5гиг( ограничение S3) отлично синкаться инкрементально смогут

Последний раз редактировалось: A.Brain (18/11/12 в 20:17), всего редактировалось 1 раз

 DG
А на "как быть с файлами контента" ничего не ответил

Ну окей, если своими руками не получится - обращусь к тебе на коммерческой основе

 Pentarh
А, еп. Я чето подумал 100 терабайт. Ну ладно. 100 гиг в принципе можно снимать mysqldump. Но со слейва.

 Pentarh
Вот тут у меня описание и скрипт бекапа со снапшота.

http://www.pentarh.com/wp/2010/08/12/mysql-remote-encrypted-backup-lvm-snapshot/

Основной гемор - настроить слейв теперь.

 DG
Залип в блоге на полчаса

Парни, ну скажите как лучше файлы бэкапить, я же теперь мучаться буду пока не узнаю рецепт. Rsync на больших объёмах нахрен нагрузит либо канал, либо проц. Как иначе?

 Pentarh
ну дампом опять же

рсинк не грузит проц, он грузит винт

 FXIX
а это. я вроде читал что при определенных обстоятельствах можно сами файлы баз бекапить. при условии что инсерт\апдейт туда не ведется в этот момент.

 DG
FXIX писал:
Это же всё равно слейв городить, на продакшене ведь их не заморозишь.

 Pentarh
FXIX писал:
Гарантию отсутствия записи и сброса кеша дает запрос "flush tables with read lock".

Потом делаем снепшот раздела с базами. Конечно же базы должны располагаться на выделенном LVM разделе.

Снепшот снимает мгновенный снимок раздела и замораживает его. Снепшот LVM раздела делается за несколько секунд.

Потом отпускаем запросы инсерт, апдейт запросом "unlock tables". Запись в базу пошла опять.

Но снятый снепшот сохранил раздел с базами в состоянии на момент снятия лока баз.

И теперь этот снепшот можно:
1) замонтировать куда то, забекапить отдельные файлы
2) снять с него бекап без монтирования утилитой dump полным или инкрементальным бекапом.

Обращаю внимание. Если бекапаются таблицы InnoDB, нужно бекапать еще и my.cnf! Т.к. там есть настройки размера и положения лог файлов инны. При других настройках в процедуре восстановления файлов, инна раскапризничается.

Последний раз редактировалось: Pentarh (18/11/12 в 22:38), всего редактировалось 1 раз

 FXIX
DG писал:

да просто настрой слейв. это и будет тебе бекап. в первый раз слейв будет медленно заливаться. потом быстрее.

слейв же тупо операционные логи мастера читает. строки вида "INSERT что-то", "DELETE что-то", "UPDATE что-то" и у себя на исполнение запускает. короче бежит за мастером.

вот раз в неделю слейв запускай да и все. и не надо со 100гиговыми дампами прыгать.

по крайней мере в мане так суть репликации описана. вживую не трогал

 Pentarh
Ну если не десятки гигабайт, можно и просто снепшотом бекапать.

Там лок таблиц включается на несколько секунд. Нагрузка на винт правда будет в процессе бекапа.

Если нагрузка на винт представляет угрозу стабильности, тогда надо городить слейв.

 iRoot
Лично я подошел с другой стороны - просто не храню миллион файлов на сервере, а заливаю их в облачное хранилище по типу S3 и никакого гемороя с резервным копированием.
А база реплицируется на другой сервер с задержкой в час и в случае если какая проблема или сам накосячил, то переключаюсь на второй сервер и все. Не спрашивайте как это, база не MySQL

 DG
iRoot писал:
А вот с этого места поподробнее. Какое именно облачное хранилише? S3 вроде не любит адалт.

 Pentarh
Мне интересно как их потом с S3 раздавать... Ну хотя бы на полтинике мегабит. Квартиру продашь нафиг )

 iRoot
DG: пока хостился там он не возразил ни разу, все было в порядке
Pentarh: а цена да, кусается. Пока трафика было мало все было супер, когда стало больше, то переехал в другое место. Но там целая история получилась - сперва нашел сервис с совместимым API, т.е. все что нужно было - это перекачать данные и поменять в настройках сервер и все. Но этот новый сервис оказался тормознутым, общение с поддержкой результата не дало, помыкался я еще немного и в итоге реализовали свое хранилище с совместимым S3 API, оказалось не сложно. Поставил это все дело на Hetzner сервера и остался очень доволен.
Предлагал даже поделиться кому надо - места полно, трафика тоже, будет мало поставлю еще сервер, система масштабируется горизонтально, но никто пока не ответил. Так что если кому надо - обращайтесь, договоримся.

 Pentarh
Чтоб цена не кусалась, надо юзать правильные цдн

 Mad
Pentarh: Советуй уж тогда правильные цдны

 DG
Вот я сейчас тестирую, насколько правильный CDN от Диамонда CDN решение для ваших сайтов. Free - тест!

 Pentarh
diamond, advanced hosters