Администрирование CockroachDB для распределённой SQL-базы

Администрирование CockroachDB для распределённой SQL-базы

Мы помогаем командам развернуть и обслуживать распределённую SQL-базу CockroachDB — PostgreSQL-совместимую, построенную на Raft-консенсусе. В отличие от Cassandra (eventual consistency) или MongoDB sharding, CockroachDB гарантирует ACID-транзакции на уровне всего кластера, даже между узлами разных регионов. Цена — сериализуемая изоляция требует round-trip между узлами для координации транзакций. Для write-heavy нагрузки с глобальным распределением это важное ограничение, которое мы учитываем при проектировании схемы.

Типичная проблема: разработчики переносят монолитную схему PostgreSQL и сталкиваются с неожиданными конфликтами транзакций из-за Raft-задержек. Или пытаются использовать автоинкремент — и получают hot spots на одном range. Мы решаем такие задачи на этапе аудита, экономя часы продакшен-инцидентов.

Наш опыт — 5+ лет работы с распределёнными СУБД, десятки проектов на CockroachDB. Предлагаем услугу «под ключ»: аудит текущей схемы, развёртывание кластера, настройка мониторинга и бэкапов. Сроки — от 2 до 5 дней на базовый кластер. Мы выполнили 30+ внедрений CockroachDB, включая мультирегиональные конфигурации с geo-partitioning.

Топология кластера и зоны

Минимальный production-кластер: 3 узла в одном регионе. Это вдвое повышает отказоустойчивость по сравнению с одиночной инстанцией — Raft требует кворум из 2/3. Для мультирегионального деплоя используем 3–5 узлов в каждом регионе. CockroachDB автоматически реплицирует ranges (по ~64 MB) согласно zone configurations.

Запуск ноды:

cockroach start \
    --certs-dir=/cockroach/certs \
    --store=/cockroach/data \
    --listen-addr=node1.internal:26257 \
    --advertise-addr=node1.internal:26257 \
    --http-addr=node1.internal:8080 \
    --join=node1.internal:26257,node2.internal:26257,node3.internal:26257 \
    --locality=region=us-east1,zone=us-east1-a \
    --background

--locality — ключевой параметр. CockroachDB использует эти метки для размещения реплик. Инициализация кластера (только один раз):

cockroach init --certs-dir=/cockroach/certs --host=node1.internal:26257 

Как настроить geo-partitioning для низкой задержки?

Zone configs определяют, где хранятся реплики для конкретной базы, таблицы или row. Пример настройки мультирегиональной репликации:

-- Репликация в трёх регионах с 5 репликами
ALTER DATABASE production CONFIGURE ZONE USING
  num_replicas = 5,
  constraints = '[+region=us-east1:2, +region=eu-west1:2, +region=ap-southeast1:1]',
  lease_preferences = '[[+region=us-east1]]';

lease_preferences определяет, в каком регионе держать leaseholder — узел, который обрабатывает reads без round-trip. Устанавливайте это в регион, откуда приходит большинство запросов на чтение.

Для таблиц с партиционированием по region можно pin-нуть данные конкретного региона к физическим узлам — это называется geo-partitioning. Читайте официальную документацию CockroachDB для деталей.

Мониторинг и диагностика

Admin UI на порту 8080 и метрики Prometheus на /_status/vars. Ключевые SQL-запросы:

-- Медленные запросы
SELECT query, count, mean, p99
FROM crdb_internal.node_statement_statistics
ORDER BY mean DESC
LIMIT 20;

-- Hot spots — ranges с высоким QPS
SELECT range_id, reads_per_second, writes_per_second
FROM crdb_internal.kv_node_status;

Hot spot — типичная проблема: sequential primary key (например, serial) создаёт один range. Решение — использовать UUID или gen_random_uuid() как primary key, либо настроить hash-шардирование.

Как избежать hot spots?

Лучший способ — избегать sequential primary keys. Используйте UUID v4 или gen_random_uuid(), который не создаёт упорядоченных ключей. Если таблица уже с serial, можно мигрировать на UUID или применить hash-индекс. Мониторинг ranges через crdb_internal.kv_node_status покажет, какие partitions перегружены. Zone configs с constraints помогают равномерно распределить нагрузку.

Backup и восстановление

-- Full backup в S3
BACKUP INTO 's3://my-bucket/backups/full?AUTH=implicit' AS OF SYSTEM TIME '-10s';
-- Restore
RESTORE FROM 's3://my-bucket/backups/full?AUTH=implicit';

CockroachDB поддерживает AS OF SYSTEM TIME — time travel queries до 25 часов назад.

Сравнение CockroachDB и PostgreSQL для глобальных приложений

Что входит в услугу

• Аудит существующей схемы и транзакций
• Развёртывание одно- или мультирегионального кластера
• Настройка TLS, zone configs, мониторинга (Prometheus + Grafana)
• Документация по эксплуатации и runbook
• Обучение команды (1–2 сессии)
• Сопровождение в течение первого месяца

Сроки ориентировочно

Стоимость рассчитывается индивидуально после анализа вашей архитектуры. Оценим проект — просто напишите нам в чат или по почте. Закажите аудит вашей схемы CockroachDB, чтобы избежать ошибок на старте.

Почему CockroachDB лучше PostgreSQL для глобальных приложений?

CockroachDB даёт ACID-транзакции на уровне всего кластера без необходимости ручного шардирования. В то время как PostgreSQL требует расширений и сложной настройки для мультирегиональной консистентности, CockroachDB решает это из коробки. При 3 узлах в разных регионах latency p99 для writes составляет около 5–15 мс, что в 2–3 раза ниже, чем при репликации PostgreSQL с синхронным коммитом.

Как мы работаем

1. Аудит — проверяем совместимость SQL и нагрузку.
2. Проектирование — выбираем топологию, настраиваем zone configs.
3. Развёртывание — запускаем кластер с TLS и мониторингом.
4. Тестирование — chaos testing: убиваем узлы, проверяем recovery.
5. Передача — документация и обучение.

Получите консультацию по вашему проекту — свяжитесь с нами.