--- metadata: - name: generator content: Diplodoc Platform v5.50.4 alternate: - https://ydb.tech/docs/en/contributor/bridge.md - https://ydb.tech/docs/ru/contributor/bridge.md sourcePath: ru/core/contributor/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). В open-source версии YDB она отсутствует. {% endnote %} Общее описание режима и сценарии использования см. в статье [Режим работы кластера Bridge](https://ydb.tech/docs/ru/concepts/bridge.md). Эта статья предназначена для разработчиков и контрибьюторов YDB и содержит технические детали реализации режима bridge. YDB поддерживает произвольное количество pile, однако для простоты изложения далее рассматривается случай с двумя pile, назовём их pile А и pile Б. ## Хранение конфигураций [Distconf](https://ydb.tech/docs/ru/concepts/glossary.md#distributed-configuration) хранит конфигурацию двух [статических групп](https://ydb.tech/docs/ru/concepts/glossary.md#static-group), двух наборов [state storage](https://ydb.tech/docs/ru/concepts/glossary.md#state-storage), а также [scheme board](https://ydb.tech/docs/ru/concepts/glossary.md#scheme-board) и [board](https://ydb.tech/docs/ru/concepts/glossary.md#board). В нём же сохраняется режим работы кластера. Конфигурация статических групп, state storage и бордов использует схему хранения с двумя комплектами кворумов: - Кворум А — включает только узлы из pile А. Запись считается успешной, если она прошла на большинстве узлов pile А и на кворуме дисков статической группы pile A; - Кворум Б — включает только узлы из pile Б. Запись считается успешной, если она прошла на большинстве узлов pile Б и на кворуме дисков статической группы pile Б. При отказе одного из pile запись в соответствующий кворум становится невозможной. Distconf использует оба кворума (А и Б) для хранения конфигурации: - Конфигурация с режимом `PRIMARY/DISCONNECTED` записывается только в кворум А; - Конфигурация с режимом `DISCONNECTED/PRIMARY` записывается только в кворум Б; - Все остальные режимы записываются в оба кворума — А и Б. При выполнении failover администратор переводит кластер в режим `PRIMARY/DISCONNECTED` или `DISCONNECTED/PRIMARY`. В этом режиме конфигурация общих компонентов сохраняется только на кворуме из `PRIMARY` pile. Для начала восстановления администратор переводит пару из живого и отказавшего pile в режим `PRIMARY/NOT_SYNCHRONIZED`. Такая конфигурация сохраняется на всех кворумах. Запись конфигурации запрещена, если новая конфигурация несовместима с последней сохранённой на узле. Например, переход из `PRIMARY/DISCONNECTED` в `DISCONNECTED/PRIMARY` недопустим. Это предотвращает ситуацию, при которой pile А и Б одновременно переключаются в режимы, претендующие на роль `PRIMARY`. Для защиты от взаимодействия pile А и pile Б в случае конфликта конфигураций блокируется установка сессий interconnect при обнаружении подобных несоответствий на узлах. У Distconf при работе в режиме bridge в каждом pile создаётся поддерево, и корни этих поддеревьев присоединяются к лидеру Distconf. Это позволяет при потере pile минимизировать необходимое перестроение связей узлов Distconf. ## Запуск статических групп Конфигурация всех статических групп хранится в Distconf. Корень поддерева Distconf в каждом pile может получить конфигурацию и принять решение о необходимом для применения этой конфигурации кворуме на основании самой конфигурации. `DISCONNECTED` pile не участвует в кворуме, поэтому для применения конфигурации без `DISCONNECTED` pile необходимы кворумы А и Б, для применения конфигурации `PRIMARY/DISCONNECTED` необходим только кворум А, для применения конфигурации `DISCONNECTED/PRIMARY` необходим только кворум Б. Когда необходимый кворум собран, Distconf применяет конфигурацию, а [Node Warden](https://ydb.tech/docs/ru/concepts/glossary.md#node-warden) запускает [VDisk](https://ydb.tech/docs/ru/concepts/glossary.md#vdisk) и [PDisk](https://ydb.tech/docs/ru/concepts/glossary.md#pdisk) статических групп. Для доступа к статической группе используется сервис `dsproxy-proxy`, который предоставляет таблеткам интерфейс [`dsproxy`](https://ydb.tech/docs/ru/concepts/glossary.md#ds-proxy) и выполняет операции синхронно с обеими группами в паре. Dsproxy-proxy статической группы меняет режим работы в зависимости от конфигурации, полученной от distconf. Конфигурация dsproxy-proxy хранится в конфигурации общих компонент. ## Поведение dsproxy-proxy {#dsproxy-proxy} В режиме `PRIMARY/SYNCHRONIZED` запись выполняется синхронно в две группы; чтение выполняется из `PRIMARY`, и при каждом чтении выполняется ping-запрос во вторую группу, чтобы гарантировать своевременное уведомление о разрыве связи или смене режима работы группы. В режиме `PRIMARY/DISCONNECTED` запись и чтение выполняются только в `PRIMARY`-группе. В режиме `PRIMARY/NOT_SYNCHRONIZED` dsproxy-proxy поддерживает несколько подрежимов, определяющих, какие виды записи выполняются в `NOT_SYNCHRONIZED`-группе: - `WRITE_KEEP` — выполняется только запись `KEEP`-флагов; - `WRITE_KEEP_BARRIER_DONOTKEEP` — выполняется запись барьеров, `KEEP`- и `DO_NOT_KEEP`-флагов; - `WRITE_KEEP_BARRIER_DONOTKEEP_DATA` — выполняется запись данных, барьеров, `KEEP`- и `DO_NOT_KEEP`-флагов. Конфигурация dsproxy-proxy содержит: - режим; - подрежим; - `PPGeneration` — номер поколения конфигурации dsproxy-proxy; - номер поколения конфигурации dsproxy-группы из pile А; - номер поколения конфигурации dsproxy-группы из pile Б. При изменении конфигурации dsproxy-proxy обязательно изменяется номер поколения конфигурации и конфигурации группы для `PRIMARY`-группы — всегда, для остальных — за исключением состояния `DISCONNECTED`. В конфигурацию группы включаются: - режим; - подрежим; - `PPGeneration` — номер поколения конфигурации управляющего dsproxy-proxy. При каждой операции группа проверяет режим, подрежим и `PPGeneration`. Это необходимо, чтобы не выполнялись операции от устаревших экземпляров dsproxy-proxy, пропустивших смену режима или подрежима, и чтобы избежать перекрёстного взаимодействия при возникновении двух `PRIMARY`. Для перехода из режима `PRIMARY/NOT_SYNCHRONIZED` в режим `PRIMARY/SYNCHRONIZED` выполняется синхронизация. В ходе синхронизации недостающие данные переносятся из `PRIMARY`-группы в `NOT_SYNCHRONIZED`-группу, а также выполняется двустороннее копирование информации о блокировках. ## Bootstrap BSController и других системных таблеток {#bootstrap} В списке узлов для запуска таблетки достаточно указать один набор узлов, включающий достаточное количество узлов из каждого pile. Bootstrapper должен анализировать конфигурацию state storage proxy-proxy и на её основе определять, можно ли запускать таблетку на данном узле. Если запуск таблетки на узле невозможен (поскольку узел не находится в `PRIMARY`-pile), Bootstrapper должен пройти по дереву подключённых к нему Bootstrapper-ов и назначить в качестве запускающего Bootstrapper из `PRIMARY`-pile. Если такого Bootstrapper-а нет, текущий Bootstrapper не должен запускать таблетку. ## Конфигурация и запуск остальных таблеток {#other-tablets} Динамическими группами хранения управляет BS Controller. Вместо каждого обычного storage-пула каждый раз создаётся три storage-пула: в пуле А — группы из pile А, в пуле Б — группы из pile Б, в пуле Ц — прокси-прокси группы, составленные из пар групп из пулов А и Б. Управляемые хайвом таблетки используют только прокси-прокси группы из пула Ц. Запуск таблеток выполняется только в `PRIMARY` или `PROMOTED`-pile. Перевоз таблеток из `PRIMARY` в `PROMOTED` выполняется по возможности мягко, перевоз таблеток из `DISCONNECTED` в `PRIMARY` происходит максимально быстро. ## Поведение interconnect {#interconnect} В interconnect разделяются обмен метаданными и установка сессии. Обмен метаданными происходит до установления сессии и позволяет паре узлов определить используемый набор функций interconnect и обменяться конфигурацией. Interconnect с узлами из отключённой половины кластера разрывается, и попытки установления соединения не предпринимаются. Установление соединения возможно только после перевода pile в состояние `PRIMARY/NOT_SYNCHRONIZED`. {% note tip "Хотите присоединиться к команде разработки YDB?" %} Ознакомьтесь с разделами о [команде YDB и открытых вакансиях](https://ydb.tech/ru/careers/), а также о [возможностях для студентов](https://ydb.tech/ru/students/). {% endnote %}