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.