Spec-Zone.ru › RethinkDB ruby

Переключение

При выходе из строя сервера причина может быть связана с проблемами доступности сети или более серьезными проблемами, такими как системный сбой. В конфигурации с несколькими серверами, где таблицы имеют несколько реплик, распределенных по нескольким физическим машинам, RethinkDB в большинстве случаев сможет автоматически поддерживать доступность.

Для выполнения автоматического переключения для таблицы необходимо выполнить следующие требования:

  • Кластер должен иметь три или более серверов
  • Таблица должна быть настроена на наличие трех или более реплик
  • Должно быть доступно большинство (более половины) реплик для таблицы

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

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

Голосующие и неголосующие? По умолчанию все реплики являются «голосующими», что просто означает, что они учитываются при любой операции, для которой требуется доступность большинства реплик. Однако скорость, с которой реплики «голосуют», зависит от задержки сети; если у вас есть удаленный дата-центр с высокой задержкой, вы можете установить его реплики в неголосующие, чтобы улучшить производительность, но при этом гарантированная доступность в этом дата-центре не обеспечивается. Вы можете установить реплику как «неголосующую», изменив ее конфигурацию таблицы с помощью reconfigure.

Ограничения автоматического переключения

В большинстве случаев автоматическое переключение может выполняться, если доступно большинство голосующих реплик. Однако в одном случае его может не произойти - при непереходном сбое подключения. Представьте себе кластер из трех серверов: A, B и C. В нормальных условиях работы сети все серверы могут подключаться друг к другу. Если произойдет сбой сети таким образом, что A может подключиться к B, а B к C, но A не может подключиться к C, то сбой сети является непереходным. Более подробное описание, а также информация о долгосрочном решении, можно найти в Github issue #4357.

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

© RethinkDB contributors
Licensed under the Creative Commons Attribution-ShareAlike 3.0 Unported License.
https://rethinkdb.com/docs/failover/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API