Mysql Дамп больших баз данных

[sage]

Здравствуйте. Есть база 21.3 Гб. Дамп делается mysqldump -q. В течение дампа сайт становится недоступен: "504 Gateway Time-out" Как правильно организовать дамп больших баз? Спасибо.

 

[флоппик]

Ошибка 504 Gateway timeout - это не ошибка MySQL.

 

[sage]

Да, я понимаю. Но является следствием дампа базы. Вот мне и интересно, как организуются дампы больших баз, где подобные простои невозможны. Ставят заглушку на время дампа или что делают?

 

[флоппик]

То есть, даже после этого сообщения, мысли посмотреть на поведение и ошибки мускула в таком состоянии тебе не пришло?

 

[sage]

Нет. А на что там смотреть? Как я понимаю, дамп блокирует таблицы. Клиенты висят в очереди, апач не возвращает вовремя ответ, на что nginx выбрасывает 504. Что-то неправильно понимаю? На что надо обратить внимание при просмотре лога?

 

[флоппик]

понятно

 

[sage]

Удивляют такие личности) Ни на один из поставленных вопросов не ответил, зато вилами по воде поводил) Обо всём и ни о чём.

 

[Redjik]

http://stackoverflow.com/questions/104612/run-mysqldump-without-locking-tables
первый ответ в гугле не mysqldump without locking

 

[sage]

решение корявое, по сути, т.к. нарушается целостность данных. Сейчас все таблицы в MyISAM. Вариантом вижу перегон всех таблиц в InnoDB и снятие hotcopy с помощью http://www.percona.com/doc/percona-xtrabackup/2.1/xtrabackup_bin/creating_a_backup.html

 

[Redjik]

Посмотри тут тогда http://2013.devconf.ru/data/2013/presentation/12.pdf

 

[fixxxer]

Самое простое и универсальное решение - снимать дамп со слейва. Это хорошо работает в любых условиях, с любым engine.

 

[Вурдалак]

Я бы даже сказал, что это единственное нормальное решение без даунтайма и с сохранением целостности БД.

 

[Dovg]

Есть мнение, что дамп снятый со слейва не всегда соответствует реальности.

 

[c0dex]

Dovg, ну ведь есть ситуации, когда отставание от мастера не столь критично?

 

[fixxxer]

Обычно отставание на несколько минут не имеет значения, все равно дампы посуточные или вроде того. А роль почти-realtime-снимка выполняет сам слейв (на случай, если мастер сдох).
А неестественно сильное отставание - это ненормально, это предмет мониторинга тем же nagios/zabbix.

 

[sage]

Всем спасибо за ответы. Ещё вопрос возник. Допустим, у нас есть связка мастер-слейв. Дамп снимается со слейва. Пусть на мастере происходят какие-то изменения. Что происходит с этими изменениями на слейве? Находятся в ожидании до тех пор, пока не закончится дамп, а потом разом вносятся?

Почитал тут про инкрементный бэкап. Как вы к нему относитесь? Например, раз в неделю делаем полный, а каждый день - инкрементный.

 

[Вурдалак]

Для бекапа слейв приостанавливает работу, после — нагоняет изменения из мастера.

 

[sage]

Спасибо. А должны ли мастер и слейв быть одной конфигурации? Или, в принципе, слейв может быть послабее мастера?

 

[c0dex]

Может быть, главное, чтобы из-за слабости не отставал)

 

[grigori]

Есть мнение, что дамп снятый со слейва не всегда соответствует реальности.

да, при активных апдейтах дамп запросто получается неконсистентным, решали через SHOW SLAVE STATUS в транзакции, можно даже SERIALIZABLE включить,
или подождать когда слейв догонит до начала транзакции, или с выборкой по полю last_updated