Interbase: горячее резервирование

Yzzi

Есть рабочая станция и два сервера. Один считается основным, второй — дублирующим, об запущены, оба под windows (Сервер 2003 std). На рабочей станции запущено приложение, использующее IB. Хочется, чтобы при выдергивании кабеля питания из любого из серверов приложение это не заметило. Возможно такое?

sobleb

IB
Что это такое?

Yzzi

Interbase

geja_03

Что это такое?
Interbase, как следует из названия. =)

sobleb

Туплюнах... :grin:

sobleb

Кластеризуй... :smirk:
Только я что-то не нашёл, что интербазе поддерживает актив-актив конфигурацию... :confused:

staskolosov

Можно ИБП всунуть внутрь сервера :) Тогда кабель питания можно будет иногда выдёргивать :)
Или можно написать какой-нибудь умный ретранслятор, который бы работал на клиенте и переадресовывал обращения программы к разным серверам, следя за их доступностью и дублируя запросы на изменение данных.
Но проще, всё-таки, использовать один сервер, поставить ИБП и сделать RAID.

sobleb

Но проще, всё-таки, использовать один сервер, поставить ИБП и сделать RAID
Не спасёт от сбоя памяти, того же рейд-контроллера, материнки, проца...

staskolosov

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

Yzzi

ИБП в корпусе сервера это хорошо! А в корпус ИБП подсадить хомячков на карусельку с динамкой :)
Дублирующие сервера — это ТЗ от заказчика.
Interbase действительно от Borland.
Или можно написать какой-нибудь умный ретранслятор, который бы работал на клиенте и переадресовывал обращения программы к разным серверам, следя за их доступностью

Существуют уже готовые решения?

psm-home

В такой постановке задача скорее всего решения не имеет. Я знаю варианты типа
1). "Самопальный стендбай". На одной базе делеются инкрементальные бекапы, непрерывно накатываются на вторую. Понятно, что есть лаг между двумя БД, и что падение активной БД приложение еще как заметит, и должно уметь переключится на вторую БД.
2). Как в 1 но вместо наката инкрементальных бекапов использовать репликатор, самодельный или готовый, их есть, искать на ibase.ru. Проблемы примерно те же что у 1). приложение должно иметь логику обнаружения сбоя БД и переключения на запасную.
3).Кластеризация на уровне ОС, типа Windows Cluster или там на Linux можно что-то типа DRDB заюзать. Минусы такие, что креш сервера может привести к повреждению БД на диске, пока БД не починишь, запасной сервер IB не поднимется. Кроме того опять таки приложение должно уметь переключаться на запасной сервер.
Понятно, что все 3 варианта сосут. Я бы сказал что у IB все плохо с высокой доступностью :).

staskolosov

Существуют уже готовые решения?
Не знаю. Никогда не сталкивался на практике с такими задачами. Попробуй поискать, может что найдёшь. Но ввиду не очень высокой распространённости IB их будет немного и они будут дорогие.
Оставить комментарий
Имя или ник:
Комментарий: