Firebird + журналируемая ФС

[iSerge]

Ищу способы как минимизировать вероятность порчи структур файла БД в результате аварийной остановки сервера (например, отключения питания).

С порчей структур файловой системы призваны бороться журналируемые ФС и они более менее с задачей справляются. Но они не могут справиться с порчей структур файлов если в момент фиксации транзации ФС файлы не были в корректном состоянии. Приложение, которое знает об особенностях работы журналируемых ФС, могло бы управлять записью таким образом, чтобы после аварии не пришлось бы чинить сруктуры файлов. Умеет ли Firebird как-то пользоваться расширенными возможностями ФС? Я не хочу чего-то невозможного?

PS. Я знаю про forced writes, но насколько я могу судить это несколько отличается от того, что я хочу.

[hvlad]

Умеет ли Firebird как-то пользоваться расширенными возможностями ФС?

Нет

Я не хочу чего-то невозможного?

Да

[iSerge]

Я не хочу чего-то невозможного?

Да

Можно попросить высказаться менее лаконично? Спасибо.

[hvlad]

Можно попросить высказаться менее лаконично? Спасибо.

Попросить-то можно
А можно я сначала спрошу - какие конкретно особенности журналируемой ФС (скажем NTFS) мог бы использовать ФБ и какие преимущества это ему даст ?
И почему FW не даёт желаемого эффекта ?

[iSerge]

Я, к сожалению, не знаком с подробностями реализаций, поэтому мои рассуждения носят скорее теоретический характер и основаны сторее на common sense, чем на реальных фактах.

какие конкретно особенности журналируемой ФС (скажем NTFS) мог бы использовать ФБ и какие преимущества это ему даст?

Транзакции. Должен же быть хоть каккойто механизм урпавления транзакциями на ФС и если такой механим есть, то должно быть можно уложить несколько дисковых операций в одну транзакцию. А если так, то возможно реализовать эффективный механизм работы с диском, который бы в случае аварий с большой вероятностью гарантировал целостность файла БД.

И почему FW не даёт желаемого эффекта?

Не исключено, что дает. Но добивается этого довольно не эффективным методом.
Грубо говоря, FW понижает вероятность получить после аварии битую БД за счет серьезного падения производительности операций записи, а мне бы хотелось достичь того же за счет потери большего куска кеша.
Я готов после аварии потратить ресурсы на восстановление данных, но меня совершенно не устраивает необходимость останова СУБД на несколько часов для прогона через backup/restore. Это актуально, например, для биллинговой системы, когда ее простой обходится значительно дороже потери небольшой части данных, которые потом почти всегда можно восстановить из других источников.

[Dimitry Sibiryakov]

Я так скажу: в свое время Лиля Козленко установила и доказала что размещение любой БД (она приводила Оракул в пример) на журналируемой ФС практически гарантирует ее порчу при сбое питания. Кроме того, это понижает ее быстродействие. Так что БД и ЖФС не дружат по определению.

[Andrew Sagulin]

Я так скажу: в свое время Лиля Козленко установила и доказала что размещение любой БД (она приводила Оракул в пример) на журналируемой ФС практически гарантирует ее порчу при сбое питания. Кроме того, это понижает ее быстродействие. Так что БД и ЖФС не дружат по определению.

А можно ссылку? Интересно было бы почитать (у меня база на NTFS лежит).

[kdv]

А можно ссылку? Интересно было бы почитать (у меня база на NTFS лежит).

ссылку уже вряд ли можно, т.к. я вот не помню, где это обсуждение было, может быть даже в fido.su.dbms. А то, что у тебя база на NTFS лежит - ну и пусть лежит.

[iSerge]

Я так скажу: в свое время Лиля Козленко установила и доказала что размещение любой БД (она приводила Оракул в пример) на журналируемой ФС практически гарантирует ее порчу при сбое питания.

Ясно. Не самый очевидный результат, но по трезвому размышлению, чего-то подобного и следовало ожидать. Я уверен, что будущее за журналируемыми ФС, а значит рано или поздно разработчикам СУБД все-таки придется учитывать их особенности.
Кстати, когда проводилось исследование, на которое вы ссылаетесь?

