Бэкап базы zabbix

М.б. разнести заббикс-сервер и сервер баз данных на разные машины?

Нет у меня разных машин, нищебродствуем.

Как правильно бекапить zabbix?

Вернее сказать как правильно бекапить mysql? Наиболее действенный вариант, поднимать slave mysql, затем : останавливать репликацию, mysqldump, восстанавливаем репликацию

Как правильно бекапить zabbix?

Надо глянуть, что утилизируется при бэкапе, отсюда и плясать.

P.S.: К примеру, zabbix должен активно использовать диск. Если Вы на него же льете бэкап то может просесть, но врядли триггеры активируются. Дело в сети, вся утилизируется пока бэкап льется куда-то.

1. А зачем вручную останавливать репликацию? При дампе возникнет рассинхрон, который сам восстановится, когда mysqldump перестанет работать.

2. Учитывая, что речь идёт о базе заббикса, где данные только добавляются (а на старые нам пофиг), при наличии слев ноды можно обойтись без бэкапа.

как вариант:

1. лочим таблицы в БД

2. sync

3. Замораживаем ФС (fsfreeze)

4. Снимаем снапшот средствами LVM (я надеюсь, что вы его используете)

Далее в обратном порядке - размораживаем ФС, разлочиваем таблицы в БД.

После этого можно спокойно примонтировать LVM-снапшот и сделать бакап файлов БД.

mysqldump как правило лочит базы на время работы. Утилизация сети не причем.

Сначала выясни, что у тебя проседает при бекапе: сеть, диск, процессор?

mysqldump как правило лочит базы на время работы.

Спорит не буду. А это приведет к срабатыванию триггеров в zabbix?

1. Ну если так, тогда хорошо. Раньше читал что нужно принудительно вырубать во избежание.

2. Система мониторинга она в том числе нужна что бы в случае чего глянуть что там было раньше. А слейв, да еще на той же машине что и master, в качестве замены бэкапа imxo никак

триггер срабатывает на основе поступаемых данных. Поступаемые данные это insert/update в базу. База залочена. Фейл

А речь о недоступности серверов ... ну тогда по идее да. С точки зрения zabbix вот уже 9ть минут в базе нет сведений о пинге с сервера. Вот он и делает вывод что сервер недоступен

триггер срабатывает на основе поступаемых данных. Поступаемые данные это insert/update в базу. База залочена. Фейл

База залочена, логика не должна выполняться вовсе. Сомневаюсь. Нужен эксперимент.

1. На время бэкапа настрой обслуживание. Хоть и немного неправильное решение.
2. Можно настроить в это время сбор данных реже (например, не раз в минуту item, а реже)
3. Узнать слабое место в сервере и исправить (диск, цп, озу, сеть).
4. Сделай отдельный zabbix прокси. Пускай прокси собирает инфу, а заббикс сервер только обрабатывает.
5. Percona XtraBackup попробуй. По идее нагрузка меньше, чем mysqldump (так говорят на форумах заббикса)

База может быть залочена для insert/update, но не для select

База может быть залочена для insert/update, но не для select

Тогда соглашусь с Вами. И это скорее всего, невозможность insert/updat, можно в логах zabbix разглядеть.

ТС поднимаешь master - client репликацию mysql и на клиенте уже делаешь дамп. и все будет збс.

как вариант:
1. лочим таблицы в БД
2. sync
3. Замораживаем ФС (fsfreeze)
4. Снимаем снапшот средствами LVM (я надеюсь, что вы его используете)
Далее в обратном порядке - размораживаем ФС, разлочиваем таблицы в БД.
После этого можно спокойно примонтировать LVM-снапшот и сделать бакап файлов БД.

И выхватываем нерабочую базу.

Система мониторинга она в том числе нужна что бы в случае чего глянуть что там было раньше.

Как правило разбор полётов происходит сразу после инцендента. Свежие данные и так есть на слейве. Исторические данные полугодовой давности не нужны.

Гм. А в каком месте она поломается? Мне серьёзно интересно, возможно, я чего-то не учёл. Однако отмечу, что подобным способом бакапил пару не слишком нагруженных БД (где исторически не сложилось слейва) и всегда бакапы разворачивались нормально.

Мне, к сожалению, не на чем делать заббикс-прокси и mysql репликацию.

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

Во время дампа так же срабатывает триггер:

CPU iowait time (server.domain.ru:system.cpu.util[,iowait]): 63.31 % 

Но он срабатывает в обоих случаях; и при бекапе на сетевое хранилище и при бекапе на локальный рейд.

Что можно сделать в такой ситуации?

CPU iowait time

У тебя машина старая и проц ложится под потолок в момент создания дампа. нормально это =)

Мне, к сожалению, не на чем делать заббикс-прокси и mysql репликацию.

Бюджетная контора? или дома балуешься?

Мне серьёзно интересно, возможно, я чего-то не учёл.

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

У тебя машина старая и проц ложится под потолок в момент создания дампа. нормально это =)

Мне кажется, что этот триггер говорит о том, что проц ожидает системы ввода\вывода. Т.е. проседает не проц, а nas или рейд во втором варианте.

Бюджетная контора? или дома балуешься?

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

то для более важных целей.

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

А еще лучше сделай Xen виртуализацию и туда засунь заббикс.

mysqldump --single-transaction

При использовании этой опции триггеры не срабатывают.

Я не силен в mysql. Погуглил, понял только, что база не блокируется в таком случае. Но чем это грозит? Смогу я обычным методом восстановить дамп сделанный таким образом? Или быть может понадобится какой-нибудь бубен?

При использовании этой опции триггеры не срабатывают.

Какие триггеры?

Я не силен в mysql. Погуглил, понял только, что база не блокируется в таком случае. Но чем это грозит?

Ничем. Почитай про транзакции в СУБД.

Спасибо тебе, добрый человек!

Можно ещё попробовать Xtrabackup, если данные в InnoDB-табличках:

http://www.percona.com/software/percona-xtrabackup

Сливай БД на реплику и бекап делай с неё.

Дофигашечки способов как это сделать, и все рабочие.

В любом случае попробуй сделать дамп без блокировок таблиц ( http://stackoverflow.com/questions/104612/run-mysqldump-without-locking-tables ). И перед командой дампа используй ionice и nice.

А вообще предложили самый красывый способ уже, скриптом регистируй период обслуживания в заббиксе для всех узлов сети, затем стопари сервер, меняй настройки в специальном таком файлике (имя забыл) чтобы на экране отображалась табличка с уведомлением об обслуживании заббикса. После бэкапа базы вертай всё нназад.

Именно поэтому для продакшна используется заранее оговоренная версия СУБД. Переход с версии на версию должен предварительно тестироваться и проводиться отдельно, и уж точно не в момент восстановления из бекапа.

Ничем. Почитай про транзакции в СУБД.

Только если базы на InnoDB

--single-transaction 

 This option sets the transaction isolation mode to REPEATABLE READ and sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time when START TRANSACTION was issued without blocking any applications. 

 When using this option, you should keep in mind that only InnoDB tables are dumped in a consistent state. For example, any MyISAM or MEMORY tables dumped while using this option may still change state.

Да, в zabbix по умолчанию InnoDB.