"CockroachDB: установка на VPS"

MAATRIX

Если вы привыкли к PostgreSQL, но хотите базу, спроектированную с расчётом на отказ отдельных узлов и горизонтальное масштабирование без ручного шардирования — CockroachDB стоит попробовать. Она говорит на языке PostgreSQL-протокола, так что почти весь ваш инструментарий (psql, драйверы, ORM) заработает без переделок. Ниже — рабочая установка на одном VPS: от скачивания бинарника до первого подключения и честного разговора о том, когда single-node режима достаточно, а когда пора думать о кластере.

Что такое CockroachDB и когда она нужна на VPS

CockroachDB — распределённая SQL-база с открытым кодом (BUSL-лицензия для части возможностей enterprise-уровня, но core-функциональность свободна). Название не случайно: разработчики закладывали в неё живучесть — база должна продолжать отвечать на запросы, даже если часть узлов кластера упала, как таракан переживает то, что не переживают другие.

Ключевые особенности:

• PostgreSQL-совместимый протокол — подключаетесь через psql, pgAdmin, любой Postgres-драйвер на Python/Go/Node/Java. Диалект SQL близок, но не идентичен — часть синтаксиса и функций отличается.
• Автоматическое шардирование данных (диапазоны, range) и репликация между узлами кластера — без ручного партиционирования таблиц.
• Строгая консистентность (serializable isolation по умолчанию) — не eventual consistency, как у многих NoSQL-решений.
• Встроенная веб-консоль для мониторинга состояния кластера, запросов, использования диска.

На один VPS её ставят в трёх случаях: разработка и тестирование перед раскаткой на кластер, изучение продукта перед покупкой managed-варианта (CockroachDB Cloud), или небольшой внутренний сервис, где распределённость пока не нужна, но хочется путь для будущего роста без смены СУБД. Если нужна классическая реляционная база без этих задач — присмотритесь к обычному PostgreSQL на VPS, он проще в эксплуатации и требует меньше ресурсов.

Требования к серверу и подготовка

CockroachDB не самая лёгкая база — рекомендации разработчиков начинаются от 4 vCPU и 8 ГБ RAM даже для одного узла, хотя для теста реально завести и на 2 vCPU / 4 ГБ. Диск — обязательно SSD или NVMe, на HDD движок будет упираться в задержки записи WAL.

Что нужно перед установкой:

• VPS на Linux (Ubuntu 22.04/24.04 или Debian 12 — самые предсказуемые варианты);
• пользователь с sudo-правами, отдельный от root;
• открытые порты 26257 (SQL и внутрикластерный трафик) и 8080 (веб-консоль) — но открывать их наружу без ограничений не стоит, ниже покажу как ограничить доступ через firewall;
• NTP-синхронизация времени — CockroachDB чувствительна к рассинхрону часов между узлами (в кластере это критично, на одном узле менее важно, но лучше сразу настроить правильно).

Проверьте и включите синхронизацию времени:

sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony
timedatectl

Если планируете VPS в России с оплатой картой или криптовалютой — берите тариф с NVMe-диском и минимум 8 ГБ RAM, экономия на памяти здесь быстро выливается в тормоза при первых же аналитических запросах.

Установка бинарника CockroachDB

Официальный способ — скачать статически собранный бинарник, никаких пакетных менеджеров с сомнительными версиями:

curl https://binaries.cockroachdb.com/cockroach-latest.linux-amd64.tgz \
  | tar -xz

sudo cp -i cockroach-*.linux-amd64/cockroach /usr/local/bin/

# опционально: библиотеки геопространственных функций
sudo mkdir -p /usr/local/lib/cockroach
sudo cp -i cockroach-*.linux-amd64/lib/libgeos.so /usr/local/lib/cockroach/
sudo cp -i cockroach-*.linux-amd64/lib/libgeos_c.so /usr/local/lib/cockroach/

Проверьте, что бинарник рабочий:

cockroach version

Команда должна вывести номер версии сборки и дату компиляции. Если хотите зафиксировать конкретную версию вместо latest (разумно для продакшена, чтобы не словить неожиданный мажорный апгрейд) — замените cockroach-latest в URL на конкретный тег, например cockroach-v24.1.5, актуальный список версий смотрите на странице релизов CockroachDB.

Создайте отдельного пользователя и каталог для данных — не запускайте базу от root:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin cockroach
sudo mkdir -p /var/lib/cockroach
sudo chown cockroach:cockroach /var/lib/cockroach

Запуск в single-node режиме и автозапуск через systemd

Для старта — вместо разворачивания полноценного трёхузлового кластера с сертификатами — используйте команду start-single-node. Она поднимает один узел, который сам себе и кластер:

cockroach start-single-node \
  --insecure \
  --store=/var/lib/cockroach \
  --listen-addr=localhost:26257 \
  --http-addr=localhost:8080 \
  --background

