Как масштабировать SurrealDB за 1 час: практическое руководство по горизонтальному росту

SurrealDB — это многофункциональная база данных нового поколения, сочетающая возможности реляционной, документной и графовой БД с собственным языком запросов SurrealQL. Её встроенная распределённость — одна из ключевых фишек. Но что делать, когда нагрузка на ваше приложение растёт и одной ноды становится недостаточно? Масштабирование SurrealDB может показаться сложной задачей, но с чётким планом его можно выполнить буквально за час. Это руководство шаг за шагом проведёт вас через процесс горизонтального масштабирования кластера SurrealDB.

Прежде всего, важно понять архитектуру. SurrealDB из коробки поддерживает кластеризацию на основе протокола Raft для обеспечения консенсуса и отказоустойчивости. Каждая нода (узел) в кластере может играть одну из трёх ролей: лидер (leader), последователь (follower) или учащийся (learner). Лидер обрабатывает все записи и реплицирует их на последователей, обеспечивая согласованность данных. Горизонтальное масштабирование — это процесс добавления новых нод в этот кластер для распределения нагрузки и повышения доступности.

**Шаг 1: Подготовка инфраструктуры (10 минут).**
Вам понадобятся как минимум три сервера (виртуальные машины, контейнеры или bare-metal) для создания отказоустойчивого кластера. Для теста можно обойтись и двумя, но для production-среды рекомендуется минимум три ноды (чтобы пережить отказ одной). Убедитесь, что:

• На всех серверах установлена одинаковая версия SurrealDB (скачайте актуальный бинарник с GitHub).
• Серверы имеют статические IP-адреса или DNS-имена и могут общаться друг с другом по сети (проверьте firewall, security groups).
• Выделен отдельный том или директория для хранения данных SurrealDB (`/path/to/data`).

**Шаг 2: Конфигурация и запуск первой ноды (лидера) (10 минут).**
На первом сервере (который станет лидером) создайте конфигурационный файл `surreal.toml`. Ключевые параметры для кластеризации:
```
[server]
bind = "0.0.0.0:8000" # Адрес для HTTP/WebSocket
bind-grpc = "0.0.0.0:9000" # Адрес для внутренней gRPC-коммуникации

[storage]
path = "/path/to/data"

[cluster]
# Уникальный ID этой ноды в кластере. Можно сгенерировать.
node-id = "node1"
# Адрес, по которому другие ноды смогут связаться с этой.
advertise-addr = "IP_НОДЫ_1:9000"
# Роль при запуске. Для первой ноды указываем 'leader'.
role = "leader"
# Список адресов других нод в кластере. Пока оставляем пустым.
cluster-addr = []
```
Запустите SurrealDB с этой конфигурацией: `surreal start --config ./surreal.toml`. Первая нода запустится в режиме ожидания последователей.

**Шаг 3: Добавление второй и третьей ноды (последователей) (15 минут).**
На втором сервере создайте аналогичный конфигурационный файл, но с другими `node-id` и `advertise-addr`. Критически важно изменить роль и указать адрес лидера:
```
node-id = "node2"
advertise-addr = "IP_НОДЫ_2:9000"
role = "follower"
# Указываем адрес лидера, чтобы нода знала, к кому присоединиться.
cluster-addr = ["IP_НОДЫ_1:9000"]
```
Запустите SurrealDB на второй ноде. Она подключится к лидеру и начнёт репликацию данных. Повторите тот же процесс для третьей ноды (`node3`). Теперь у вас работает кластер из трёх нод. Лидер автоматически управляет репликацией записей на последователей.

**Шаг 4: Настройка балансировки нагрузки и проверка (15 минут).**
Сама база данных теперь масштабирована, но приложение по-прежнему подключается к одному адресу. Чтобы распределить read-запросы (чтение), настройте балансировщик нагрузки (например, nginx или облачный LB) перед кластером. Направляйте трафик на адреса `bind` всех трёх нод (порт 8000). SurrealDB поддерживает согласованное чтение с последователей.

Важно: Все write-запросы (запись, обновление, удаление) должны по-прежнему идти на лидера. Но в случае его отказа Raft-протокол автоматически выберет нового лидера из последователей, что обеспечит высокую доступность.

Проверьте работу кластера:

• Подключитесь к любой ноде через SurrealDB CLI или веб-интерфейц (Studio) и выполните запрос `INFO FOR KV;`. Он покажет информацию о кластере.
• Сымитируйте отказ: остановите лидера. Через несколько секунд одна из оставшихся нод должна стать новым лидером, и запись должна продолжиться (возможно, с небольшой задержкой).
• Проверьте репликацию: создайте запись через одну ноду и прочитайте её через другую.

**Шаг 5: Дальнейшая оптимизация и мониторинг (10 минут).**
Масштабирование не заканчивается на запуске нод. Настройте мониторинг ключевых метрик: загрузка CPU/памяти на каждой ноде, латенция запросов, статус репликации. Используйте встроенные метрики Prometheus (SurrealDB предоставляет endpoint `/metrics`). Для ещё большего масштабирования вы можете добавлять новые ноды в режиме `follower` или `learner` (ученик, который только синхронизирует данные, но не участвует в выборах лидера).

За час вы превратили одиночный экземпляр SurrealDB в отказоустойчивый кластер, способный выдерживать повышенные нагрузки и сбои оборудования. Главное — чётко следовать шагам и понимать, что основная магия (консенсус, репликация, выборы лидера) уже встроена в саму базу данных. Ваша задача — корректно её сконфигурировать и предоставить надёжную сетевую инфраструктуру.