У кого есть проблемы с nbackup?

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

Gallemar,

судя по предыдущим сообщениям, вашим база имеет размер 160 Гб, так ?
Если да, то примите соболезнования: в рабочее время будут красивые тормоза. Ибо при каждом запуске nbackup будет просматривать ВСЮ базу полностью, все 160 гигов, даже если в ней изменилось всего 100 страниц.
Кроме того, у мну в одном тесте был прецедент, когда nbackup заваливал индексы в базе (при числе активно пишущих коннектов ~10). Но воспроизвести это затем не удалось, так что "не пойман - не вор".

Поэтому задумайтесь о двух вариантах:
1) shadow, причем продакшен в этом случае можно делать с FW = OFF, оставив FW = ON на его тени. Достоинство варианта: минимальное время простоя при сбое базы; недостаток: если в файле продакшена возникнет "нехорошая страница", она тут же окажется и в файле тени
2) репликация, при которой на продакшене оставляем FW = ON, на реплике - FW = OFF, т.к. в неё пишет только один процесс. Реплику регулярно проверяем валидацией (через nbackup -L, затем делаем файловую копию, затем nbackup -N и наконец gfix -v -full созданной файловой копии). Достоинство варианта: файл базы реплики практически никогда не разрушается, т.к. в него пишет только один процесс. Недостатки: а) реплика отстаёт от реальности на время от нескольких секунд до минут; б) нужны некие танцы с бубном для того, чтобы репликатор считал попытку нарушения PK/UK при записи в реплику ошибкой и откатывал всю транзакцию, а не разруливаемым конфликтом и галантным обходом "проблемных позиций"; в) нужны еще более серьёзные танцы с бубном для синхронизации метаданных (прежде всего - генераторов, но с ними вроде уже нет такой проблемы в IBPhoenix-репликаторе). То есть, при репликации продакшена изменения в его метаданных следует делать крайне осторожно и продумать механизм дублирования их в реплику.

Таблоид,проблемы с тормозами были,но решились запуском с ключом -d off. Бэкап нулевого и первого делаем ночью,думаем насчет второго в течении дня.

Gallemar
Таблоид,проблемы с тормозами были,но решились запуском с ключом -d off. Бэкап нулевого и первого делаем ночью,думаем насчет второго в течении дня.

Да какой бы уровень вы не делали, nbackup всё равно будет шерстить ВЕСЬ файл. И еще: вы задумывались над тем, что будет твориться на предприятии, когда ваша БД помрёт и надо будет ресторить эти самые 160 Гб с энбекапного хранилища ? Тестовый обвал с замером времени до запуска отресторенной базы - делали ?

Таблоид,делал, в пределах часа восстановление 0+1. Первого уровня накопление за день.

Таблоид,вопрос - заваливание индексом было во время бэкапа или рестора? Если бэкапа то какого уровня? Если 1-2 то какой временной интервал выбирался?

Gallemar,

ну, раз всё так быстро ресторится - пробуйте тогда внедрять его. Только не снимайте FW = ON с продакшена. И всё-таки раз в сутки делайте полный ("обычный") backup. Так, на всякий...

Gallemar
Таблоид,вопрос - заваливание индексом было во время бэкапа или рестора? Если бэкапа то какого уровня? Если 1-2 то какой временной интервал выбирался?

Было не "заваливание индексом" (), а разрушение индекса.
Есть такая зловещая ошибка, которая называется missing entries. Когда она возникает, агрегирование (count(*), sum(*) etc) натуралом и по индексу даёт разные результаты (по индексу - всегда меньше).
Когда nbackup заканчивался, вводился "сигнал" остановки теста, при этом все окошки дружно прекращали свою работу. Дальше делалась валидация - и вот она как раз выдавала примерно в 60-70% случаев эту ошибку.
Это было, ЕМНИП, в сентябре 2010. Когда я захотел воспроизвести её через полгода на тогдашнем свежем снапшоте, то сделать это уже не смог.

Таблоид
Дальше делалась валидация - и вот она как раз выдавала примерно в 60-70% случаев эту ошибку.

то есть, индекс бился когда запись шла в дельту?

kdv,

он просто бился, пофиг куда шла запись :-) Влад еще тогда сказал, что к бекапу это отношения не имеет, просто карта так легла.