Настройка Replication и Sharding в PostgreSQL, MongoDB и TrueNAS: маршрутизация данных для отказоустойчивости и масштабирования (2026)

Построение надежной инфраструктуры хранения требует выбора правильных механизмов распределения данных. Репликация обеспечивает отказоустойчивость и распределение нагрузки на чтение, а шардирование позволяет горизонтально масштабировать запись и хранение. Это руководство предоставляет проверенные инструкции для настройки этих механизмов в PostgreSQL 16+, MongoDB 7+ и TrueNAS Core 13+.

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

Выбор стратегии: когда репликация, а когда шардирование?

Репликация и шардирование решают разные проблемы в архитектуре хранения данных. Репликация создает копии данных на нескольких узлах для повышения доступности и распределения запросов на чтение. Шардирование разделяет данные между серверами для горизонтального масштабирования нагрузки на запись и объемов хранения.

PostgreSQL использует репликацию как основной механизм отказоустойчивости. MongoDB применяет шардирование для масштабирования, дополняя его репликацией внутри каждого шарда. TrueNAS реализует репликацию на уровне файловой системы ZFS для резервного копирования и аварийного восстановления.

Система	Основной механизм	Ключевая задача	Ограничения
PostgreSQL 16+	Потоковая репликация (master-standby)	Отказоустойчивость, чтение с реплик	Запись только на мастер-узел
MongoDB 7+	Шардирование с репликасетами	Горизонтальное масштабирование записи	Сложность выбора shard key
TrueNAS Core 13+	ZFS snapshot replication	Disaster recovery, геораспределение	Асинхронность, зависит от сети

Репликация в PostgreSQL: обеспечение доступности и распределение нагрузки на чтение

Архитектура master-standby в PostgreSQL позволяет создать один мастер для операций записи и несколько standby-реплик для чтения. Физическая потоковая репликация передает изменения на уровне WAL, обеспечивая минимальную задержку. Логическая репликация работает на уровне отдельных таблиц, позволяя выборочно реплицировать данные.

Реплики разгружают мастер-узел, принимая до 80% запросов SELECT в read-intensive сценариях. Это критично для веб-приложений с высоким соотношением чтения к записи. Ограничение заключается в том, что все операции INSERT, UPDATE, DELETE выполняются только на мастере.

Шардирование в MongoDB: горизонтальное масштабирование для растущих нагрузок

Шардированный кластер MongoDB состоит из config servers, mongos-роутеров и набора шардов. Каждый шард представляет собой отдельный replica set для внутренней отказоустойчивости. Mongos-роутер направляет запросы к нужным шардам на основе ключа шардирования.

Ключ шардирования определяет, как данные распределяются между шардами. Неправильный выбор приводит к неравномерной нагрузке и появлению "горячих" шардов. Балансировщик автоматически перемещает чанки данных между шардами для поддержания равномерного распределения.

Для глубокого понимания архитектуры шардирования изучите полное руководство по масштабированию БД, где сравниваются стратегии range и hash шардирования.

Репликация в TrueNAS: отказоустойчивость на уровне системы хранения

TrueNAS использует механизм снапшотов ZFS для создания точек восстановления. Репликация копирует эти снапшоты на удаленный сервер TrueNAS по SSH. Это обеспечивает защиту от физических сбоев оборудования и географическое распределение данных.

Настройка включает создание периодических снапшотов с политиками хранения и задач репликации. Инкрементальная репликация передает только изменения, экономя пропускную способность сети. Восстановление данных выполняется путем импорта реплицированного пула или отдельных наборов данных.

Практические примеры настройки можно найти в пошаговом руководстве по репликации в TrueNAS.

Пошаговая настройка репликации в PostgreSQL 16+ для production-среды

Настройка потоковой репликации в PostgreSQL требует изменения конфигурационных файлов на мастер- и standby-узлах. Процесс занимает 15-30 минут при наличии предустановленного PostgreSQL 16+ на обоих серверах.

