--- metadata: - name: generator content: Diplodoc Platform v5.50.6 alternate: - https://ydb.tech/docs/en/concepts/bridge.md?version=main - https://ydb.tech/docs/ru/concepts/bridge.md?version=main sourcePath: ru/core/concepts/bridge.md --- > **Documentation Index:** Fetch the complete configuration index at https://ydb.tech/docs/ru/llms.txt # Режим работы кластера Bridge {% note info "Функциональность Корпоративной СУБД Яндекса" %} Данная функциональность доступна только в [Корпоративной СУБД Яндекса](https://ydb.tech/docs/ru/downloads/yandex-enterprise-database.md?version=main). В open-source версии YDB она отсутствует. {% endnote %} Эта статья описывает особый режим работы кластера YDB, при котором хранение данных осуществляется с синхронной репликацией между несколькими частями кластера, называемыми [pile](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#pile). Режим bridge является надстройкой над базовыми режимами распределённого хранилища: каждый pile строится по одному из поддерживаемых YDB [режимов работы](https://ydb.tech/docs/ru/concepts/topology.md?version=main#cluster-config) (например, `mirror-3-dc` или `block-4-2`) и сам по себе отказоустойчив; bridge добавляет поверх этого синхронную репликацию между pile и управляемый failover/switchover нагрузки между ними. Это обеспечивает дополнительный слой отказоустойчивости поверх выбранных топологий. Режим bridge требует больше оборудования и сложнее в эксплуатации; он особенно полезен для кластеров, размещённых в двух дата-центрах, и систем с повышенными требованиями к доступности — например, когда необходимо сохранять доступность при отказе трёх дата-центров из четырёх. ## Описание режима {#description} В режиме bridge узлы кластера разделяются на несколько [pile](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#pile) (обычно — по одному pile в датацентре). При отказе одного из pile кластер становится недоступным до тех пор, пока не будет выполнена команда отключения этого pile. После отключения кластер возобновляет работу. YDB поддерживается произвольное количество pile, однако для простоты изложения далее рассматривается случай с двумя pile. На уровне [распределённого хранилища](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#distributed-storage) в режиме bridge реализуется синхронная репликация по схеме Active / Active между pile. На уровне [узлов баз данных](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#database-node) возможно резервирование по схеме Active / Passive. Для хранения данных используются пары [групп хранения](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#storage-group) из разных pile. При этом для хранения данных в каждом из pile могут применяться любые поддерживаемые YDB [режимы работы](https://ydb.tech/docs/ru/concepts/topology.md?version=main#cluster-config). В режиме bridge может быть достигнут zero-downtime [switchover](https://en.wikipedia.org/wiki/Switchover). При [failover](https://en.wikipedia.org/wiki/Failover) кластер требует явного отключения репликации в отказавший pile для возобновления работы. При отключении любого pile происходит приостановка обслуживания запросов до выполнения команды отключения репликации в этот pile. Pile не являются самостоятельными кластерами YDB, а представляют собой части одного кластера со сложной топологией: - [таблетки](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#tablet) в режиме bridge запускаются в единственном экземпляре; - в каждом pile работает отдельная [статическая группа](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#static-group) и набор независимых групп хранения с обычными [VDisk](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#vdisk). Доступ к группам хранения осуществляется через DS-proxy-proxy, который предоставляет таблеткам интерфейс [DS-proxy](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#ds-proxy) и выполняет операции с использованием двух DS-proxy — по одной для групп в каждом pile; - в каждом pile работает свой набор реплик [StateStorage](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#state-storage), [SchemeBoard](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#scheme-board) и [Board](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#board). Доступ к StateStorage, SchemeBoard и Board осуществляется через аналогичные proxy-proxy. ## Состояния Pile {#pile-states} Режим работы кластера определяется состояниями всех его pile. Например, для кластера из pile А и pile Б состояния pile указываются как (А, Б), где порядок имеет значение. ![Диаграмма состояний кластера](_assets/bridge_pile_states.drawio.svg){inline=false} Каждый pile может находиться в одном из следующих состояний: - `PRIMARY`. Основной pile, в котором работают таблетки. Только один pile может находиться в состоянии `PRIMARY`. - `SYNCHRONIZED`. Ведомый pile, в котором все группы хранения синхронизированы с `PRIMARY`. - `DISCONNECTED`. Отключённый от `PRIMARY`, не участвует в выполнении операций. - `NOT_SYNCHRONIZED`. Pile, в котором группы хранения ещё не синхронизированы с `PRIMARY`. При завершении синхронизации YDB автоматически переключает pile в состояние `SYNCHRONIZED`. - `PROMOTED`. Pile, который необходимо плавно переключить из состояния `SYNCHRONIZED` в состояние `PRIMARY`. Pile пребывает в этом состоянии до завершения плавного переключения, после чего YDB автоматически переключает его в состояние `PRIMARY`. - `SUSPENDED`. Pile, который необходимо плавно переключить в состояние `DISCONNECTED`. По завершении переключения YDB автоматически переводит pile в состояние `DISCONNECTED`. В норме пара pile работает в режиме `PRIMARY/SYNCHRONIZED` или `SYNCHRONIZED/PRIMARY`. То есть один из pile — `PRIMARY`, в нём работают таблетки, второй pile — `SYNCHRONIZED`, все его группы хранения синхронизированы с `PRIMARY`. Операция записи считается завершённой при таком состоянии pile только после успешного выполнения записи в группы хранения каждого pile с необходимой избыточностью. ### Переходы между состояниями {#transitions-between-states} | Состояние до | Состояние после | Как происходит | Пояснение | | --- | --- | --- | --- | | `PRIMARY` | `SYNCHRONIZED` | Автоматически | Завершение планового переключения. | | `PRIMARY` | `DISCONNECTED` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `PRIMARY` с выбором нового `PRIMARY`. | | `PRIMARY` | `SUSPENDED` | Вручную — [takedown](../reference/ydb-cli/commands/bridge/takedown.md) | Плановое отключение текущего `PRIMARY` с выбором нового `PRIMARY`. | | `SYNCHRONIZED` | `PRIMARY` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `PRIMARY` с выбором нового `PRIMARY`. | | `SYNCHRONIZED` | `DISCONNECTED` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `SYNCHRONIZED`. | | `SYNCHRONIZED` | `PROMOTED` | Вручную — [switchover](../reference/ydb-cli/commands/bridge/switchover.md) | Старт плановой смены `PRIMARY`. | | `SYNCHRONIZED` | `SUSPENDED` | Вручную — [takedown](../reference/ydb-cli/commands/bridge/takedown.md) | Старт планового отключения `SYNCHRONIZED` pile. | | `DISCONNECTED` | `NOT_SYNCHRONIZED` | Вручную — [rejoin](../reference/ydb-cli/commands/bridge/rejoin.md) | Возврат pile в кластер после обслуживания/восстановления. | | `NOT_SYNCHRONIZED` | `SYNCHRONIZED` | Автоматически | Завершение синхронизации данных. | | `NOT_SYNCHRONIZED` | `DISCONNECTED` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `NOT_SYNCHRONIZED`. | | `PROMOTED` | `PRIMARY` | Автоматически | Завершение планового переключения. | | `PROMOTED` | `PRIMARY` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `PRIMARY` с выбором нового `PRIMARY`. | | `PROMOTED` | `DISCONNECTED` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `PROMOTED`. | | `SUSPENDED` | `NOT_SYNCHRONIZED` | Вручную — [rejoin](../reference/ydb-cli/commands/bridge/rejoin.md) | Отмена планового отключения pile. | | `SUSPENDED` | `DISCONNECTED` | Автоматически | Завершение планового отключения. | | `SUSPENDED` | `DISCONNECTED` | Вручную — [failover](../reference/ydb-cli/commands/bridge/failover.md) | Аварийное отключение недоступного `SUSPENDED`. | ## Сценарии изменения состояния {#state-change-scenarios} ### Отказ pile {#failover} При отказе pile кластер становится недоступным. Для возобновления работы кластера необходимо отключить отказавший pile, переведя его в состояние `DISCONNECTED`. Администратор может подать команду переключения из состояния `PRIMARY/SYNCHRONIZED` или `SYNCHRONIZED/PRIMARY` в одно из состояний `PRIMARY/DISCONNECTED` или `DISCONNECTED/PRIMARY`. Команда изменяет конфигурацию групп хранения и приводит к изменению способа записи в эти группы. [Interconnect](https://ydb.tech/docs/ru/concepts/glossary.md?version=main#actor-system-interconnect) разрывает сессии со всеми узлами pile в состоянии `DISCONNECTED`; при этом сессии для обмена данными не устанавливаются (TCP-соединения для обмена метаданными о состояниях pile могут оставаться активными). Дальнейшие операции записи и чтения выполняются без участия pile в состоянии `DISCONNECTED`. Если изменился `PRIMARY` pile, таблетки перезапускаются в нём. Аналогичным образом выполняется переключение, если отказавший pile находился в любом состоянии, а назначаемый `PRIMARY` pile — в одном из допустимых состояний: `PRIMARY`, `SYNCHRONIZED`, `PROMOTED`. Если назначаемый `PRIMARY` pile находился в состоянии `DISCONNECTED`, `NOT_SYNCHRONIZED` или `SUSPENDED`, штатное переключение невозможно, поскольку pile может не содержать полной и актуальной реплики данных. ### Восстановление pile {#rejoin} После восстановления работоспособности узлов отказавшего pile его необходимо повторно подключить к кластеру, переведя в состояние `NOT_SYNCHRONIZED`. Администратор может подать команду переключения из состояния `PRIMARY/DISCONNECTED` в `PRIMARY/NOT_SYNCHRONIZED` или из `DISCONNECTED/PRIMARY` в `NOT_SYNCHRONIZED/PRIMARY`. Произойдёт обмен конфигурацией между узлами; сессии interconnect устанавливаются только между узлами с одинаковой конфигурацией. Команда запускает синхронизацию групп хранения. По завершении синхронизации происходит автоматическое переключение из состояния `PRIMARY/NOT_SYNCHRONIZED` в `PRIMARY/SYNCHRONIZED` или из `NOT_SYNCHRONIZED/PRIMARY` в `SYNCHRONIZED/PRIMARY`. ### Плановое переключение PRIMARY pile {#switchover} Для плановой смены `PRIMARY` pile необходимо перевести назначаемый новым `PRIMARY` pile в состояние `PROMOTED`. Администратор может подать команду переключения из состояния `PRIMARY/SYNCHRONIZED` в `PRIMARY/PROMOTED` или из `SYNCHRONIZED/PRIMARY` в `PROMOTED/PRIMARY`. Команда не изменяет способ записи в группы хранения, но обновляет их конфигурацию и инициирует смену `PRIMARY` pile с плавным переносом таблеток в новый `PRIMARY`. По завершении переключения состояние `PRIMARY` сменяется на `SYNCHRONIZED`, а `PROMOTED` - на `PRIMARY`. ### Плановое отключение pile {#takedown} Для планового отключения pile его необходимо перевести в состояние `SUSPENDED`. Администратор может подать команду переключения из состояния `PRIMARY/SYNCHRONIZED` в `PRIMARY/SUSPENDED` или из `SYNCHRONIZED/PRIMARY` в `SUSPENDED/PRIMARY`. Будет выполнено плановое отключение узлов pile, переведённого в состояние `SUSPENDED`, с переводом их в режим `DISCONNECTED`. Система стремится минимизировать влияние этого процесса на работу кластера. После завершения перевода pile в состояние `DISCONNECTED` его узлы могут быть выключены для технического обслуживания. После этого необходимо выполнить штатное восстановление pile, переключив его в состояние `NOT_SYNCHRONIZED`. ### Восстановление при разделении кластера на две части с несовместимой конфигурацией (split brain) {#split-brain} Может возникнуть ситуация, когда администратор привёл кластер в состояние, при котором pile А и Б оказались изолированы друг от друга, а затем pile А был переконфигурирован так, что стал `PRIMARY`, а pile Б — `SYNCHRONIZED`, и одновременно pile Б был переконфигурирован так, что стал `PRIMARY`, а pile А — `SYNCHRONIZED`. Это приводит к разделению кластера на две части с несовместимой конфигурацией ([split-brain](https://en.wikipedia.org/wiki/Split-brain_(computing))). В таком состоянии каждая часть кластера может оставаться работоспособной. Для восстановления единого кластера необходимо выбрать, какой из pile будет очищен. После этого нужно остановить все узлы этого pile, дождаться их полной остановки, очистить все диски на всех узлах, а затем снова включить узлы очищаемого pile. После этого следует выполнить штатное восстановление pile, переведя его в состояние `NOT_SYNCHRONIZED`. ### Нештатное восстановление pile В сложных ситуациях, например при последовательных отказах pile, может возникнуть следующий сценарий: сначала отказал pile А, он был переведён в состояние `DISCONNECTED`, и кластер продолжил работу; затем произошёл необратимый отказ pile Б; после этого удалось восстановить работоспособность pile А. В таких случаях возможно восстановление кластера на основе pile А. Если необходимо возобновить работу кластера, когда работоспособность сохранил только pile, находящийся в состоянии `DISCONNECTED`, `NOT_SYNCHRONIZED` или `SUSPENDED`, администратор может выполнить команду переключения из `PRIMARY/DISCONNECTED` в `DISCONNECTED/PRIMARY` (или аналогично для `NOT_SYNCHRONIZED` или `SUSPENDED`) с указанием специального параметра `force`. Это приведёт к разделению кластера на две части с несовместимой конфигурацией. В зависимости от фактического состояния данных в pile, который переводится в состояние `PRIMARY`, кластер может быть восстановлен в корректное или внутренне неконсистентное состояние. Работоспособность такого кластера не гарантируется. Если кластер оказался работоспособным, можно продолжить восстановление до нормального состояния. Перед восстановлением отключённого pile необходимо полностью очистить данные и метаданные на всех его узлах, после чего перевести pile в состояние `NOT_SYNCHRONIZED`. ## Особенности реализации режима bridge {#bridge-implementation-details} Подробнее об устройстве режима bridge см. в [Устройство режима bridge](https://ydb.tech/docs/ru/contributor/bridge.md?version=main).