Всплески задержек репликации при перебалансировке шардов #5

New Issue

2026-08-17T21:21:30Z

gvsafronov commented

2026-08-17 21:21:30 +00:00

Проблема

ReshardingManager в raft_coordinator.go выполняет перераспределение шардов при изменении состава кластера. Репликация данных во время перешардирования использует тот же механизм, что и обычная репликация (NetworkReplicator), что приводит к ряду проблем, связанных с деградацией производительности.

Возникает амплификация записи, поскольку данные миграции конкурируют с операциями обычной рабочей нагрузки. Задержки на хвосте распределения (p95/p99) значительно возрастают в периоды миграции. Сетевые и дисковые ресурсы перегружаются, так как трафик миграции и производственный трафик используют одну и ту же инфраструктуру. В крупных кластерах с миллионами документов это может приводить к падению QPS до 40% и росту задержек с 50 мс до более чем 350 мс.

Архитектурная проблема

Как минимизировать влияние перебалансировки шардов на производственные операции в распределённой системе баз данных?

Пример сценария

Рассмотрим кластер из 3 узлов, в который добавляется 4-й узел. ReshardingManager инициирует перераспределение 1 миллиона документов. В процессе миграции наблюдаются следующие симптомы:

QPS падает на 40% относительно базового уровня
P99 задержка возрастает с 50 мс до 350 мс
Использование сети возрастает с 20% до 80%
Время ожидания дискового ввода-вывода увеличивается на 300%

Основная причина — отсутствие приоритизации трафика: трафик миграции обрабатывается с тем же приоритетом, что и пользовательские запросы, что вызывает конкуренцию за ресурсы и влияет на все операции.

Предлагаемые направления исследований

Репликация на основе приоритетов — реализация отдельных очередей с приоритетами для миграции и обычных операций с регулированием трафика, чтобы пользовательские запросы получали более высокий приоритет.
AIMD-регулирование — использование управления перегрузками с аддитивным увеличением и мультипликативным уменьшением (AIMD), аналогично TCP, где скорость миграции постепенно увеличивается до обнаружения перегрузки, а затем мультипликативно уменьшается.
Миграция с копированием при записи (Copy-on-Write) — использование снимков с копированием при записи для предотвращения блокировки операций во время миграции.
Прогнозируемое планирование — прогнозирование паттернов нагрузки и планирование миграций в периоды низкого трафика.
Инкрементальная перебалансировка — перемещение данных небольшими пакетами с обнаружением обратного давления (backpressure), позволяющее приостанавливать и возобновлять процесс.
Изоляция ресурсов — использование ограничителей скорости, отдельных пулов потоков или контроллеров пропускной способности дискового ввода-вывода для изоляции трафика миграции.

Соответствующие файлы с исходным кодом

internal/cluster/raft_coordinator.go (ReshardingManager, строки 2100–2400)
internal/cluster/network_replicator.go (NetworkReplicator, строки 100–300)
internal/cluster/raft_coordinator.go (ReshardingMetrics)

**Проблема** ReshardingManager в raft_coordinator.go выполняет перераспределение шардов при изменении состава кластера. Репликация данных во время перешардирования использует тот же механизм, что и обычная репликация (NetworkReplicator), что приводит к ряду проблем, связанных с деградацией производительности. Возникает амплификация записи, поскольку данные миграции конкурируют с операциями обычной рабочей нагрузки. Задержки на хвосте распределения (p95/p99) значительно возрастают в периоды миграции. Сетевые и дисковые ресурсы перегружаются, так как трафик миграции и производственный трафик используют одну и ту же инфраструктуру. В крупных кластерах с миллионами документов это может приводить к падению QPS до 40% и росту задержек с 50 мс до более чем 350 мс. **Архитектурная проблема** Как минимизировать влияние перебалансировки шардов на производственные операции в распределённой системе баз данных? **Пример сценария** Рассмотрим кластер из 3 узлов, в который добавляется 4-й узел. ReshardingManager инициирует перераспределение 1 миллиона документов. В процессе миграции наблюдаются следующие симптомы: - QPS падает на 40% относительно базового уровня - P99 задержка возрастает с 50 мс до 350 мс - Использование сети возрастает с 20% до 80% - Время ожидания дискового ввода-вывода увеличивается на 300% Основная причина — отсутствие приоритизации трафика: трафик миграции обрабатывается с тем же приоритетом, что и пользовательские запросы, что вызывает конкуренцию за ресурсы и влияет на все операции. **Предлагаемые направления исследований** 1. **Репликация на основе приоритетов** — реализация отдельных очередей с приоритетами для миграции и обычных операций с регулированием трафика, чтобы пользовательские запросы получали более высокий приоритет. 2. **AIMD-регулирование** — использование управления перегрузками с аддитивным увеличением и мультипликативным уменьшением (AIMD), аналогично TCP, где скорость миграции постепенно увеличивается до обнаружения перегрузки, а затем мультипликативно уменьшается. 3. **Миграция с копированием при записи (Copy-on-Write)** — использование снимков с копированием при записи для предотвращения блокировки операций во время миграции. 4. **Прогнозируемое планирование** — прогнозирование паттернов нагрузки и планирование миграций в периоды низкого трафика. 5. **Инкрементальная перебалансировка** — перемещение данных небольшими пакетами с обнаружением обратного давления (backpressure), позволяющее приостанавливать и возобновлять процесс. 6. **Изоляция ресурсов** — использование ограничителей скорости, отдельных пулов потоков или контроллеров пропускной способности дискового ввода-вывода для изоляции трафика миграции. **Соответствующие файлы с исходным кодом** - `internal/cluster/raft_coordinator.go` (ReshardingManager, строки 2100–2400) - `internal/cluster/network_replicator.go` (NetworkReplicator, строки 100–300) - `internal/cluster/raft_coordinator.go` (ReshardingMetrics)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#5