Немедленное восстановление

[Nat]

FB 1.5.3
С b/r вопросов нет... Но как отловить момент сбоя?
Сбои можно классифицировать грубо говоря на 5 видов:
1). Несанкционированный доступ и порча по некомпетентности или намеренно (начиная с нарушения ссылочной целостности по неопытности и до полного ...)
2). Неуправляемый параллелизм(многопользовательская среда, когда одна транзакция пытается что-то модифицировать, когда другая еще не зафиксирована)
3) Локальный сбой (аварийные ситуации из-за некорректной работы программы)
4) Мягкий сбой (потеря оперативной памяти - по разным причинам, начиная со сбоя напряжения и ...)
5) Жесткий сбой(физическое разрушение носителя, процессора и т.д.)

Первые три не интересуют.

Но остальные...

а) Какие существуют механизмы у самого FB 1.5.3 по автоматическому восстановлению и доведению до логического выполнения незафиксированных транзакций при например мягком сбое и есть ли такие?

б) Как можно автоматизировать отлов события сбоя работы сервера в случае 4 и 5? Но не по таймеру, а по наступлению события. Резервная копия при этом предположим находится на другом физическом носителе.

[Nat]

Имеется в виду немедленный отлов события сбоя, чтобы тут же начать процедуру восстановления. Для пользователей, сбой и восстановление должны быть прозрачными. Есть у кого нибудь опыт или идеи. Такое решение, думаю, будет полезно всем.

[WildSery]

Физическое нарушение целостности данных БД (как раз не важно, в оперативке или на другом носителе) выяснится при обращении к данной странице сервером. Он выдаст соответствующую ошибку (зависит от ошибки), и аварийно завершится. Для классика, конечно же, аварийно завершится только напоровшийся на сбой коннект.
Смотреть в firebird.log.
"Автоматическая починка, прозрачная для ползателя" - утопия.

[Slavik]

а) Какие существуют механизмы у самого FB 1.5.3 по автоматическому восстановлению и доведению до логического выполнения незафиксированных транзакций при например мягком сбое и есть ли такие?

Нет никаких механизмов, ибо в FB нет никаких незафиксированных транзакций, т.к. нет и журнала транзакций, их порождающего... И если покопаешься в инете и почитаешь историю, то узнаешь, что Interbase был создан как раз для того, чтобы мгновенно подыматься после падения. А автоматически завершать транзакции, незавершённые самим приложением -- прямой путь к логической порче данных в базе. Это должно делать приложение.

б) Как можно автоматизировать отлов события сбоя работы сервера в случае 4 и 5? Но не по таймеру, а по наступлению события. Резервная копия при этом предположим находится на другом физическом носителе.

Для этого есть источники бесперебойного питания, RAID-контроллеры, кластеры и т.п. аппаратно-программные средства.

Пример реальной задачи с ТАКИМИ требованиями в студию!

[kdv]

пункты 1 и 2 - бред конкретный.
изучить
1. многоверсионность, транзакции
2. www.ibase.ru/devinfo/db_repair.htm

[Nat]

Спасибо за совет всем, кто ответил!
Вы правы.
Что касается падения и подъема сервера, это понятно(guard подымет). Ссылки, которые вы даете уже прочитаны ранее, но еще буду изучать более подробно.
Но как тогда быть например с денежными переводами?
Например, модификация была произведена, но фиксация была отложена(средствами ОС), в этот момент мягкий сбой.???
Если я правильно понимаю, операции снятия с одного счета и добавления к другому счету будут по правилам в теле одной транзакции. Значит при потере отложенных записей после фиксации(якобы) просто все останеться на своих местах? Или все-таки потеря возможна? Не будет ли потеряно то, что не было зафиксировано.

С FB пришлось работать только неделю назад и пока не изучен механизм поведения до конца, в процессе. Но задачу необходимо выполнить насколько возможно и по времени и по надежности.

Понятно, что 100 процентной гарантии никто не даст ни в чем, однако как другие решают такие эксессы? Как обеспечивают надежность и прозрачность для клиентов? Только с помощью железа (зеркала, кластера, блейды и т.д. и средств самых ОС)?

Случай 1, 2 рассматривать не надо. Это
непрофессионализм разработчиков в зачаточном периоде развития, который можно назвать бредом, однако он возможен и приведен здесь не для рассмотрения, а просто, как пусть самый фантастический, но все же случай (ИМХО - если смотреть на проблему системно), который неосуществим в серьезных проектах.


Зараннее спасибо!

[kdv]

Что касается падения и подъема сервера, это понятно(guard подымет).

про свойства сервисов в панели управления не в курсе?
guardian уже давно не нужен.

