тугодумик,

>Ну первым делом она вообще не должна падать:)

ну мы ведь живем в реальном мире ;) а не рекламных буклетов

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

Откат транзакции вам обеспечит любая база. Не вопрос.
Меня вот другое интересует. Как вы в рамках распределенной базы собираетесь поддерживать целостность? Речь то идет о хранении информации о ДЕНЬГАХ. Тут вам никакая периодическая репликация не поможет. И выглядеть это будет в вашем планируемом варианте примерно так: клиент обновляет данные (скажем свой счет) на одной из баз. Стартует распределенная транзакция, которая обязана синхронизировать изменение счета клиента во всех базах данных. Клиент нажав кнопку, нервно курит с минуту (как минимум) ожидая долгожданного подтверждения об окончании трансакции. Я уже не говорю про ситуацию, когда одна из баз в этот момент будет в офлайне....или канал до какой-либо из баз упадет.
Мое твердое убеждение - информация о деньгах должна хранится в одном месте. Иначе у вас система будет иметь столько ограничений и дополнительных условий, что в конечном итоге дискредитирует саму начальную идею распределенной БД.



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

А потом вам нужно эту упавшую базу еще каким-то образом синхронизировать с остальными. Кто пробовал делать distributed recovery в Oracle поймет о чем речь.

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

Как вы себе представляете ситуацию, когда "при проишествии какого-либо сбоя в базе данных она автоматом переправляла запрос на работающую базу" ?? База допустим лежит, а вы от нее еще чего-то хотите. Это сугубо задача клиентского софта.

Вот ссылка про организацию кластера под RedHat (это доработанный opensource kimberlite cluster)

http://www.redhat.com/docs/manuals/enterprise/RHEL-AS-2.1-Manual/cluster-manager/

Из того, что Вы здесь описали, у вас одни железки будут стоить > 50K