Конфигурирование подсистем распространения метаданных State Storage, Board, Scheme Board

Применяется если нужно изменить конфигурацию подсистем распространения метаданных состоящую из State Storage, Board, Scheme Board, на кластере YDB.

При использовании конфигурации V2 подсистемы распространения метаданных частично поддерживаются автоматически за счёт механизма Self Heal — см. Self Heal State Storage (перенос и добавление реплик при изменениях топологии). Чтобы отключить это поведение, установите state_storage_self_heal_config.enable в false, как описано в том же разделе. Отключение не обязательно для нижеприведённых шагов: конфигурация после ydb admin cluster config replace применится до очередного срабатывания автоматики.

Важно

Ошибка в конфигурации подсистем распространения метаданных (в том числе в секции domains_config) или неправильная последовательность изменений могут привести к недоступности кластера YDB.

Для ручного изменения конфигурации State Storage в кластере YDB необходимо выполнить следующие шаги.

  1. Получить текущую конфигурацию кластера с помощью команды ydb admin cluster config fetch:
  ydb [global options...] admin cluster config fetch --v2-internal-state > config.yaml

В результате выполнения данной команды текущая конфигурация будет сохранена в файле config.yaml

  1. Внести требуемые изменения в секции domains_config конфигурационного файла config.yaml:
    Правила изменения секции domains_config см. в разделе Правила конфигурирования State Storage.

  2. Применить новую конфигурацию кластера с помощью ydb admin cluster config replace:

ydb [global options...] admin cluster config replace -f config.yaml

Правила конфигурирования State Storage

Перечисленные ниже правила применяются к state_storage и к раздельным полям explicit_state_storage_config, explicit_state_storage_board_config, explicit_scheme_board_config в секции domains_config файла config.yaml (см. Конфигурация State Storage). Ключи explicit_* соответствуют по отдельности State Storage, Board и Scheme Board.

Под кольцом в конфигурации понимается блок ring внутри элемента списка ring_groups (см. Конфигурация State Storage).

Изменение конфигурации производится в несколько шагов. Сначала добавляется новая группа колец, состоящая из правильно выбранных узлов (в соответствии с моделью отказа), а затем старая группа колец удаляется.

Чтобы избежать недоступности кластера, удаление и добавление групп колец выполняйте строго в последовательности шагов, описанной ниже.

  1. Чтобы изменить конфигурацию подсистем распространения метаданных без недоступности кластера необходимо производить это путем добавления и удаления групп колец.

  2. Добавлять и удалять можно только группы колец с параметром WriteOnly: true.

  3. В новой конфигурации всегда должна присутствовать хотя бы одна группа колец из предыдущей конфигурации без параметра WriteOnly. Такая группа колец должна идти первой в списке.

  4. Если в разных группах колец используются одни и те же узлы кластера, добавьте параметр ring_group_actor_id_offset:1 к группе колец. Значение должно быть уникальным среди групп колец.

    Этот параметр сделает уникальными идентификаторы реплик в данной группе колец, они не будут совпадать с идентификаторами из других групп, и это позволит разместить на одном узле кластера несколько реплик одного типа.

  5. Переход к новой конфигурации выполняется за 4 последовательных шага. На каждом шаге подготавливается новая конфигурация и применяется к кластеру.

    Только что созданные или готовые к удалению группы колец помечаются флагом WriteOnly: true. Это необходимо, чтобы запросы на чтение обрабатывались уже развернутой группой колец, пока новая конфигурация распространится на необходимое количество узлов, создадутся новые реплики или удалятся старые.

    Поэтому между шагами необходимо делать паузу как минимум в 1 минуту.

    • Добавляем новую группу колец с параметром WriteOnly: true соответствующую целевой конфигурации.
    • Снимаем флаг WriteOnly.
    • Выставляем флаг WriteOnly: true на группу колец соответствующую старой конфигурации, новую группу колец переносим в начало списка групп колец.
    • Удаляем старую группу колец.

Пример

Рассмотрим на примере текущей конфигурации:

config:
  domains_config:
    explicit_scheme_board_config:
      ring:
        nto_select: 5
        node: [1,2,3,4,5,6,7,8]

и целевой конфигурации:

config:
  domains_config:
    explicit_scheme_board_config:
      ring:
        nto_select: 5
        node: [10,20,30,40,5,6,7,8]

Мы хотим перенести часть реплик на другие узлы кластера.

Шаг 1
На первом шаге подготовьте ring_groups, следуя правилам конфигурирования: первая группа колец совпадает с текущей конфигурацией из листингов выше, вторая — с целевой и помечена WriteOnly: true. Параметр ring_group_actor_id_offset указывайте так, как описано в тех же правилах, если наборы узлов у групп совпадают.

config:
  domains_config:
    explicit_scheme_board_config:
      ring_groups:
        - ring:
          nto_select: 5
          node: [1,2,3,4,5,6,7,8]
        - ring:
          nto_select: 5
          node: [10,20,30,40,5,6,7,8]
          write_only: true
          ring_group_actor_id_offset: 1

Шаг 2
Снимаем флаг WriteOnly.

config:
  domains_config:
    explicit_scheme_board_config:
      ring_groups:
        - ring:
          nto_select: 5
          node: [1,2,3,4,5,6,7,8]
        - ring:
          nto_select: 5
          node: [10,20,30,40,5,6,7,8]
          ring_group_actor_id_offset: 1

Шаг 3
Делаем новую группу колец первой в списке. На старую конфигурацию выставляем флаг WriteOnly: true

config:
  domains_config:
    explicit_scheme_board_config:
      ring_groups:
        - ring:
          nto_select: 5
          node: [10,20,30,40,5,6,7,8]
          ring_group_actor_id_offset: 1
        - ring:
          nto_select: 5
          node: [1,2,3,4,5,6,7,8]
          write_only: true

Шаг 4
Применяем на кластере целевую конфигурацию:

config:
  domains_config:
    explicit_scheme_board_config:
      ring_groups:
        - ring:
          nto_select: 5
          node: [10,20,30,40,5,6,7,8]
          ring_group_actor_id_offset: 1

Проверка результата

Проверить, что изменения применились, можно в разделе CMS в Embedded UI кластера (доступен на порту 8765): перейдите на вкладку Tablets и убедитесь по репликам таблеток подсистем метаданных, что конфигурация подхватилась.