Например, модификация была произведена, но фиксация была
отложена(средствами ОС), в этот момент мягкий сбой.???
Если я правильно понимаю, операции снятия с одного счета и добавления к другому счету будут по правилам в теле одной транзакции. Значит при потере отложенных записей после фиксации(якобы) просто все останеться на своих местах? Или все-таки потеря возможна? Не будет ли потеряно то, что не было зафиксировано.

опять ..... читай про транзакции. если транзакция завершена commit - все сохранится. Не завершена по любой причине - ничего что было сделано в транзакции не сохранится, и не должно.

С FB пришлось работать только неделю назад и пока не изучен механизм поведения до конца, в процессе. Но задачу необходимо выполнить насколько возможно и по времени и по надежности.

при чем тут FB. транзакции везде одинаково работают.

[WildSery]

Значит при потере отложенных записей после фиксации(якобы) просто все останеться на своих местах? Или все-таки потеря возможна? Не будет ли потеряно то, что не было зафиксировано.

Возможна поломка базы, возможна. Хотя и весьма маловероятна.
В этом случае должна быть разработана схема быстрого отката на ближайший бэкап и накатывание всех последующих изменений (если конечно они импортятся роботом, должны сохраняться обязательно, и не только на случай сбоя).
Если же набиваются ползателями - тут ой. Но в критически важных данных такой схемы быть и не должно. По-любому должен быть какой-то журнал.

[Nat]

опять ..... читай про транзакции. если транзакция завершена commit - все сохранится. Не завершена по любой причине - ничего что было сделано в транзакции не сохранится, и не должно.

в случае отложенных записей все комиты в оперативке и при потере ее они также теряются, хотя отмечены (думаю в RDB$TRANSACTIOS) как зафиксированные(на самом деле при фиксации стерты с этой системной БД), а отключать хэширование, значит замедлить работу.

при чем тут FB. транзакции везде одинаково работают

FB притом, что не у всяком БД нет журнала транзакций.
Например, я даже задумался, не стоит ли в случаях с потерей оперативки создавать свой, отдельно размещенный журнал(что опять может привести замедлению(лишние движения)) ИМХО

Возможна поломка базы, возможна. Хотя и весьма маловероятна.

Задача и состоит в том, чтоб исключить такую вероятность максимально. Всезнающими никто не родился, я не исключение, но думаю это исправимо.

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

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

Спасибо за участие в дискусии всем. Возможно я повторяюсь каким-то образом в своих вопросах, но так приобретаеться уверенность в правильности будущего решения. С уважением. Жду ваших комментов.

[stix-s]

при чем тут FB. транзакции везде одинаково работают.

Ага, только не везде ими правильно управляют
Сходил вот сегодня в магазин, запастить на обед. Расплатился кредиткой:у кассира на мониторе - в авторизации отказано - мне SMS, что деньгу успешно содрали
Ладно, еще разок кредитку провели - у кассира все ОК, и с меня еще раз содрали
Вот в свой банк дозвонюсь и решу куда права качать идти:в магазин, в банк магазина или в свой банк.
А поди у всех все на всемогущем Оракле

[WildSery]

FB притом, что не у всяком БД нет журнала транзакций.
Например, я даже задумался, не стоит ли в случаях с потерей оперативки создавать свой, отдельно размещенный журнал(что опять может привести замедлению(лишние движения)) ИМХО

При чём тут тип БД? Если повреждена память, то и в журнале будет муйня. Точно так же система не гарантирует, что весь журнал будет сохранён при внезапном исчезновении питания.

[Attid]

ошибка с дисками решается рейдами или теневой копией.

ошибка с памятью и прочим железом репликацией в реальном времени

ну и логированием на клиенте.

я себе выбрал вариант с теневой копией и логами действий на клиенте за последние 2е суток. ну и бекап почаще и подальше =)

[Nat]

При чём тут тип БД? Если повреждена память, то и в журнале будет муйня. Точно так же система не гарантирует, что весь журнал будет сохранён при внезапном исчезновении питания.

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

ошибка с дисками решается рейдами или теневой копией.

ошибка с памятью и прочим железом репликацией в реальном времени

ну и логированием на клиенте.

Мне кажеться, что это самое подходящее решение. В любом случае в ходе этого спора с уважаемыми участниками форума я приобрел уверенность в пути решения проблемы. Спасибо всем, кто принял участие в обсуждении моей проблемы и потратил свое время!
С уважением и благодарностью.

[Nat]

Остальное мне понятно и остается лишь потщательнее изучить некоторые материалы по способам восстановления и механизамам работы FB

[Nat]

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

[WildSery]

Насколько я понимаю, при начале транзакции в журнал вноситься запись(там где журнал существует) о том, что такая-то транзакция начата(всегда думал, что одна из причин создания журнала транзакций это в том числе и возможность восстановления недокачанных транзакцияй после мягкого сбоя) после фиксации она отмечается, как фиксированная или в случае мягкого сбоя докатывается после запуска.

