iBase.ru Forum

Здравствуйте!

Искал я искал, но не нашел ответа на следующий вопрос: можно ли с помошью резервного копирования полностью восстановить базу, все данные вплоть до момента её падения? (не исключаю что искал плохо )

Нет ли возможности сделать резервную копию только тех данных, которые были добавлены или изменены с момента последнего полного бэкапа? (те которые удалили - удалить )

Кроме того, в форумах поднимали вопрос о логах изменений в базе, но Firebird, по-моему, этого не поддерживает... Для примера могу привести MySQL, который умеет писать лог всех запросов к базе (в SQL) и отдельно лог запросов, которые модифицируют данные в базе (лог пишется как в SQL, так и в двоичном формате - по выбору администратора). Лог изменений мог бы также пригодиться для горячего копирования состояния базы на Slave-сервер, реализуя таким образом некое подобие репликации (в MySQL так и сделано).

Буду благодарен за любые ответы/советы/подсказки

Искал я искал, но не нашел ответа на следующий вопрос: можно ли с помошью резервного копирования полностью восстановить базу, все данные вплоть до момента её падения? (не исключаю что искал плохо Sad )

нет. бэкап это "снимок" базы на момент старта бэкапа.

Нет ли возможности сделать резервную копию только тех данных, которые были добавлены или изменены с момента последнего полного бэкапа? (те которые удалили - удалить )

нет, инкрементальный бэкап будет только в FB 2.0.

о логах изменений в базе, но Firebird, по-моему, этого не поддерживает... Для примера могу привести MySQL, который умеет писать лог всех запросов к базе (в SQL) и отдельно лог запросов, которые модифицируют данные в базе (лог пишется как в SQL, так и в двоичном формате - по выбору администратора). Лог изменений мог бы также пригодиться для горячего копирования состояния базы на Slave-сервер, реализуя таким образом некое подобие репликации (в MySQL так и сделано).

с точки зрения повреждения БД наивно думать что база повредится, а лог - нет. у IB/FB просто это все внутри одного файла.

kdv писал(а):

о логах изменений в базе, но Firebird, по-моему, этого не поддерживает... Для примера могу привести MySQL, который умеет писать лог всех запросов к базе (в SQL) и отдельно лог запросов, которые модифицируют данные в базе (лог пишется как в SQL, так и в двоичном формате - по выбору администратора). Лог изменений мог бы также пригодиться для горячего копирования состояния базы на Slave-сервер, реализуя таким образом некое подобие репликации (в MySQL так и сделано).

с точки зрения повреждения БД наивно думать что база повредится, а лог - нет. у IB/FB просто это все внутри одного файла.

Я имел в виду запись обращений клиентских программ к БД в журнал, для последующего разбора или проверки, в случае необходимости. Этот журнал может (должен) представлять собой отдельный файл на файловой системе (возможно, в форме SQL-запросов и вызовов процедур, или в двоичном формате, с последующим восстановлением в опять-таки тот же SQL и вызовы процедур и функций). Или бинарный лог операций над данными таблиц (вставка/обновление/удаление, к которым собственно и приводятся большинство вызовов хранимых процедур) и счетчиков (возможно еще чего-то, что нужно на полноценном "зеркале" рабочей базы).

ой, не надо только писать про журналы, логи транзакций и т.п.... лично я об этом в курсе, причем очень давно. Во-первых, если используется MySQL без транзакций, то лог - это АУДИТ. Да, аудита в IB/FB нет. Но можно сделать на триггерах (исключая select-ы). Если речь про лог транзакций, то он у IB/FB внутри БД, и в общем случае при сбоях сервера база "восстанавливается" сама-собой.

включение любых доп. логов, аудитов и т.п счетчиков резко затормозит производительность сервера, надеюсь, не надо объяснять почему. Если хочется надежности - ставьте raid 5 или Raid 1 (или shadow вместо raid 1). Если хочется аудита по модификации данных (например для репликации), то это, к сожалению, придется писать самому, на триггерах.

kdv писал(а):ой, не надо только писать про журналы, логи транзакций и т.п.... лично я об этом в курсе, причем очень давно.

Замечательно! А вывод какой? Ждать этого или не ждать? Я понимаю что неприятно слышать об успехах конкурентов, но пишу я не для того чтобы унизить Firebird или его команду разработчиков. Есть "вкусности" у конкурентов - желательно не отставать. Вот только я не понял - будет это или нет?
И, прошу отметить, я ни в коем случае не настаиваю и не требую, понимая разработчиков и сам процесс, и с большой благодарностью принимаю и использую результаты их очень нужной и такой нелёгкой работы...

kdv писал(а):Во-первых, если используется MySQL без транзакций, то лог - это АУДИТ. Да, аудита в IB/FB нет.

Возможно что и аудит, но этот "аудит" однажды помог мне восстановить базу после сбоя.

kdv писал(а):Но можно сделать на триггерах (исключая select-ы). Если речь про лог транзакций, то он у IB/FB внутри БД, и в общем случае при сбоях сервера база "восстанавливается" сама-собой.

О логе транзакций речь не идёт. Вешать триггера на таблицы - задача очень непростая. У меня таблиц больше 80, триггера нужны будут на большей их половине. Данное решение нельзя назвать подходящим, хотя бы потому, что такая проблема возникает не у одного меня...

kdv писал(а):включение любых доп. логов, аудитов и т.п счетчиков резко затормозит производительность сервера, надеюсь, не надо объяснять почему.

Резко затормозит? Хм... Во сколько раз? Не думаю что процедура добавления (если я не ошибаюсь - реализована в системном вызове ядра) в еще один файл так сильно скажется на производительности сервера... Вот дополнительные счетчики и различная статистика - тут Вам виднее.

kdv писал(а):Если хочется надежности - ставьте raid 5 или Raid 1 (или shadow вместо raid 1).

Raid5 и так стоит, но при сбоях на файловой системе это не поможет. Тогда-то и прийдёт на помощь лог с другого раздела диска

kdv писал(а):Если хочется аудита по модификации данных (например для репликации), то это, к сожалению, придется писать самому, на триггерах.

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

В планах есть REDO-лог для point-in-time recovery и аудит вызовов API (по сути лог SQL-запросов). Но в FB2 этого не будет.

Отличные планы - перспективное будущее! Жаль что это будет не сразу во второй версии...