Базовая настройка потоковой репликации (streaming replication)

На мастер-узле отредактируйте postgresql.conf:

wal_level = replica
max_wal_senders = 10
wal_keep_size = 1GB
hot_standby = on

В pg_hba.conf добавьте строку для доступа standby:

host replication replicator 192.168.1.100/32 md5

Создайте пользователя для репликации:

CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'secure_password';

На standby-узле выполните инициализацию из мастера:

pg_basebackup -h 192.168.1.1 -D /var/lib/postgresql/16/main -U replicator -P -v -R

После запуска службы проверьте статус репликации на мастере:

SELECT client_addr, state, sync_state FROM pg_stat_replication;

Настройка автоматического переключения (failover) с помощью Patroni

Patroni управляет выбором мастера в кластере PostgreSQL, используя распределенное хранилище конфигураций. Установите Patroni и etcd на всех узлах кластера.

Конфигурационный файл /etc/patroni/patroni.yml для узла:

scope: postgres_cluster
name: node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.1:8008

etcd:
  hosts:
    - 192.168.1.1:2379
    - 192.168.1.2:2379
    - 192.168.1.3:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 30
    maximum_lag_on_failover: 1048576

При отказе мастера Patroni выполняет выбор нового лидера в течение 30-60 секунд. Трафик приложений необходимо перенаправлять на новый мастер через механизм балансировки нагрузки.

Балансировка нагрузки на чтение между репликами

HAProxy распределяет запросы SELECT между мастером и standby-репликами. Конфигурация включает проверку статуса репликации:

backend postgres_read
    balance roundrobin
    option httpchk OPTIONS /replica
    server pg_master 192.168.1.1:5432 check port 8008
    server pg_replica1 192.168.1.2:5432 check port 8008 backup
    server pg_replica2 192.168.1.3:5432 check port 8008 backup

PgBouncer в режиме session pooling уменьшает нагрузку на соединения. Мониторинг лага репликации выполняется через запрос:

SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag;

Лаг более 1 минуты указывает на проблемы с сетью или нагрузкой на реплику.

Практическое руководство по шардированию в MongoDB 7+

Развертывание шардированного кластера MongoDB требует минимум трех config servers, двух mongos-роутеров и нескольких шардов. Каждый компонент запускается как отдельный сервис с уникальным портом.

Развертывание шардированного кластера с нуля

Запустите config servers как replica set на портах 27019, 27029, 27039:

mongod --configsvr --replSet configReplSet --dbpath /data/configdb1 --port 27019

Инициализируйте replica set config servers:

rs.initiate({
  _id: "configReplSet",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1.example.com:27019" },
    { _id: 1, host: "cfg2.example.com:27029" },
    { _id: 2, host: "cfg3.example.com:27039" }
  ]
})

Запустите mongos-роутеры, указывая на config servers:

mongos --configdb configReplSet/cfg1.example.com:27019,cfg2.example.com:27029,cfg3.example.com:27039 --port 27017

Добавьте шарды как отдельные replica sets. Подключитесь к mongos и выполните:

sh.addShard("shardReplSet1/shard1.example.com:27018")
sh.addShard("shardReplSet2/shard2.example.com:27018")

Критический выбор: стратегии и ключи шардирования (Shard Key)

Ключ шардирования определяет производительность кластера. Hashed sharding равномерно распределяет данные, но исключает range queries по шардированному полю. Ranged sharding поддерживает range queries, но требует тщательного выбора границ чанков.

Хороший shard key обладает высокой кардинальностью, равномерным распределением запросов и неизменяемостью. Плохой ключ создает "горячие" шарды и ограничивает масштабирование.

Пример хорошего ключа для коллекции пользователей:

sh.shardCollection("app.users", { "account_id": 1, "user_id": 1 })

Пример плохого ключа (низкая кардинальность):