Кроме того, это понижает ее быстродействие.

С производительностью-то как раз все понятно - возрастают накладные расходы на поддержку структур ФС.

Так что БД и ЖФС не дружат по определению.

Пожалуй, я скорее соглашусь с утверждением, что разработчики СУБД пока не занимались использованием особенностей ЖФС, чем с утверждением, что что дружба невозможна принципиально.

Дкмаю, я получил ответ на свой вопрос: если кто-то из разработчикоив и занимался вопросом эффективного взаимодействия с современными ФС, то решил что игра не стоит свеч.

[WildSery]

Проблемы - если журнала два, один у ФС, другой у БД.
Журнал - это всё же надстройка над ФС, и если он реализован в сервере БД, а не в ФС, то какая тебе разница? К тому же любой ЖФС разрабатывается с точки зрения универсальности, а журнал конкретной БД - очень тонко заточенная штука, максимально подходящая для своей БД.

Отсюда напрашивается вывод - никаких использований ЖФС серверами БД не предвидится. По крайней мере, до каких-то существенный изменений в способах хранения информации.

[kdv]

Пожалуй, я скорее соглашусь с утверждением, что разработчики СУБД пока не занимались использованием особенностей ЖФС, чем с утверждением, что что дружба невозможна принципиально.

да можно подумать, что ЖФС только появились, а разработчики СУБД дальше своего носа не смотрят. Так?

[Dimitry Sibiryakov]

Дело было действительно в SU.DBMS, но у яндекса же найдется все. Лиля - человек серьезный и есть вероятность что это все изложено где-то в виде статьи.
По поводу использования возможностей ЖФС: ткните пальцем в МСДН где написано как использовать эти возможности в АПИ. И что-нибудь из линуксовых мануалов на ту же тему тоже было бы неплохо.

[iSerge]

Проблемы - если журнала два, один у ФС, другой у БД.
Журнал - это всё же надстройка над ФС, и если он реализован в сервере БД, а не в ФС, то какая тебе разница? К тому же любой ЖФС разрабатывается с точки зрения универсальности, а журнал конкретной БД - очень тонко заточенная штука, максимально подходящая для своей БД.

Ну конечно же мне в общем-то все равно каким образом реализован журнал. Во-первых, Вы почему-то считаете, что general purpose это всегда очень плохо или, по крайней мере, в разы хуже специализированных решений. Вовторых, журналЫ БД и ФС призваны решать и решают разные задачи и работают на разных уровнях, так что, вообще говоря, не исключают друг друга. Проблемы начинаются когда мы отказываемся от взаимодействия и тогда вероятность конфликтов естественно возрастает.

Отсюда напрашивается вывод - никаких использований ЖФС серверами БД не предвидится. По крайней мере, до каких-то существенный изменений в способах хранения информации.

Не согласен. По-моему такое взимодействие стравнительно дешевый способ обеспечить приемлемую вероятноть получить битую БД после аварии.

Не исключено, что я пытаюсь подойти к решению не с ой стороны.
Для меня важно, чтобы после аварии мне не пришлось бы терять время на починку БД, а можно было бы сразу продолжать работу. При этом я готов смириться с потерей данных из всех незавершенных транзакций. И мне бы не хотелось бы при этом серьезно жертвовать производительностью записи в БД. Можно тут что-то сделать?

[Merlin]

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

Да.

1. Поставить UPS.
2. Понять что такое Forced Writes. То есть разобраться, а не на слух.
3. Прийти к выводу, что в общем случае при FW On оно и есть так, как ты хочешь. А если оно не так, и причина повреждения именно в отключении питания, то дело в недобитых багах. Которые и надо искать и фиксить, а не маяться фигнёй.

[iSerge]

Пожалуй, я скорее соглашусь с утверждением, что разработчики СУБД пока не занимались использованием особенностей ЖФС, чем с утверждением, что что дружба невозможна принципиально.

