Streaming replication

Streaming replication — это механизм репликации данных в системах управления базами данных (СУБД), при котором изменения, вносимые в основную (первичную) базу данных, непрерывно передаются в виде потока журнальных записей (WAL — Write-Ahead Log) на одну или несколько резервных (реплик) баз данных. В отличие от традиционной репликации на основе копирования файлов WAL целиком, streaming replication обеспечивает минимальную задержку (обычно от нескольких миллисекунд до секунды) и позволяет репликам находиться в состоянии «горячего резерва» (hot standby), доступного для выполнения запросов на чтение.

История и развитие

Концепция потоковой репликации впервые была реализована в СУБД PostgreSQL. До появления этого механизма в PostgreSQL для создания реплик использовалась утилита pg_standby, которая копировала файлы WAL с первичного сервера на резервный с помощью скриптов. Этот подход был медленным, требовал ручного управления и не гарантировал актуальность данных.

Версия PostgreSQL 9.0, выпущенная в сентябре 2010 года, представила встроенную поддержку streaming replication. Это стало значительным шагом вперёд, так как позволило автоматизировать процесс репликации, снизить задержки и обеспечить постоянную синхронизацию. В последующих версиях (9.1, 9.2 и далее) механизм был расширен: добавлена поддержка синхронной репликации (когда транзакция на первичном сервере считается завершённой только после подтверждения записи на реплике), каскадной репликации (реплика может выступать источником для других реплик) и улучшена производительность.

Принцип работы

Streaming replication основана на архитектуре «ведущий-ведомый» (master-slave). Первичный сервер (master) постоянно генерирует записи WAL, которые описывают все изменения данных (вставки, обновления, удаления, изменения схемы). Эти записи не записываются в файлы немедленно, а сначала помещаются в буфер в оперативной памяти.

Процесс репликации включает следующие этапы:

1. Передача потока: на первичном сервере работает фоновый процесс walsender, который устанавливает TCP-соединение с процессом walreceiver на резервном сервере. walsender читает записи WAL из буфера (или из уже записанных файлов, если реплика отстала) и отправляет их в режиме реального времени.
2. Приём и запись: на резервном сервере процесс walreceiver принимает поток записей WAL и записывает их в локальный файл WAL (в каталог pg_wal). После этого записи применяются к состоянию базы данных процессом startup, который воспроизводит изменения (replay).
3. Подтверждение: в асинхронном режиме первичный сервер не ждёт подтверждения от реплики. В синхронном режиме транзакция на первичном сервере фиксируется (commit) только после получения подтверждения от реплики о том, что запись WAL была записана и применена.

Резервный сервер может находиться в режиме «горячего резерва» (hot standby), что позволяет выполнять на нём запросы SELECT (чтение) без блокировки процесса репликации. Это делает streaming replication основой для масштабирования нагрузки на чтение и обеспечения высокой доступности.

Виды и режимы

Асинхронная репликация

Наиболее распространённый режим. Первичный сервер отправляет записи WAL и не ждёт подтверждения от реплики. Преимущества: минимальная задержка на первичном сервере, высокая пропускная способность. Недостатки: при сбое первичного сервера возможна потеря данных, которые были отправлены, но ещё не записаны на реплику (обычно не более нескольких мегабайт).

Синхронная репликация

Первичный сервер фиксирует транзакцию только после получения подтверждения от одной или нескольких реплик (настраивается параметром synchronous_standby_names). Преимущества: гарантированная целостность данных — потеря данных при сбое первичного сервера исключена. Недостатки: увеличение времени выполнения транзакций (из-за ожидания подтверждения), снижение производительности на высоконагруженных системах.

Каскадная репликация

Резервный сервер может выступать источником данных для других резервных серверов. Это позволяет строить иерархические структуры репликации, снижая нагрузку на первичный сервер и улучшая масштабируемость в географически распределённых системах.

Настройка и конфигурация

Для включения streaming replication в PostgreSQL требуется выполнить несколько шагов:

