TiDB: распределённая HTAP-база с MySQL-протоколом

TiDB — распределённая база данных, которая говорит по протоколу MySQL и умеет одновременно обслуживать транзакционную нагрузку и аналитические запросы. Внутри это набор компонентов: SQL-слой TiDB, распределённое key-value-хранилище TiKV, планировщик размещения PD и колоночный TiFlash для HTAP. В статье соберём стенд, подключимся mysql-клиентом, включим колоночную реплику и разберём, что проверять в эксплуатации.

Архитектура без магии

TiDB не хранит данные сама: она принимает SQL, строит план и обращается к TiKV по ключам. TiKV раскладывает диапазоны ключей на регионы, реплицирует их через Raft и хранит на RocksDB. PD следит за метаданными, балансирует регионы и выдаёт глобальные метки времени. TiFlash — отдельный колоночный движок, который получает изменения через Raft и позволяет считать агрегаты, не нагружая строковое хранилище.

Такая схема даёт горизонтальное масштабирование и отказоустойчивость, но добавляет сетевые задержки и требования к эксплуатации. Это не «MySQL, только быстрее»: часть возможностей отсутствует, а поведение блокировок отличается, поэтому перед миграцией проверяйте совместимость на своих запросах.

Быстрый стенд через TiUP

TiUP — официальный менеджер компонентов. Для локальной проверки хватит одной команды playground, которая поднимает временный кластер в отдельных процессах:

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bashrc
tiup playground --db 1 --pd 1 --kv 3 --tiflash 1 --monitor

Playground печатает порты: SQL на 4000, dashboard на 2379, Grafana на 3000. Данные живут во временном каталоге и исчезают после остановки. Для стенда на неделю это удобно, для проверки отказоустойчивости — нет: процессы не переживут перезагрузку и не дадут настоящего распределения по машинам.

Подключение и первые запросы

Клиент MySQL подключается к порту 4000. В playground пользователь root без пароля, в production так делать нельзя:

mysql -h 127.0.0.1 -P 4000 -u root
CREATE DATABASE shop;
USE shop;
CREATE TABLE orders (id BIGINT PRIMARY KEY AUTO_INCREMENT, region VARCHAR(32), total DECIMAL(12,2), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP);
INSERT INTO orders (region, total) VALUES ('msk', 1200.50), ('spb', 800.00), ('msk', 430.10);
SELECT region, SUM(total) FROM orders GROUP BY region;

Синтаксис знакомый, но не все возможности MySQL реализованы одинаково. Проверяйте хранимые процедуры, триггеры, сложные блокировки и поведение AUTO_INCREMENT на своих сценариях. Для приложения важны параметры подключения: parseTime=true, корректный charset и пул соединений с ограничением времени ожидания.

HTAP: колоночная реплика TiFlash

Аналитика по большим таблицам на строковом движке конкурирует с транзакциями. TiFlash хранит копию таблицы в колоночном формате и умеет читать её изолированно. Включается на уровне таблицы:

ALTER TABLE orders SET TIFLASH REPLICA 1;
SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'shop';
SET SESSION tidb_isolation_read_engines = 'tiflash';
EXPLAIN ANALYZE SELECT region, SUM(total) FROM orders GROUP BY region;

Реплика появляется не мгновенно: дождитесь AVAILABLE = 1. Затем сравните план до и после переключения движка. Если TiFlash не используется, проверьте, что таблица не слишком маленькая для выбора колоночного пути и что статистика собрана. Не включайте TiFlash на все таблицы подряд: каждая реплика занимает диск и добавляет нагрузку на репликацию.

Кластер и конфигурация

Для нескольких машин используется topology.yaml и команда tiup cluster. Версию берите из tiup list tidb, а не из памяти. Минимальный пример для четырёх машин:

global:
  user: tidb
  ssh_port: 22
  deploy_dir: /data/tidb

server_configs:
  tidb:
    log.slow-threshold: 300
    performance.max-procs: 8
  tikv:
    raftstore.store-pool-size: 4

tidb_servers:
  - host: 10.0.0.11
tikv_servers:
  - host: 10.0.0.12
  - host: 10.0.0.13
  - host: 10.0.0.14
pd_servers:
  - host: 10.0.0.11

Разворачивание и проверка статуса:

VERSION=$(tiup list tidb | awk '/LTS/ {print $1; exit}')
tiup cluster check ./topology.yaml --user root -p --apply
tiup cluster deploy prod "$VERSION" ./topology.yaml --user root -p
tiup cluster start prod
tiup cluster display prod

check --apply помогает привести лимиты, swap и параметры ядра к требованиям, но перед production-запуском прочитайте, что именно меняется. Для Kubernetes есть TiDB Operator, однако он добавляет свой слой сложности: начинайте с ручного кластера, чтобы понимать, что происходит внутри.

Резервное копирование

Логический дамп подходит для небольших баз и переноса, физическое резервное копирование — для больших объёмов. Инструмент BR работает с PD и сохраняет согласованную копию:

tiup install br dumpling
br backup full --pd "127.0.0.1:2379" --storage "local:///backup/full" --ratelimit 128
dumpling -h 127.0.0.1 -P 4000 -u root -o /backup/dump --filetype sql
br restore full --pd "127.0.0.1:2379" --storage "local:///backup/full"

Проверяйте восстановление на отдельном стенде, а не только наличие файлов. Для S3-совместимого хранилища используйте s3:// и настройте доступ через переменные окружения, не храня ключи в командной строке. Учитывайте, что br restore меняет целевой кластер, поэтому проверяйте его на отдельном стенде.

Диагностика и ограничения

Наблюдаемость в TiDB хорошая, если ей пользоваться. Встроенные таблицы information_schema.cluster_info, cluster_config и slow_query показывают состояние узлов, расхождения конфигурации и медленные запросы. В Grafana смотрите latency, количество регионов, размер очередей Raft и ошибки PD. Для диагностики:

• ADMIN SHOW DDL JOBS; — зависшие схемные изменения;
• SELECT * FROM information_schema.slow_query ORDER BY query_time DESC LIMIT 10; — тяжёлые запросы;
• SELECT * FROM information_schema.tikv_store_status; — состояние хранилищ;
• логи компонентов через tiup cluster display и каталог deploy_dir.

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

Чек-лист

• Версия TiDB зафиксирована и совпадает на всех узлах.
• PD и TiKV размещены на разных машинах, диск быстрый и отдельный.
• Настроены лимиты памяти, slow log и мониторинг.
• TiFlash включён только для таблиц, где есть аналитика.
• Есть проверенный план резервного копирования и восстановления.
• Приложение протестировано на совместимость с MySQL-протоколом.

Итог

TiDB закрывает сценарий, где транзакции и аналитика должны жить рядом, а база растёт горизонтально. Начните с playground, затем соберите небольшой кластер через TiUP, включите TiFlash на одной таблице и сравните планы. И только после этого переносите боевую нагрузку: распределённая система прощает меньше ошибок в конфигурации, чем одиночный MySQL.