да можно подумать, что ЖФС только появились, а разработчики СУБД дальше своего носа не смотрят. Так?

Я бы не стал высказываться так категорично, но что-то такое напрашивается.
ЖФС как класс появились уже давно, а вот в массы пошли сравнительно недавно. Я уверен в том, что среди людей приложивших свои мозг и руки с коду firebird найдется хотябы один человек, который не знает что, например, NTFS это журналируемая ФС.
Просто если вопрос использования ЖФС как-то был решен, то, наверное, кто-то может развернуто, прредложений на 20-30, рассказать какое было принято решение и почему.

[Andrew Sagulin]

... может быть даже в fido.su.dbms.

Само сообщение не нашёл - только последующее обсуждение.
В двух словах (как я понял): если между тем, как приложение запросило увеличение размера файла и получило Ok от WinAPI, и тем, как драйвер NTFS полностью зафиксировал изменения на диске, сделать Reset, то размер файла может не измениться, а все добавленные данные потеряются. При следующей загрузке СУБД "будет думать", что файл увеличился, а на самом деле это не так, и... "а пацаны-то не знают".

[iSerge]

2. Понять что такое Forced Writes. То есть разобраться, а не на слух.

Пока все что я нашел про FW - это утверждение что FW ON отключает кэш измененных страниц и таким образом все вносимые изменения БД сразу попадают на диск, а так же что включение этой опци приводит к серьезному падению производительности записи в БД. Последнее меня не устраивает.

Поделитесь, пожалуйста, ссылочкой на материал где можно почитать поподробнее. Спасибо.

3. Прийти к выводу, что в общем случае при FW On оно и есть так, как ты хочешь. А если оно не так, и причина повреждения именно в отключении питания, то дело в недобитых багах. Которые и надо искать и фиксить, а не маяться фигнёй.

Увы, я пока не осознал, что то, о чем я говорю, это фигня. Не реализовано - да.

А кроме FW еще что-нибудь?

[WildSery]

Во-первых, Вы почему-то считаете, что general purpose это всегда очень плохо или, по крайней мере, в разы хуже специализированных решений.

Я не сказал, что плохо. Возможно, оно как гоночный болид по скорости и такой же красивый. Но нам нужен велосипед, чтобы проехать по тропке в лесу.

Вовторых, журналЫ БД и ФС призваны решать и решают разные задачи и работают на разных уровнях, так что, вообще говоря, не исключают друг друга.

ИМХО, это как копать тоннель с двух сторон горы. Задачи разные, у одних с севера на юг надо, у других с юга на север. Хорошо, если встретятся. Ещё лучше, если расхождение будет в несколько сантиметров. А так - два тоннеля. Один general purpose, автострада многополосная, а второй - для проезда трамвайчика, с рельсами, который и нужен был серверу.

Отсюда напрашивается вывод - никаких использований ЖФС серверами БД не предвидится. По крайней мере, до каких-то существенный изменений в способах хранения информации.

Не согласен. По-моему такое взимодействие стравнительно дешевый способ обеспечить приемлемую вероятноть получить битую БД после аварии.

Дык вроде ж о том и речь? Что результат "взаимодействия" - битая база

[kdv]

Просто если вопрос использования ЖФС как-то был решен, то, наверное, кто-то может развернуто, прредложений на 20-30, рассказать какое было принято решение и почему.

гм. "Вот в системе есть АБЦ. А вы ее не используете. Ну почему, почему, почему? я сам не в курсе тонкостей АБЦ, но считаю эту штуку очень полезной - ведь зачем-то же ее сделали? а разработчики ваши, очевидно, среднего ума, раз не используют АБЦ"

http://www.testline.ru/info/articles_fi ... _ntfs.html

[Dimitry Sibiryakov]

включение этой опци приводит к серьезному падению производительности записи в БД. Последнее меня не устраивает.

Точнее было бы сказать "выключение этой опции приводит к некоторому повышению производительности записи". На какой именно операции ты получил неустраивающую тебя производительность? И какой была это производительность?
А вцелом ты прав: все тобой доселе сказанное действительно фигня.