1. На первичном сервере: установить параметр wal_level = replica (или logical для логической репликации), задать max_wal_senders (количество допустимых подключений реплик) и настроить аутентификацию для реплик (например, через файл pg_hba.conf).
2. На резервном сервере: создать резервную копию с помощью pg_basebackup, указав параметр -X stream для потоковой передачи WAL во время создания копии. В файле postgresql.conf задать hot_standby = on (для горячего резерва) и настроить параметры подключения к первичному серверу (через primary_conninfo).
3. Запуск: запустить резервный сервер. Он автоматически подключится к первичному и начнёт получать поток WAL.

Преимущества и недостатки

Преимущества

• Низкая задержка: данные на реплике обновляются практически в реальном времени (от миллисекунд до секунды).
• Горячий резерв: реплика может обслуживать запросы на чтение, разгружая первичный сервер.
• Автоматизация: не требует ручного копирования файлов WAL.
• Масштабируемость: позволяет легко добавлять реплики для увеличения производительности чтения.
• Высокая доступность: при сбое первичного сервера можно быстро переключиться на реплику (с помощью утилит типа pg_ctl promote или менеджеров кластеров).

Недостатки

• Потеря данных при асинхронной репликации: возможна потеря последних транзакций при сбое первичного сервера.
• Нагрузка на сеть: потоковая передача WAL требует стабильного и быстрого сетевого соединения.
• Сложность настройки синхронной репликации: требует учёта задержек сети и может снижать производительность.
• Ограниченная масштабируемость записи: все операции записи выполняются только на первичном сервере.

Применение

Streaming replication широко используется в современных информационных системах для:

• Обеспечения высокой доступности (HA): создание отказоустойчивых кластеров баз данных (например, с использованием Patroni, pgpool-II, repmgr).
• Масштабирования нагрузки на чтение: распределение запросов SELECT между несколькими репликами (например, с помощью балансировщиков нагрузки).
• Географического распределения: размещение реплик в разных дата-центрах для снижения задержек для пользователей из разных регионов.
• Резервного копирования: реплика может использоваться для создания резервных копий без нагрузки на первичный сервер.
• Тестирования и аналитики: реплики могут использоваться для выполнения сложных аналитических запросов, не затрагивающих основную базу.

Реализации в других СУБД

Хотя термин «streaming replication» наиболее тесно связан с PostgreSQL, аналогичные механизмы существуют и в других СУБД:

• MySQL: использует асинхронную и полусинхронную репликацию на основе бинарного журнала (binary log). Потоковая передача данных реализована через протокол репликации.
• MariaDB: поддерживает асинхронную и полусинхронную репликацию, а также групповую репликацию (Galera Cluster), которая обеспечивает синхронную репликацию на уровне транзакций.
• SQL Server: использует технологию Always On Availability Groups, которая поддерживает синхронную и асинхронную репликацию на уровне баз данных.
• Oracle Database: использует Data Guard для синхронной и асинхронной репликации, а также Active Data Guard для горячего резерва.

Критика и ограничения

Основная критика streaming replication связана с ограничением на операции записи: все изменения должны выполняться на одном первичном сервере. Это создаёт узкое место при высоких нагрузках на запись. Для решения этой проблемы используются шардирование (распределение данных по нескольким первичным серверам) или логическая репликация, которая позволяет реплицировать только определённые таблицы или базы данных.

Кроме того, при асинхронной репликации существует риск потери данных при сбое, что неприемлемо для некоторых финансовых и критически важных систем. Синхронная репликация, хотя и решает эту проблему, вносит задержки и снижает производительность, особенно на больших расстояниях.

См. также

• Репликация (базы данных)
• Write-Ahead Log
• PostgreSQL
• Высокая доступность
• Шардирование

Источники

• Официальная документация PostgreSQL: «Chapter 26. High Availability, Load Balancing, and Replication» (раздел «Streaming Replication»).
• Книга «PostgreSQL 9.0 High Performance» Грегори Смита.
• Статья «Understanding PostgreSQL Streaming Replication» на сайте PostgreSQL Tutorial.
• Документация MySQL: «Replication».
• Документация SQL Server: «Always On Availability Groups».