Настройка кросс-региональной репликации данных для DR

После выхода из строя основного ЦОДа в us-east-1 мы обнаружили, что все бэкапы лежат в том же регионе. Восстановление из другого региона заняло 8 часов вместо целевого RTO в 15 минут. Тогда мы поняли: кросс-региональная репликация — единственный способ уложиться в RPO/RTO. За 5+ лет работы с DR мы настроили десятки решений на PostgreSQL, MySQL и S3 для компаний с требованием RPO менее 1 минуты. Наша команда провела более 50 проектов по Disaster Recovery, средний достигнутый RPO — 2 секунды при асинхронной репликации.

Репликация PostgreSQL между регионами

Streaming replication через интернет работает, но требует защищённого канала. Обычная схема: VPN или VPC Peering между регионами, синхронная или асинхронная репликация в зависимости от требований к RPO.

Для асинхронной репликации между регионами Patroni с etcd в каждом регионе — правильный выбор. Но нужно явно указать, что cross-region реплика не участвует в выборах лидера:

# patroni-dr.yml — конфиг для DR-реплики в другом регионе
scope: pg-production
namespace: /service/
restapi:
  listen: 0.0.0.0:8008
  connect_address: 10.10.1.5:8008
etcd3:
  # Локальный etcd только для состояния DR-ноды
  # Не участвует в кворуме основного кластера
  hosts: 10.10.0.1:2379
bootstrap:
  dcs:
    maximum_lag_on_failover: 10485760  # 10 MB — допускаем лаг для cross-region
    master_start_timeout: 300
postgresql:
  listen: 0.0.0.0:5432
  connect_address: 10.10.1.5:5432
  data_dir: /var/lib/postgresql/data
  parameters:
    # Реплика только для чтения, не для выборов
    hot_standby: "on"
    recovery_min_apply_delay: "0"
  tags:
    # Исключить из автоматического failover — только ручной promote
    nofailover: true
    noloadbalance: false
    nosync: false

Мониторинг лага репликации критически важен. Если pg_wal_lsn_diff на DR-реплике растёт — либо сеть деградировала, либо нагрузка на мастер выросла:

-- На мастере: проверить лаг DR-реплики
SELECT client_addr, application_name, state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn) AS sent_lag_bytes,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag_bytes,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication
WHERE application_name = 'dr-replica-eu-west';

Репликация MySQL/MariaDB

Для MySQL бинарного лога достаточно для кросс-региональной репликации. Современный GTID-based replication упрощает failover и восстановление после разрыва:

# my.cnf на DR-реплике
[mysqld]
server-id = 2000
# уникальный, отличный от основного кластера
gtid_mode = ON
enforce_gtid_consistency = ON
read_only = ON
super_read_only = ON
# Параллельная репликация для снижения лага
slave_parallel_type = LOGICAL_CLOCK
slave_parallel_workers = 8
# Сохранение позиции репликации в таблице (не в файле)
master_info_repository = TABLE
relay_log_info_repository = TABLE
relay_log_recovery = ON

Репликация файловых систем

Для файлов и объектного хранилища подходы разные.

AWS S3 Cross-Region Replication: включается на уровне bucket policy и работает автоматически. Важный нюанс — CRR реплицирует только новые объекты после включения, существующие нужно скопировать отдельно через aws s3 sync:

# Настройка Cross-Region Replication через AWS CLI
aws s3api put-bucket-replication \
  --bucket company-primary-eu-central-1 \
  --replication-configuration '{
    "Role": "arn:aws:iam::123456789:role/s3-replication-role",
    "Rules": [
      {
        "Status": "Enabled",
        "Filter": {"Prefix": ""},
        "Destination": {
          "Bucket": "arn:aws:s3::TRUETECH-dr-eu-west-1",
          "StorageClass": "STANDARD_IA",
          "ReplicationTime": {
            "Status": "Enabled",
            "Time": {"Minutes": 15}
          },
          "Metrics": {
            "Status": "Enabled",
            "EventThreshold": {"Minutes": 15}
          }
        },
        "DeleteMarkerReplication": {"Status": "Enabled"}
      }
    ]
  }'

rsync + inotifywait для on-premise: для файловых серверов вне облака — непрерывная репликация через lsyncd или rsync по расписанию через cron. lsyncd использует inotify и реплицирует изменения в реальном времени:

-- /etc/lsyncd/lsyncd.conf.lua
sync {
    default.rsync,
    source = "/data/media",
    target = "dr-server.company.com:/data/media",
    rsync = {
        binary = "/usr/bin/rsync",
        archive = true,
        compress = true,
        rsh = "/usr/bin/ssh -e aes128-ctr -i /etc/lsyncd/dr-key",
        _extra = {"--bwlimit=50000"} -- ограничение полосы: 50 Мбит/с
    }
}

Проверка консистентности данных

Репликация может работать без ошибок и при этом давать расхождения данных — особенно при асинхронной схеме. Для PostgreSQL pg_checksums и периодические сравнения через pg_comparator или checksums на уровне приложения.

Для S3 — периодический листинг и сравнение объектов между регионами через AWS Data Sync или собственные скрипты.

Почему асинхронная репликация — базовый выбор для кросс-регион?

Синхронная репликация между датацентрами на расстоянии >1000 км даёт задержку не менее 10 мс на пакет, что снижает пропускную способность записи до 1/3 от локальной. Асинхронная схема вносит лаг 0.5–5 секунд, но сохраняет производительность мастера. В 90% случаев для DR достаточно асинхронной репликации с RPO до 10 секунд. Patroni с пометкой nofailover: true позволяет автоматически не промотировать DR-реплику, пока оператор не решит иначе. Сравните: синхронная схема даёт RPO=0, но снижает TPS на 40% — мы рекомендуем её только для финансовых транзакций в пределах одного города. Асинхронная репликация в 50 раз быстрее по TPS при задержке >10 мс.

Как проверить консистентность данных после репликации?

Для PostgreSQL используйте pg_checksums и pg_comparator. Для таблиц с большим объёмом данных (10+ TB) достаточно сравнивать контрольные суммы каждого WAL-файла. Для S3 — запускайте aws s3 sync --dryrun раз в неделю, чтобы выявить расхождения в именах и хэшах объектов. Наши инженеры включают такие проверки в автоматику по умолчанию.

Типичные ошибки и чек-лист при настройке DR

Что входит в работу по настройке DR

Ориентиры по срокам

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Получите консультацию — наши инженеры оценят вашу схему и предложат оптимальное решение под ключ с гарантией RTO/RPO. Настройте DR, который действительно работает, — свяжитесь с нами, чтобы обсудить детали вашего проекта.

Ссылки

• PostgreSQL streaming replication
• AWS S3 Cross-Region Replication