sh.shardCollection("app.users", { "country": 1 }) // Только 200 значений

Детальный разбор стратегий шардирования и готовые конфигурации для production доступны в руководстве по настройке репликасета MongoDB.

Мониторинг и балансировка шардированного кластера

Команда sh.status() показывает распределение чанков по шардам:

sh.status()
--- Sharding Status ---
  sharding version: {
    "_id" : 1,
    "minCompatibleVersion" : 5,
    "currentVersion" : 6,
    "clusterId" : ObjectId("67c1a2b3d4e5f67890123456")
  }
  shards:
    { "_id" : "shardReplSet1", "host" : "shardReplSet1/shard1.example.com:27018", "state" : 1 }
    { "_id" : "shardReplSet2", "host" : "shardReplSet2/shard2.example.com:27018", "state" : 1 }

Автоматическая балансировка перемещает чанки при отклонении распределения более 20%. Мониторинг метрик включает нагрузку CPU на шардах, количество операций в секунду и размер данных.

Для комплексной настройки безопасности и производительности изучите руководство по MongoDB в production 2026.

Настройка отказоустойчивого кластера хранения на TrueNAS Core 13+

TrueNAS использует ZFS для создания пулов хранения с функциями снапшотов и репликации. Настройка занимает 20-40 минут при наличии двух серверов TrueNAS в одной сети.

Создание и планирование ZFS снапшотов

В веб-интерфейсе TrueNAS перейдите в Storage → Snapshots. Создайте периодический снапшот для набора данных:

Источник: pool/app_data
Расписание: ежечасно с 8:00 до 20:00
Политика хранения: сохранять 24 последних снапшота
Исключения: пропускать если занято более 80% пула

Ручное создание снапшота через CLI:

zfs snapshot pool/app_data@manual_$(date +%Y%m%d_%H%M%S)

Настройка репликации на удаленный TrueNAS

Сгенерируйте SSH-ключи на источнике и добавьте публичный ключ в авторизованные ключи на целевом сервере. В веб-интерфейсе перейдите в Tasks → Replication Tasks.

Создайте задачу репликации:

Источник: локальный снапшот pool/app_data@auto_*
Назначение: ssh://backup@192.168.2.1:/mnt/backup_pool/replica
Расписание: ежедневно в 02:00
Тип: инкрементальная репликация
Компрессия: lz4
Ограничение пропускной способности: 100 Мбит/с

Проверьте статус последней задачи:

zfs list -t snapshot -r pool/app_data | tail -5

Восстановление данных выполняется через импорт реплицированного пула или откат к конкретному снапшоту.

Для построения высокодоступного кластера файлового хранилища используйте руководство по TrueNAS SCALE 2026.

Интеграция и мониторинг: создание единой отказоустойчивой инфраструктуры

Комплексная инфраструктура объединяет шардированный MongoDB для горизонтального масштабирования, реплицированный PostgreSQL для транзакционных данных и TrueNAS для резервного копирования. Мониторинг всех компонентов обеспечивает предсказуемость и быстрое реагирование на сбои.

Ключевые метрики для мониторинга каждой системы

PostgreSQL: отслеживайте лаг репликации в байтах и секундах через pg_stat_replication. Критический порог: 1 ГБ WAL или 60 секунд.

MongoDB: мониторьте состояние членов replica set (1 - PRIMARY, 2 - SECONDARY), количество операций в секунду на шардах и балансировку чанков. Аномалия: один шард обрабатывает более 70% запросов.

TrueNAS: проверяйте статус последней задачи репликации, занятость дисков и количество ошибок ZFS. Тревога: занятость пула более 85% или сбой репликации в течение 24 часов.

Настройка алертов в Prometheus с Grafana:

- alert: PostgreSQLReplicationLag
  expr: pg_replication_lag_bytes > 1073741824  # 1GB
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Высокий лаг репликации PostgreSQL"