Флаг --insecure отключает TLS и аутентификацию по сертификатам — это нормально для локальной разработки, но для сервера, который слушает не только localhost, недопустимо: без сертификатов любой, кто достучится до порта 26257, получит доступ к данным без пароля. Для сервера, доступного снаружи, поднимайте secure-режим с собственным CA:

mkdir certs my-safe-directory
cockroach cert create-ca --certs-dir=certs --ca-key=my-safe-directory/ca.key
cockroach cert create-node localhost <ip-сервера> \
  --certs-dir=certs --ca-key=my-safe-directory/ca.key
cockroach cert create-client root \
  --certs-dir=certs --ca-key=my-safe-directory/ca.key

cockroach start-single-node \
  --certs-dir=certs \
  --store=/var/lib/cockroach \
  --listen-addr=0.0.0.0:26257 \
  --http-addr=0.0.0.0:8080 \
  --background

Дальше оформите запуск как systemd-сервис, чтобы база поднималась после перезагрузки сервера:

# /etc/systemd/system/cockroachdb.service
[Unit]
Description=CockroachDB single-node
After=network.target

[Service]
Type=forking
User=cockroach
ExecStart=/usr/local/bin/cockroach start-single-node \
  --certs-dir=/var/lib/cockroach/certs \
  --store=/var/lib/cockroach/data \
  --listen-addr=0.0.0.0:26257 \
  --http-addr=0.0.0.0:8080 \
  --background
ExecStop=/usr/local/bin/cockroach quit \
  --certs-dir=/var/lib/cockroach/certs --host=localhost:26257
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now cockroachdb
sudo systemctl status cockroachdb

Не забудьте ограничить доступ к портам через firewall — открывать 26257 и 8080 всему интернету не стоит даже в secure-режиме:

sudo ufw allow from <ваш-ip> to any port 26257
sudo ufw allow from <ваш-ip> to any port 8080
sudo ufw enable

Подключение: psql, ORM, веб-консоль на порту 8080

Первое, что стоит сделать после старта — создать пользователя базы данных вместо использования встроенного root для приложений:

cockroach sql --certs-dir=certs --host=localhost:26257

CREATE USER app_user WITH PASSWORD 'смените-меня';
CREATE DATABASE app_db;
GRANT ALL ON DATABASE app_db TO app_user;

Дальше подключение — обычным psql, потому что протокол PostgreSQL-совместимый:

psql "postgresql://app_user:пароль@server-ip:26257/app_db?sslmode=require"

Из Python (через psycopg2 или SQLAlchemy) строка подключения выглядит так же, как для PostgreSQL, меняется только порт:

import psycopg2
conn = psycopg2.connect(
    "postgresql://app_user:пароль@server-ip:26257/app_db?sslmode=require"
)

Веб-консоль по умолчанию слушает порт 8080 — откройте https://server-ip:8080 (или http://, если запускали в insecure-режиме) в браузере. Там видно состояние узла, распределение диапазонов данных (ranges), активные запросы, использование диска и памяти. Для одного узла большинство графиков репликации будут показывать предупреждения — это нормально, ниже объясню почему.

Если параллельно держите аналитическую нагрузку, полезно свериться со статьёй ClickHouse или PostgreSQL для аналитики — CockroachDB заточена под транзакционную нагрузку (OLTP), а не под тяжёлую аналитику по колонкам.

От single-node к кластеру: честные ограничения

Здесь важно не обмануть себя маркетингом. Как и с Cassandra, вся сила CockroachDB — в кластере из нескольких нод: автоматическая репликация данных между узлами, переживание падения отдельной машины без потери доступности, распределение нагрузки чтения между репликами. Single-node режим — это фактически обычная реляционная база без единого из этих преимуществ, только с накладными расходами распределённого движка поверх.

Что это означает на практике:

• Отказоустойчивости нет. Если единственный узел упал или диск сломался — база недоступна, ровно как и с любой другой СУБД на одном сервере. Регулярные бэкапы обязательны.
• Replication factor по умолчанию — 3, но реплицировать данные некуда, если узел один: в консоли будете видеть warning об under-replicated ranges. Это ожидаемо, не баг.
• Оверхед на служебные процессы (range splitting, распределённый консенсус Raft даже внутри одного узла) отъедает ресурсы, которые классический PostgreSQL потратил бы на полезную работу.

Когда данных и нагрузки становится больше, следующий шаг — не апгрейд тарифа одного VPS, а добавление узлов: минимум 3 сервера для полноценной отказоустойчивости (кворум Raft требует нечётного числа узлов для однозначного голосования). Для расчёта итоговой конфигурации пригодится статья про выделенный сервер для большой базы данных — на этом этапе часто выгоднее переходить с VPS на выделенное железо.

Бэкапы даже в single-node режиме делайте регулярно — встроенная команда экспортирует в облачное хранилище или локальную директорию:

BACKUP DATABASE app_db INTO 'nodelocal://1/backups/app_db';

Восстановление:

RESTORE DATABASE app_db FROM LATEST IN 'nodelocal://1/backups/app_db';

Частые вопросы