Адміністрування 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. Передача — документація та навчання.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами.