2.9. Отказоустойчивость и высокая доступность
Shardman обеспечивает отказоустойчивость сразу после установки. Демон shardmand контролирует конфигурацию кластера Shardman и управляет кластерами stolon, которые используются для обеспечения доступности сегментов и отказоустойчивости. Общая конфигурация Shardman (shardmand, stolon) хранится в кластере etcd.
Чтобы обеспечить отказоустойчивость каждого кластера stolon, необходимо установить Repfactor > 0 в режиме перекрёстной репликации (PlacementPolicy=cross) или добавить хотя бы одну реплику в режиме ручной топологии (PlacementPolicy=manual).
Процессы stolon sentinel отвечают за наблюдение за процессами keeper и выбор одного из таких процессов в качестве ведущего. Процессы sentinel проводят выборы при запуске кластера и каждый раз, когда текущий ведущий процесс sentinel выходит из строя.
Один из процессов keeper выбирается ведущим. Все операции записи выполняются в ведущем процессе, а остальные экземпляры используются в качестве резервных.
В случае автоматической отработки отказа stolon позаботится об автоматической замене резервного на ведущего, а вышедшего из строя ведущего — на резервного. Для выполнения отработки отказа дополнительно требуется наличие etcd, в котором сохраняется мгновенный статус ведущего/резервного от stolon.
При необходимости можно переключить ведущего вручную, выполнив команду shardmanctl shard switch.
Автоматическая отработка отказа основана на использовании тайм-аутов, которые можно переопределить в sdmspec.json, как в данном примере:
{
"ShardSpec":{
"failInterval": "20s",
"sleepInterval": "5s",
"convergenceTimeout": "30s",
"deadKeeperRemovalInterval": "48h",
"requestTimeout": "10s",
...
},
...
},
...
Можно указать некоторые параметры отказоустойчивости, чтобы задать поведение кластера в состоянии сбоя: masterDemotionEnabled, masterDemotionTimeout, minSyncMonitorEnabled и minSyncMonitorUnhealthyTimeout.
2.9.1. Тайм-ауты
-
convergenceTimeout Интервал ожидания достижения базой данных требуемого состояния, когда не ожидается длительных операций.
По умолчанию:
30s.-
deadKeeperRemovalInterval Интервал, по истечении которого «мёртвый» процесс
keeperбудет удалён из данных кластера.По умолчанию:
48h.-
failInterval Интервал после первой ошибки по истечении которого процесс объявляется
keeperили базы данных неработоспособной.По умолчанию:
20s.-
requestTimeout Интервал, по истечении которого любой запрос (проверок процессов
keeperпроцессамиsentinelи т. д.) завершится ошибкой.По умолчанию:
10s.-
sleepInterval Интервал ожидания перед следующей проверкой.
По умолчанию:
5s.