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

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

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

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

1. Запись на ведущий узел (мастер). Клиент отправляет запрос на изменение данных. Ведущий узел фиксирует изменение в своём журнале транзакций (например, binary log в MySQL) и одновременно отправляет это изменение одному или нескольким ведомым узлам (репликам).
2. Ожидание подтверждения от реплики. Ведущий узел не завершает транзакцию и не отправляет ответ клиенту, пока не получит подтверждение от хотя бы одного ведомого узла о том, что данные приняты и записаны в его журнал (но не обязательно применены к базе данных).
3. Подтверждение клиенту. После получения подтверждения от реплики ведущий узел фиксирует транзакцию и отправляет клиенту сообщение об успешном выполнении операции.

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

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

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

Одним из первых широко распространённых реализаций стала полусинхронная репликация в MySQL, внедрённая в версии 5.5 (2010 год) в виде плагина. Впоследствии она была улучшена в MySQL 5.7 и 8.0, где появилась возможность настройки количества реплик, от которых требуется подтверждение. Аналогичные механизмы были реализованы в PostgreSQL (через расширения, такие как synchronous_standby_names), а также в NoSQL-системах, например, в MongoDB (режим «majority commit»).

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

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

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

Недостатки

• Задержки. По сравнению с асинхронной репликацией, полусинхронная добавляет дополнительное время на ожидание подтверждения от реплики, что может быть критично для высоконагруженных систем.
• Зависимость от сети. Если сеть между ведущим и ведомым узлами нестабильна, полусинхронная репликация может приводить к задержкам или даже к временному отключению репликации (например, при превышении тайм-аута).
• Риск потери данных при множественных сбоях. Если ведущий узел выходит из строя сразу после подтверждения записи, а реплика, получившая данные, также отказывает до их применения, данные могут быть потеряны. Однако вероятность такого сценария мала.

Применение

Полусинхронная репликация широко используется в системах, где требуется высокая доступность и защита от потери данных, но при этом допустимы небольшие задержки. Основные области применения:

• Реляционные базы данных. MySQL, MariaDB, PostgreSQL и другие СУБД используют полусинхронную репликацию для обеспечения отказоустойчивости в кластерных конфигурациях.
• Распределённые файловые системы. Например, в GlusterFS или Ceph полусинхронная репликация применяется для балансировки между производительностью и согласованностью.
• Системы управления содержимым (CMS). Крупные веб-сайты, такие как интернет-магазины или новостные порталы, часто используют полусинхронную репликацию для обеспечения целостности данных при высоких нагрузках.

Примеры реализации

MySQL

В MySQL полусинхронная репликация реализована через плагин rpl_semi_sync_master. Настройка включает параметры:

• rpl_semi_sync_master_enabled — включение режима.
• rpl_semi_sync_master_timeout — тайм-аут ожидания подтверждения от реплики (по умолчанию 10 секунд). Если реплика не отвечает, система автоматически переключается на асинхронную репликацию.
• rpl_semi_sync_master_wait_for_slave_count — количество реплик, от которых требуется подтверждение (по умолчанию 1).

PostgreSQL

В PostgreSQL полусинхронная репликация настраивается через параметр synchronous_standby_names в файле postgresql.conf. Можно указать список реплик, от которых ожидается подтверждение, или использовать ключевое слово FIRST для выбора одной реплики.

MongoDB

В MongoDB полусинхронная репликация реализована через механизм «majority commit». Запись считается подтверждённой, если она записана на большинство узлов реплика-сета (например, 2 из 3). Это обеспечивает согласованность, близкую к синхронной, но с меньшими задержками.

Сравнение с другими типами репликации

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

Основная критика полусинхронной репликации связана с её зависимостью от сетевой инфраструктуры. В условиях нестабильной сети или высокой задержки между узлами система может часто переключаться в асинхронный режим, что снижает надёжность. Кроме того, полусинхронная репликация не решает проблему «split-brain» (разделения кластера), когда из-за сетевого разрыва оба узла считают себя ведущими. Для предотвращения таких ситуаций требуется дополнительное использование механизмов кворума или менеджеров кластера.

Источники

• MySQL 8.0 Reference Manual: Semi-Synchronous Replication
• PostgreSQL Documentation: Synchronous Replication
• MongoDB Documentation: Write Concern
• C. J. Date, «An Introduction to Database Systems» (8th edition), 2003
• Статья «Semi-synchronous replication in distributed systems» в журнале ACM Computing Surveys, 2015