Comments 7
я бы убрал размещение арбитра в офисе из примера, обычно там самый плохой и нестабильный интернет.
К тому же как только нет инета в офисе (бц без света, проблемы с провайдером) состояние кластера после этого неизвестно…
К тому же как только нет инета в офисе (бц без света, проблемы с провайдером) состояние кластера после этого неизвестно…
0
Вопрос такой, как будет вести себя вся система и арбитр в том числе, если как обычно не пропадает полностью связь, а например latency увеличивается в разы?
Второй вопрос, арбитр общается по tcp? Какой тайм-аут на heartbeat? Что происходит при 15 процентной потери пакетов между репликами?
Второй вопрос, арбитр общается по tcp? Какой тайм-аут на heartbeat? Что происходит при 15 процентной потери пакетов между репликами?
0
Как всегда интересуют "пограничные состояния". Например раз в 30 сек падает связь на 20 секунд, что будет делать ваш кластер ?
0
Смотря между какими площадками будет пропадать связь.
Если между схд (канал реплики), то порт репликации, где пропадает связь будет помещаться неактивным и по нему не будет ходить трафик.
Если между схд и арбитром, то арбитр будет все время думать, что схд "падает" и будет ходить проверять себя к другой схд, где другая схд "опровергнет" предположение слишком канал реплики работает.
Если и там и там, то ничего работать не будет, ибо это трэш и так делать нельзя)
В любом случае, для метрокластера нужны надежные каналы, если их нет, то лучше выбрать асинхронную реплику
0
Видимо арбитр это и есть тот самый бессмертный админ…
0
Sign up to leave a comment.
AERODISK Engine: Катастрофоустойчивость. Часть 2. Метрокластер