Лог-репликация

Лог-репликация — это механизм распределённых систем, обеспечивающий согласованное копирование записей журнала операций (log) с одного узла (лидера) на другие узлы (последователи) для достижения отказоустойчивости и консистентности данных. Лог-репликация является ключевым компонентом алгоритмов консенсуса, таких как Raft и Paxos, а также применяется в системах управления базами данных (СУБД), потоковых платформах и распределённых файловых системах.

Основные принципы

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

Свойства лога

• Упорядоченность: записи располагаются в строгом хронологическом порядке, определяемом индексом.
• Неизменяемость: после записи в лог команда не может быть изменена, но может быть удалена при сжатии (compaction).
• Согласованность: если две записи в разных логах имеют одинаковые индекс и термин, то они содержат одну и ту же команду, а все предыдущие записи также идентичны.

Алгоритмы реализации

Raft

В алгоритме Raft лог-репликация является частью процесса достижения консенсуса. Лидер отправляет последователям сообщения AppendEntries, содержащие новые записи. Последователи подтверждают получение, и лидер считает запись зафиксированной (committed), когда большинство узлов (кворум) её приняли. После фиксации запись применяется к конечному автомату (state machine) на всех узлах.

Paxos

В Paxos лог-репликация реализуется через многократное выполнение протокола для каждой записи. Лидер предлагает значение, и узлы голосуют за его принятие. В отличие от Raft, Paxos не гарантирует строгой последовательности, что усложняет управление логом.

Репликация в СУБД

В системах управления базами данных, таких как PostgreSQL (через потоковую репликацию) или MySQL (через бинарный лог), лог-репликация используется для синхронизации данных между мастер-сервером и репликами. Мастер записывает изменения в журнал (WAL — Write-Ahead Log), а реплики непрерывно читают и применяют эти записи.

Типы репликации

Синхронная

При синхронной репликации лидер ждёт подтверждения от всех или большинства последователей, прежде чем сообщить клиенту об успехе. Это обеспечивает высокую надёжность, но увеличивает задержки. Пример: синхронная репликация в PostgreSQL требует подтверждения от хотя бы одной синхронной реплики.

Асинхронная

Асинхронная репликация не требует немедленного подтверждения — лидер отправляет записи и сразу отвечает клиенту. Это снижает задержки, но при сбое лидера часть данных может быть потеряна. Используется в системах, где производительность важнее консистентности, например, в некоторых конфигурациях Apache Kafka.

Полусинхронная

Компромиссный вариант, при котором лидер ждёт подтверждения от одной или нескольких реплик, но не от всех. Сочетает умеренную надёжность с приемлемой производительностью.

Применение

Распределённые базы данных

• etcd — распределённое хранилище ключ-значение, использующее Raft для лог-репликации. Каждая запись в логе соответствует операции put или delete.
• TiDB — распределённая SQL-база данных, где лог-репликация обеспечивает согласованность между узлами хранения через Raft.
• CockroachDB — использует Raft для репликации данных между регионами, гарантируя глобальную консистентность.

Потоковые платформы

• Apache Kafka — реплицирует партиции между брокерами через лог-репликацию. Каждая партиция имеет лидера и последователей, которые синхронизируют записи.
• Apache Pulsar — использует лог-репликацию для обеспечения долговременного хранения сообщений и отказоустойчивости.

Файловые системы

• HDFS (Hadoop Distributed File System) — реплицирует блоки данных между узлами, но не использует строгий лог, а полагается на копирование блоков.
• Ceph — применяет лог-репликацию для синхронизации данных между OSD (Object Storage Daemon).

Проблемы и ограничения

Сбои лидера

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

Сжатие лога (Log Compaction)

Со временем лог растёт, занимая память. Для управления размером применяются методы сжатия, такие как snapshotting (сохранение текущего состояния конечного автомата) или удаление старых записей. В Raft лидер периодически создаёт снимки (snapshots) и отправляет их медленным последователям.

Сетевые задержки

В распределённых системах с высокой задержкой сети лог-репликация может замедлять производительность. Для смягчения этого эффекта используются пакетная отправка записей и настройка таймаутов.

Потеря данных

При асинхронной репликации возможна потеря данных, если лидер выходит из строя до того, как записи будут скопированы. В синхронных схемах потеря минимальна, но система становится менее доступной при отказе узла.

Пример работы (Raft)

1. Клиент отправляет команду SET key=value лидеру.
2. Лидер добавляет запись в свой лог с индексом 5 и термином 3.
3. Лидер отправляет AppendEntries всем последователям.
4. Последователи добавляют запись в свои логи и отправляют подтверждение.
5. Лидер получает подтверждения от большинства (например, 2 из 3 узлов) и фиксирует запись.
6. Лидер применяет команду к конечному автомату и отвечает клиенту.
7. Последователи впоследствии применяют запись, когда получают уведомление о фиксации.

Интересные факты

• Алгоритм Raft был разработан в 2013 году Диего Онгаро и Джоном Остерхаутом как упрощённая альтернатива Paxos, с акцентом на понятность и лёгкость реализации.
• В некоторых системах, таких как Google Spanner, лог-репликация сочетается с глобальными часами TrueTime для обеспечения внешней консистентности.
• Лог-репликация лежит в основе технологии блокчейн, где каждый блок содержит записи транзакций, а репликация происходит через консенсус Proof of Work или Proof of Stake.

Источники

• Онгоро Д., Остерхаут Дж. «In Search of an Understandable Consensus Algorithm (Extended Version)» (2014).
• Лампорт Л. «The Part-Time Parliament» (1998) — описание алгоритма Paxos.
• Документация Apache Kafka: «Replication and Log Compaction».
• Документация etcd: «Raft log replication».
• Клейнман С. «Designing Data-Intensive Applications» (2017) — главы о репликации и консенсусе.