Шардинг

Зачем нужны шарды

Каждая запись в Raft-группу проходит через её лидера. Пропускная способность одной группы ограничена скоростью записи на диск и вычислительные операции ее лидера. Шарды снимают это ограничение: у каждого шарда свой лидер, лидеры распределяются по нодам, и записи идут параллельно увеличивая пропускную способность и надежность кластера.

Шард — это Raft-группа данных плюс заказчики, которые ей принадлежат. Заказчик переносится на шард целиком:

Поэтому списание по цепочке «виртуальный ключ → команда → заказчик» остаётся одной атомарной записью на одном шарде.

Кластерная конфигурация с поддержкой фактора репликации меньше чем количество узлов будет поддержана в будущих релизах Meridian.

Страница Shards

Страница Cluster → Shards (/workspace/cluster/shards). Данные обновляются каждые 5 секунд, кнопка обновления рядом с Add запрашивает их сразу.

Список шардов

Левая панель — таблица шардов.

Щелчок по строке открывает шард в правой панели. Меню ⋯ в строке содержит действие Delete.

Карточка шарда

Правая панель — выбранный шард.

Ниже на карточке:

• Replicas — реплики шарда: Replica ID, Node, Role (voter или learner).
• Ownership — сколько на шарде заказчиков (Customers), команд (Teams) и виртуальных ключей (Virtual keys).
• Migrations — миграции, в которых участвует шард: направление (на шард или с шарда), заказчик, откуда и куда, фаза, возраст. Метка stuck отмечает зависшую миграцию.

Добавление шарда

Что происходит дальше:

1. Кластер сохраняет новую версию топологии. Шард размещается на активных нодах, но не больше max_replicas из правила размещения.
2. Лидер _meta в фоне создаёт Raft-группу на выбранных нодах.
3. Когда версия становится Active, шард появляется в маршрутизации и готов принимать заказчиков.

Сразу после создания в поле Quorum может стоять —: группа ещё собирается. Через несколько секунд там появится число живых реплик.

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

Типичные ошибки:

Удаление шарда

⋯ → Delete в строке шарда. Удаление отклоняется, если:

• это shard0;
• на шарде есть заказчики — сначала перенесите их на другие шарды;
• шард участвует в незавершённой миграции.

Удаление останавливает реплики на всех нодах и удаляет данные шарда. Вернуть удалённый шард можно только созданием нового и переносом заказчиков. Для удаления нужно право cluster.shard.delete.

Статусы шардов

Состояние шарда складывается из трёх независимых признаков.

Состояние в документе — колонка State

Здоровье группы — поле Quorum

Здоровье пересчитывается каждые 5 секунд по данным gossip о живых нодах. Кворум — voters / 2 + 1.

Локальная реплика на ноде

Нода может не запустить свою реплику шарда. Такое состояние видно в поле local_replica ответа GET /api/cluster/v1/shards/{shard_id} и в local_shards ответа GET /api/cluster/v1/status.

Reseat выдаёт реплике новый идентификатор, и кворум заново реплицирует её данные:

curl -X POST http://localhost:8080/api/cluster/v1/groups/shard1/replicas/node2/reseat

Операция необратима: данные старой реплики отбрасываются.

Миграция заказчика между шардами

Миграция переносит заказчика на другой шард вместе с командами, виртуальными ключами, бюджетами и rate limit'ами.

Когда нужна:

• Балансировка. Заказчик с высокой нагрузкой переезжает на свежий шард.
• Изоляция. Важный заказчик получает отдельный шард.
• Удаление шарда. Перед удалением все заказчики переносятся на другие шарды.

Запуск миграции

Миграция запускается со страницы заказчика, а не со страницы Shards.

Кнопка Migrate недоступна, если у заказчика уже идёт миграция, нет подходящего шарда назначения или нет права cluster.shard.migrate.

Отслеживание

Прогресс виден на странице Shards в блоке Migrations карточки шарда — исходного или шарда назначения. Строка показывает фазу и возраст миграции. Страница заказчика тоже показывает, что миграция идёт и в какой она фазе.

Пока миграция не завершена:

• изменения заказчика, его команд и виртуальных ключей отклоняются с кодом 409 — повторите их после завершения; чтение работает;
• исходный шард и шард назначения нельзя удалить;
• для этого заказчика нельзя запустить вторую миграцию. Разные заказчики мигрируют параллельно.

Фазы миграции

Перенос разбит на группы: по одной на каждую команду заказчика и одна на сам заказчик. Миграция переходит в следующую фазу, когда её достигли все группы.

Метка stuck появляется, если миграция не завершилась за 30 минут.

Если миграция зависла или упала

Кластер сам повторяет незавершённые миграции: каждые 30 секунд он продолжает до 10 миграций, которые не продвигались дольше 30 секунд. Каждый шаг идемпотентен, повтор безопасен. Текст последней ошибки хранится в поле error_message миграции.

В интерфейсе нет кнопок отмены и повтора — используйте API:

# Повторить с текущей фазы
curl -X POST http://localhost:8080/api/cluster/v1/migrations/{migration_id}/retry

# Отменить (до snapshotted включительно)
curl -X POST http://localhost:8080/api/cluster/v1/migrations/{migration_id}/abort

# Аварийная отмена (до applied включительно)
curl -X POST "http://localhost:8080/api/cluster/v1/migrations/{migration_id}/abort?force=true"

После published отменить миграцию нельзя. Чтобы вернуть заказчика, запустите обратную миграцию. История завершённых миграций хранится 30 дней.

API

Создание и удаление шарда требуют заголовка If-Match с текущей Latest-версией топологии: без него — 428, с устаревшей версией — 412. Параметр dry_run=true возвращает план без изменений. Миграции недоступны без PostgreSQL: сервер отвечает 501.

Полная спецификация — в справочнике API.