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