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


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



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

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

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