>
> Поэтому в данной ситуации, если Мастер не доступен зеркалу и
> редиректорам, вполне справедливо будет считать его died.
> И передать статус active на сервер А.
А если мастер и один редиректор оказались в одной половине интернета
(вместе с частью клиентов), зеркало и другой редиректор - в другой ?
Между двумя половинками (M9 развалилась, скажем) интернет не ходит.
> Не обязательно. Редиректоры получают "я жив" от Мастера и зеркал,
> кстати точно так-же они могут обмениваться информацией о том, кто
> получает какой сигнал от других.
Могут. Но это эскалация той же проблемы на уровень редиректоров.
> > Но он выдаст редирект на редиректор, который отправит на одно из
> > зеркал - которые на самом деле отвалились от пользователя. Или
> > не отвалились :)
> Почему бы редиректору не _вспомнить_, какую информацию об этом
> "дисконнекте" имеют остальные? Если остальные видят, что А и Б
> недоступны, а Мастер жив, то считать его active.
А если система из трех редиректоров и трех серверов БД распалась
на три сегмента ? Каждый видит ровно один сервер БД.
Я специально предлагаю симметричные случаи - они проще для анализа.
> > частично жив). Кто из двух будет продолжать обслуживание, а кто не будет ?
> > Если будут оба, то последний билет будет продан два раза.
> В ситуации необходим сторонний арбитр, = редиректор, который при
> наличии ответов и от Мастера, и от А, установит на Мастере статус
> Active,
Я уже писал - если сторонний арбитр один, то он является SPF
(и никто не гарантирует, что от сети не отвалился именно он)
Если арбитров несколько - возникает проблема выборов среди них,
которая ничем не отличается от выбора главного из серверов БД.
>если Мастера будеТ видеть только один редиректор из скажем 10,
> то он на критический период берёт на себя функцию proxy.
Олег, напишите все это в (псевдо)коде.
Можно выдвигать всякие забавные идеи, но они должны алгоритмизироваться.
Я пока ничего разумного для алгоритмизации не увидел, кроме
благих пожеланий "хорошо бы сделать так" (действительно, неплохо),
"редиректоры могут обмениваться информацией" (действительно, могут).
Ну а толку то.
Алексей Тутубалин
mailto: lexa@lexa.ru
Web:
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
