raft_failover.md: renormalize crlf -> lf

docs/architecture/raft_failover.md

-# Raft и отказоустойчивость
-
-Raft — алгоритм для решения задач консенсуса в сети ненадёжных
-вычислений. В Picodata этот алгоритм применяется для репликации
-глобальных таблиц и всей конфигурации кластера (топологии, схемы данных
-и другой информации). Raft обеспечивает согласованность данных на всех
-инстансах кластера.
-
-Raft предполагает, что в кластере всегда существует явно выделенный
-лидер (`leader`). Только он отправляет новые записи на другие узлы
-кластера. Если обычный узел (`follower`) долго не получает сообщений от
-лидера, то он переходит в состояние "кандидат" (`candidate`) и проводит
-процедуру голосования.
-
-## Динамическое переключение голосующих узлов в Raft (Raft voter failover) {: #raft-voter-failover }
-
-Все узлы Raft в кластере делятся на два типа: голосующие (`voter`) и
-неголосующие (`learner`). За консистентность raft-группы отвечают только
-первые. Для применения каждой записи требуется собрать кворум из `N/2 +
-1` голосующих узлов. Неголосующие узлы в кворуме не участвуют и всегда
-находятся в состоянии "follower".
-
-Чтобы сохранить баланс между надежностью кластера и удобством его
-эксплуатации, в Picodata предусмотрено автоматическое распределение
-голосующих узлов. Количество голосующих узлов в кластере не настраивается
-и зависит только от общего количества инстансов:
-
-- 1 инстанс — 1 голосующий узел;
-- 2 инстанса — 2 голосующих узла;
-- 3 или 4 инстанса — 3 голосующих узла;
-- 5 и более инстансов — 5 голосующих узлов;
-
-Если один из голосующих узлов становится недоступным
-или прекращает работу (что может нарушить кворум в Raft), то тип `voter`
-автоматически присваивается одному из доступных неголосующих узлов.
-Переключение происходит незаметно для пользователя.
-
-## Пример распределения голосующих узлов
-
-Приведем пример кластера с одним уровнем распределения узлов между
-локациями. Пусть это будет два датацентра (`MSK`, `SPB`) и третья
-локация для арбитража (решающего голоса в случае потери сетевой
-связности между датацентрами). Вне зависимости от общего числа узлов в
-кластере предполагается наличие всего 5 голосующих узлов, которые, в
-данном случае, распределятся так:
-
-- 2 в локации `MSK`;
-- 2 в локации `SPB`;
-- 1 в третьей локации.
-
-Если весь датацентр в локации `SPB` теряет доступность и связь с арбитром,
-то его 2 голосующих узла перемещаются в датацентр локации `MSK`. При
-восстановлении связности, голосующие узлы возвращаются обратно и
-исходная конфигурация восстанавливается.
-
-В случае, если лишь отдельный сервер с голосующим узлом в `SPB` теряет
-связь, то право голоса перемещается внутри локации, т.е. переходит к
-другому узлу в `SPB`. Если сервер восстанавливает связь, то он уже не
-станет автоматически голосующим, т.к. схема распределения не будет этого
-требовать.
-
-См. также:
-
-- [Репликация и зоны доступности](../tutorials/deploy_on_hosts.md#failure-domains)
-
----
-[Исходный код страницы](https://git.picodata.io/picodata/picodata/docs/-/blob/main/docs/architecture/raft_failover.md)
+# Raft и отказоустойчивость
+
+Raft — алгоритм для решения задач консенсуса в сети ненадёжных
+вычислений. В Picodata этот алгоритм применяется для репликации
+глобальных таблиц и всей конфигурации кластера (топологии, схемы данных
+и другой информации). Raft обеспечивает согласованность данных на всех
+инстансах кластера.
+
+Raft предполагает, что в кластере всегда существует явно выделенный
+лидер (`leader`). Только он отправляет новые записи на другие узлы
+кластера. Если обычный узел (`follower`) долго не получает сообщений от
+лидера, то он переходит в состояние "кандидат" (`candidate`) и проводит
+процедуру голосования.
+
+## Динамическое переключение голосующих узлов в Raft (Raft voter failover) {: #raft-voter-failover }
+
+Все узлы Raft в кластере делятся на два типа: голосующие (`voter`) и
+неголосующие (`learner`). За консистентность raft-группы отвечают только
+первые. Для применения каждой записи требуется собрать кворум из `N/2 +
+1` голосующих узлов. Неголосующие узлы в кворуме не участвуют и всегда
+находятся в состоянии "follower".
+
+Чтобы сохранить баланс между надежностью кластера и удобством его
+эксплуатации, в Picodata предусмотрено автоматическое распределение
+голосующих узлов. Количество голосующих узлов в кластере не настраивается
+и зависит только от общего количества инстансов:
+
+- 1 инстанс — 1 голосующий узел;
+- 2 инстанса — 2 голосующих узла;
+- 3 или 4 инстанса — 3 голосующих узла;
+- 5 и более инстансов — 5 голосующих узлов;
+
+Если один из голосующих узлов становится недоступным
+или прекращает работу (что может нарушить кворум в Raft), то тип `voter`
+автоматически присваивается одному из доступных неголосующих узлов.
+Переключение происходит незаметно для пользователя.
+
+## Пример распределения голосующих узлов
+
+Приведем пример кластера с одним уровнем распределения узлов между
+локациями. Пусть это будет два датацентра (`MSK`, `SPB`) и третья
+локация для арбитража (решающего голоса в случае потери сетевой
+связности между датацентрами). Вне зависимости от общего числа узлов в
+кластере предполагается наличие всего 5 голосующих узлов, которые, в
+данном случае, распределятся так:
+
+- 2 в локации `MSK`;
+- 2 в локации `SPB`;
+- 1 в третьей локации.
+
+Если весь датацентр в локации `SPB` теряет доступность и связь с арбитром,
+то его 2 голосующих узла перемещаются в датацентр локации `MSK`. При
+восстановлении связности, голосующие узлы возвращаются обратно и
+исходная конфигурация восстанавливается.
+
+В случае, если лишь отдельный сервер с голосующим узлом в `SPB` теряет
+связь, то право голоса перемещается внутри локации, т.е. переходит к
+другому узлу в `SPB`. Если сервер восстанавливает связь, то он уже не
+станет автоматически голосующим, т.к. схема распределения не будет этого
+требовать.
+
+См. также:
+
+- [Репликация и зоны доступности](../tutorials/deploy_on_hosts.md#failure-domains)
+
+---
+[Исходный код страницы](https://git.picodata.io/picodata/picodata/docs/-/blob/main/docs/architecture/raft_failover.md)