Добрый день.
Начитавшись страшилок из офф.документации и случаев из жизни стал вопрос: как грамотно организовать регулярный бекап реплицируемой базы?
"Бин-лог и репликации - Для репликации "mysqldump" не предназначена, для этого есть бин-лог (--log-bin)"
и наоборот:
"1. Восстановление из бинлогов возможно только тогда, когда они велись с самого начала. Либо если есть слепок первоначального состояния базы данных, после которого начали вестись логи.
2. На нагруженных серверах бинлоги быстро убивают пространство на диске, поэтому их хранят не все, а некоторое количество последних. Предыдущие же либо пакуются, либо вовсе удаляются. Понятно, что в последнем случае восстановить ничего не удастся.
3. Еще одно назначение бинлогов — репликация. Если есть реплика, безусловно легче восстановить данные с нее, чем из бинлогов."
И еще 1000 и 1 мнений обо всём, но не о конкретном: как мне на реплицируемой базе (по одному мастеру и слейву) корректно сделать dump.sql?!
Его нужно делать на слейве, или на мастере? Если на мастере, то останавливая репликацию, или "на живую"?
суть - хочу иметь под боком "свежий" архив, готовый в любой момент к


Как грамотно организовывается такая задача? Если у кого-то есть ссылка на соответствующую статью - буду признателен! Пока что только планирую настроить и развернуть проксирование с репликацией, собираю рецепты и "хорошие практики"! ))

Скучные вы тут какие-то... Ok, попробую "оживить": наткнулся на просторах на рекомендации/советы по поднятию Percona XtraDB Cluster.
Говорят в её состав входит xtrabackup, который как раз умеет корректно делать dump без остановки баз... но там же говорят, что жутко страдает скорость UPDATE/INSERT-ов...

Кто пользуется: поделитесь пож., реальными отзывами (в особенности ошибко-багами, с которыми столкнулись пи использовании)!

Тихо сам с собою - я веду беседу...
Кластер это хорошо, но дорого. В наших реалиях, учитывая что "общая скорость кластера равняется скорости самой медленной его ноды" - пока что присматриваюсь к варианту "обычной" репликации в режиме Master <-> Master (Когда первый мастер 1 и он же слейв для мастера 2, и наоборот: мастер 2 является слейвом 1 для мастера 1).
Говорят, что с одной стороны эта схема достаточно жизнеспособная, а с другой - позволяет сделать на Слейве1 штатный mysqldump и прочая без остановки мастера, что и требуется по задаче...

Поделитесь: у кого какие "нештатные/малоописанные" грабли вспывали, при работе по такой схеме?

Dimitry Sibiryakov, спасибо - не знал!
У меня много как раз частых обновлений данных, поэтому даже с Вашим уточнением кластер мне не подойдёт ("сервера" очень разные по параметрам - есть 1 "большой и умный" и группа простых и примитивных VPS'ов).
Хочу "размазать" тонким слоем реплики по хостингам с тем, что бы пока мастер1 "жив" - вообще все запросы шли только на него, в то же время когда он упадёт (редко, но бывает) - что бы хостинги смогли "подхватить" и пусть с потерей в производительности, но продолжить раздачу контента.
Объединить это в кластер, значит потерять весь профит от умного сервера на всех операциях вставки и апдейта, а у меня таких каждые 10 минут по по тысяча-пиццот на разных проектах одновременно.
Собственно - из-за них и затеяли добавление одного выделенного сервера под базы, но тут же захотелось не только скорости, а еще и резервирования... ))