Informix Logo Архив конференции ukr.comp.dbms.informix
Пред. по дате ] [ След. по дате ] [ Пред. по нити ] [ След. по нити ][ Индекс по датам ][ Индекс по нитям ]

Re: ER fault tolerance

From "Denis Melnikov" <dmelnik@col.ru>
Date Tue, 18 Jun 2002 17:02:58 +0400
Organization COMSTAR Telecommunications

Serg Kovalenko <sk@profix.kiev.ua> сообщил в новостях
следующее:aen250$6cd$1@castle.profix.kiev.ua...
>
> "Denis Melnikov" <dmelnik@col.ru> wrote in message
> aemstc$sl0$1@storm.comstar.ru">news:aemstc$sl0$1@storm.comstar.ru...
> > Добрый день!
> >
> > Как я уже писал, планирую репликацию оперативного сервера на отчетный.
> > Документация оставляет открытым вопрос отказоустойчивости репликации.
> Поэтому
> > задаю вопрос здесь:
> >
> > 1-я ситуация - падает оперативный сервер. Я его восстанавливаю до момента
> > времени (PIT). Но отчетный сервер уже принимал данные после PIT до сбоя.
> > Как их откатить?
> Зачем их откатывать? Отчетный становится Primary, а оперативный с него
> докатывает изменения.

Это так в случае HDR, но я говорю об Enterprise Replication.

> Дальше - отчетный сервер (Slave) не может принимать данные, если он не будет
> переключен в режим  Primary.
> >
> > 2-я ситуация - падает отчётный сервер. В итоге после восстановления на нем
> > нет свежих данных оперативного сервера. Как их докатить?
> Дело в том, что архив делается только на Primary сервере, Slave поднимается
> с него.
> Соответсвенно, изменения на Slave докатываются логами с Primary.
> >
> > Понятно, что в 1-м случае бронебойный способ - параллельное восстановление
> Нет, как я обяснил выше.
> > обоих серверов до PIT. А во 2-м - инициализация репликации с нуля.
> В каком-то роде - да.
> > Но может быть есть и более экономичные пути (вроде анализа onlog)?
> >
> > Денис.




Украинская баннерная сеть
Home ] Hosted by No-MORE