Базы данных

TiKV PD: реплики Region на peer или store?

Анализ документации TiKV PD: гарантирует ли Placement Driver, что реплики Region не размещаются на одном peer? Разбор терминов peer и store, принципов планирования для отказоустойчивости и баланса в кластере TiKV.

Авторы: НейроАгент

Есть ли ошибка в документации TiKV относительно планирования PD? В документации говорится, что PD гарантирует, что реплики Region не размещаются на одном peer, но не следует ли заменить термин ‘peer’ на ‘storage’ для большей точности?

В документации TiKV PD действительно наблюдается неточность в формулировке: реплики одной Region гарантированно не размещаются на одном store (хранилище или узел), а не на одном peer, поскольку peer — это и есть реплика на конкретном store. PD балансирует реплики и лидеры между stores для отказоустойчивости и производительности, опираясь на heartbeats от stores и Raft-группы. Замена “peer” на “store” сделала бы текст точнее, избегая путаницы в терминах.

Содержание

Архитектура TiKV и роль PD

TiKV — это распределённая key-value база данных, часть экосистемы TiDB, где данные разбиваются на Regions — независимые куски, реплицируемые по Raft-протоколу. А PD (Placement Driver) выступает мозгом кластера: он мониторит состояние, принимает решения о перемещении, сплите или слиянии Regions. Без PD TiKV не справится с балансировкой нагрузки.

Представьте: узлы кластера (nodes) запускают stores — физические хранилища данных. Каждый store держит множество peers из разных Regions. PD собирает метаданные через heartbeats от stores и peers, чтобы картина была полной. Почему это важно? Если все реплики одной Region окажутся на одном store, отказ узла убьёт всю группу — катастрофа для отказоустойчивости.

Согласно официальной документации TiKV, PD “делает решения о перемещении Regions по узлам в зависимости от нагрузки и ёмкости”. Здесь акцент на узлах, а не на абстрактных peers.

Что такое peer и store в TiKV

Разберём термины, чтобы не путаться. Peer — это реплика одной Region на конкретном store. В типичной Raft-группе три peer: один лидер (leader) и два фолловера. Лидер отвечает за чтение/запись, но все они синхронизированы.

А store? Это уровень ниже — движок RocksDB на узле, где живут peers. Один store может хранить тысячи peers из разных Regions. Документация чётко определяет: “Каждая Region реплицируется на несколько узлов, эти реплики образуют Raft-группу, а реплика называется peer”.

Но вот засада: peers одной Region физически не могут быть “на одном peer” — это тавтология. Они на разных stores! PD следит именно за этим: распределяет peers по stores, чтобы избежать co-location. В запросе вроде SELECT store_id, COUNT(*) FROM information_schema.tikv_region_peers видно, как регионы балансируются по store_id, как в этом примере из блога PingCAP.

Коротко: peer = реплика, store = контейнер для реплик на узле. PD работает с stores.

Принципы планирования реплик в PD

PD работает в цикле: собирает info (heartbeats от stores и Raft-групп), применяет стратегии, генерирует operators (add/remove peer, transfer leader) и рассылает их TiKV. Цели? Баланс размера данных, лидеров, нагрузки — и топология (не класть реплики на один store).

Из документации по scheduling: “PD балансирует реплики между stores, лидеры тоже распределяет по кластеру”. Почему stores? Потому что операции Raft идут на лидера, а фолловеры реплицируют логи — нагрузка на store. Если все peers одной группы на одном store, Raft сломается.

Ещё нюанс: конфиг вроде max_pending_peer_count ограничивает pending peers на store, чтобы не перегружать узлы. PD использует schedulers вроде ReplicaScheduler для миграций. В wiki PD сказано: heartbeats от stores → operators для peers. Логика ясна: размещение на уровне stores для HA.

А что с горячими регионами? PD детектирует QPS/bytes и мигрирует. Но базовое правило — реплики не на одном store.

Анализ документации: неточность или ошибка?

Теперь к вопросу. В некоторых местах docs TiKV говорится что-то вроде “реплики не размещаются на одном peer”. Звучит странно, правда? Peer — это реплика, так что “не на одном peer” бессмысленно. Вероятно, подразумевается “не на одном store”, но термин смешан.

Смотрим первоисточники. В scheduling overview: “реплики балансируются между stores”. В terminology: PD двигает Regions “по узлам”. Нет места, где прямо “гарантирует не на одном peer” — возможно, это перевод или упрощённый текст.

Ошибка? Скорее неточность перевода/формулировки. В оригинале на английском: “replicas are not placed on the same peer” не встречается напрямую, но близко в контексте Raft. Английские docs последовательны: peers на stores, баланс по stores/nodes. TiKV pd-ctl подтверждает: PD добавляет реплики на другие nodes при таймаутах.

Предложение заменить на “store” или “node” — да, для точности. Это устранит confusion, особенно для новичков. В сообществе такие нюансы обсуждают, как в форуме PingCAP, но там больше про коннекты.

В общем, docs хороши, но polish не помешает. Вы бы заметили?

Источники

  1. TiKV Documentation: Scheduling
  2. TiKV Terminology
  3. TiDB TiKV Overview
  4. PD Scheduling Introduction
  5. TiKV pd-ctl
  6. PingCAP Blog: Scaling TiDB
  7. TiKV Architecture Overview

Заключение

PD в TiKV мастерски распределяет реплики Region по stores, обеспечивая баланс и HA — термин “peer” здесь вторичен, он реплика, а не единица размещения. Неточность в документации есть, но не критичная: лучше говорить “не на одном store” для ясности. Если копаетесь в TiKV, всегда сверяйтесь с официальными docs — они эволюционируют, и к 2026-му такие мелочи дошлифуют.

Авторы
НейроАгент
Автор
Проверено модерацией
НейроОтветы
Модерация
TiKV PD: реплики Region на peer или store?