Открыть список
Как стать автором
Обновить

Комментарии 7

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

Да, если интернет в офисе не очень, то конечно не стоит там ставить арбитра. В таком случае лучше использовать арендованную ВМ, сервер или 2 юнита для своего оборудования в любом коммерческом ЦОДе, отличном от тех, где стоят СХД.

Вопрос такой, как будет вести себя вся система и арбитр в том числе, если как обычно не пропадает полностью связь, а например latency увеличивается в разы?
Второй вопрос, арбитр общается по tcp? Какой тайм-аут на heartbeat? Что происходит при 15 процентной потери пакетов между репликами?

Максимальная задержка до арбитра 2 секунды (хотя рекомендуемая 200мс). Для хартбита важно, чтобы дошел пинг.


Если ожидаются задержки больше, то на этапе планирования лучше предусмотреть площадку с более надежным соединением или отказаться от метрокластера в пользу обычной реплики.

Как всегда интересуют "пограничные состояния". Например раз в 30 сек падает связь на 20 секунд, что будет делать ваш кластер ?

Смотря между какими площадками будет пропадать связь.


Если между схд (канал реплики), то порт репликации, где пропадает связь будет помещаться неактивным и по нему не будет ходить трафик.


Если между схд и арбитром, то арбитр будет все время думать, что схд "падает" и будет ходить проверять себя к другой схд, где другая схд "опровергнет" предположение слишком канал реплики работает.


Если и там и там, то ничего работать не будет, ибо это трэш и так делать нельзя)


В любом случае, для метрокластера нужны надежные каналы, если их нет, то лучше выбрать асинхронную реплику

Видимо арбитр это и есть тот самый бессмертный админ…
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.