Что значит "докатывается"? Если транзакция не завершена, то почему ты решаешь, что её нужно подтвердить, на основании каких данных?
"Продолжить" транзакцию вообще нельзя - откуда ты знаешь, что должно было быть дальше?
Каких ещё "недокачанных" транзакций? Это к предыдущему моему вопросу, наверное?

[Nat]

Честно говоря не помню как точно, но логика следующая...-> Это вытекает из принципа учета транзакций, который говорит о том, что изменения в БД сохраняются в два этапа, сначала сохраняются изменения без изменения состояния БД, на втором этапе изменения сохраняются или отменяются клиентским процессом (commit или rollback). Если мы добавляем запись, то в БД появляеться новая запись. Если удаляем, то запись не затираеться, а просто отмечаеться, как удаленная. Если модифицируем, опять же появляеться новая модифицированная запись, а старая отмечаеться, как устаревшая. Но все это появляется до комита. После комита же она отмечаеться, как актуальная, в случае отката - что происходит точно не помню, но кажеться устаревшая запись береться и переписываеться вновь и подтверждается, поскольку идентификатор ее тразакции больше, она становится актуальной.
В случае сбоя до момента фиксации, но после записи новой записи, у нас есть незафиксирорванные транзакции в журнале.
В механизме я возможно ошибаюсь...

[Nat]

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

[вырезано модератором]

[Slavik]

Зачем приводить здесь выдержки из статьи? Мы её читали.

Не понимаю я смысла изысканий. Сделать такую систему, которая будет самовосстанавливаться при любых сбоях? А кто будет контролировать контролёра ?

Ну, а если всё-таки время неработоспособности системы очень хочется сократить и процесс восстановления более-менее автоматизировать, то здесь начинается полёт фантазии ограниченый бюджетом и временем разработки такой системы разумной достаточностью.

Параноидальный пример с трёхзвенкой. Есть несколько основных дублирующих друг друга серверов и несколько промежуточных (трёхзвенка). Все запросы идут через среднее звено, т.е. промежуточный сервер, который легко может быть заменён другим (запасным), т.к. сам никаких данных не содержит и запросы не обрабатывает, а лишь перенаправляет их основным серверам. Причём транзакция считается успешной только если она успешно прошла на всех основных серверах из списка активных. Если какой-то из основных серверов вернул непредусмотренную ошибку или не отвечает заданное время, то промежуточное приложение исключает его из списка активных и в дальнейшем запросы к нему не шлёт.

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

Периодически согласно плану каждый основной сервер проходит процедуру резервного копирования базы данных. Способы реализации неограничены. Главное -- синхронизация. Т.е. перед началом резервного копирования базы, служба, отвечающая за это, посылает сигнал промежуточному приложению с просьбой приостановить посылку запросов на все основные сервера, промежуточное приложение выполняет эту просьбу и возвращает сигнал службе резервного копирования, которая ставит в базу данных метку, запускает процесс резервного копирования и немедленно извещает промежуточное приложение о возможности возобновления запросов к основным серверам. Процесс резервного копирования, естественно, продолжается на фоне работающей системы. Метка служит для облегчения возможности выявления данных, которых не будет в резервной копии базы.

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

Теперь, что делать если один из основных серверов был исключен из списка активных? На мой взгляд, с этим должно разбираться ответственное лицо в зависимости от причины неработоспособности. Главное, что пока идет разбирательство и починка, общая система остаётся в рабочем и активном состоянии. Когда поломанный сервер починен, на нем запускается процесс синхронизации. Синхронизатор восстанавливает самый свежий бэкап с "живого" сервера и доплняет его разницей, начиная с последней метки. Естественно, архивация базы-источника на этот период должна быть запрещена. Процесс заливки данных можно повторять до достижения некоторого минимального количества записей, которые надо перелить из "живой" базы в "оживляемую". Далее синхронизатор, как и в случае резервного копирования, посылет сигнал промежуточному приложению с просьбой о приостановке выполнения запросов. Получив ответ, докачивает данные и активирует оживший основной сервер. Аналогично можно делать плановый бэкап/рестор.

Как и любой вариант, данный имеет кучу недостатков. Если не упоминать его стоимости, то -- это нелюбовь к длинным транзакциям во время обслуживания, ибо если во время выполнения длинных транзакций серверу приложений придёт сигнал на приостановку обработки запросов, то вся система станет в режим ожидания. Хотя можно и rollback сделать, если очень надо.

[kdv]

нечего тут цитировать статьи, тем более устаревшие, с этого же сайта.
Статью Харрисон если и можно читать, то в последнюю очередь, если вообще нужно.
читай www.ibase.ru/devinfo/mga.htm , а дальше все остальные которые указаны в конце этой статьи

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

В общем, ты лучше сначала почитай статьи на сайте, по 2-3 раза, а потом приходи сюда опять с вопросами, что именно осталось тебе непонятным.