Теоретический вопрос по Backup/Restore

Ремонт и восстановление баз данных InterBase, Firebird, Yaffil

Модераторы: kdv, Alexey Kovyazin

Ответить
galaober
Сообщения: 4
Зарегистрирован: 11 апр 2005, 12:16

Теоретический вопрос по Backup/Restore

Сообщение galaober » 11 апр 2005, 14:57

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

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

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

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

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 11 апр 2005, 15:27

Искал я искал, но не нашел ответа на следующий вопрос: можно ли с помошью резервного копирования полностью восстановить базу, все данные вплоть до момента её падения? (не исключаю что искал плохо Sad )
нет. бэкап это "снимок" базы на момент старта бэкапа.
Нет ли возможности сделать резервную копию только тех данных, которые были добавлены или изменены с момента последнего полного бэкапа? (те которые удалили - удалить )
нет, инкрементальный бэкап будет только в FB 2.0.
о логах изменений в базе, но Firebird, по-моему, этого не поддерживает... Для примера могу привести MySQL, который умеет писать лог всех запросов к базе (в SQL) и отдельно лог запросов, которые модифицируют данные в базе (лог пишется как в SQL, так и в двоичном формате - по выбору администратора). Лог изменений мог бы также пригодиться для горячего копирования состояния базы на Slave-сервер, реализуя таким образом некое подобие репликации (в MySQL так и сделано).
с точки зрения повреждения БД наивно думать что база повредится, а лог - нет. у IB/FB просто это все внутри одного файла.

galaober
Сообщения: 4
Зарегистрирован: 11 апр 2005, 12:16

Сообщение galaober » 11 апр 2005, 15:56

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

kdv
Forum Admin
Сообщения: 6595
Зарегистрирован: 25 окт 2004, 18:07

Сообщение kdv » 11 апр 2005, 17:06

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

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

galaober
Сообщения: 4
Зарегистрирован: 11 апр 2005, 12:16

Сообщение galaober » 11 апр 2005, 19:03

kdv писал(а):ой, не надо только писать про журналы, логи транзакций и т.п.... лично я об этом в курсе, причем очень давно.
Замечательно! А вывод какой? Ждать этого или не ждать? Я понимаю что неприятно слышать об успехах конкурентов, но пишу я не для того чтобы унизить Firebird или его команду разработчиков. Есть "вкусности" у конкурентов - желательно не отставать. Вот только я не понял - будет это или нет?
И, прошу отметить, я ни в коем случае не настаиваю и не требую, понимая разработчиков и сам процесс, и с большой благодарностью принимаю и использую результаты их очень нужной и такой нелёгкой работы... :)
kdv писал(а):Во-первых, если используется MySQL без транзакций, то лог - это АУДИТ. Да, аудита в IB/FB нет.
Возможно что и аудит, но этот "аудит" однажды помог мне восстановить базу после сбоя.
kdv писал(а):Но можно сделать на триггерах (исключая select-ы). Если речь про лог транзакций, то он у IB/FB внутри БД, и в общем случае при сбоях сервера база "восстанавливается" сама-собой.
О логе транзакций речь не идёт. Вешать триггера на таблицы - задача очень непростая. У меня таблиц больше 80, триггера нужны будут на большей их половине. Данное решение нельзя назвать подходящим, хотя бы потому, что такая проблема возникает не у одного меня...
kdv писал(а):включение любых доп. логов, аудитов и т.п счетчиков резко затормозит производительность сервера, надеюсь, не надо объяснять почему.
Резко затормозит? Хм... Во сколько раз? Не думаю что процедура добавления (если я не ошибаюсь - реализована в системном вызове ядра) в еще один файл так сильно скажется на производительности сервера... Вот дополнительные счетчики и различная статистика - тут Вам виднее. :)
kdv писал(а):Если хочется надежности - ставьте raid 5 или Raid 1 (или shadow вместо raid 1).
Raid5 и так стоит, но при сбоях на файловой системе это не поможет. Тогда-то и прийдёт на помощь лог с другого раздела диска :)
kdv писал(а):Если хочется аудита по модификации данных (например для репликации), то это, к сожалению, придется писать самому, на триггерах.
Жаль, очень жаль... Потому как не одного меня это беспокоит :( Да и вообще отсутствие подобных логов сдерживает использование данной СУБД в серьёзных (ответственных, критичных к вопросам изменения информации и доступу к базе) проектах :(((
А как в будущих версиях, это планируется? Если да, то когда, хотя бы приблизительно, это будет?

dimitr
Разработчик Firebird
Сообщения: 888
Зарегистрирован: 26 окт 2004, 16:20

Сообщение dimitr » 11 апр 2005, 21:24

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

galaober
Сообщения: 4
Зарегистрирован: 11 апр 2005, 12:16

Сообщение galaober » 11 апр 2005, 22:20

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

Ответить