Ответ
Асинхронная репликация — это механизм копирования данных, при котором основной сервер (мастер) подтверждает запись на своей стороне не дожидаясь применения этих изменений на репликах. Это создаёт потенциальную задержку (replication lag) между данными на мастере и реплике.
С точки зрения DevOps:
- Цель: Обеспечить высокую доступность, географическое распределение и разгрузку мастер-сервера (для чтения) с минимальным impact на его производительность при записи.
- Типичный use-case: Настройка реплик для аналитических запросов, бэкапов или резервных копий в другом регионе, где небольшая задержка данных допустима.
Пример настройки асинхронной репликации в PostgreSQL через recovery.conf (PostgreSQL 12 и ниже) или postgresql.auto.conf (13 и выше):
# На реплике (пример для PG 13+)
primary_conninfo = 'host=master-pg-host port=5432 user=replicator password=... application_name=replica-1'
# Критичный параметр: synchronous_commit = off (по умолчанию на реплике)Плюсы для эксплуатации:
- Высокая производительность записи на мастере: Запись не блокируется сбоями или медленной работой реплик.
- Устойчивость к отказу реплики: Мастер продолжает работать, даже если все реплики отвалились.
- Работа на большом расстоянии: Можно разместить реплику в другом дата-центре без серьёзного падения производительности мастера.
Риски и минусы (DevOps должен учитывать):
- Потеря данных (RPO > 0): При аварийном отказе мастера последние зафиксированные на нём, но не переданные на реплику данные будут утеряны.
- Чтение устаревших данных: Приложения, читающие с реплик, могут видеть неактуальную информацию.
- Сложность восстановления: Промоутинг реплики в мастера может привести к расхождению данных, если lag был значительным.
Мониторинг: Ключевая метрика — replication lag (в байтах или секундах), которую нужно отслеживать в системах типа Prometheus/Grafana.
