Налаштування крос-регіональної реплікації даних для DR

Налаштування крос-регіональної реплікації даних для DR

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

Наша команда: 5+ років досвіду в DR, 50+ виконаних проєктів. Ми допомогли клієнтам заощадити до $10,000 на місяць завдяки оптимізації DR-рішень. Середня вартість рішення для PostgreSQL DR — $5,000, економія на простої може перевищувати $50,000 на рік.

Крос-регіональна реплікація даних: практичний посібник

Реплікація 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 Мбіт/с
    }
}

Орієнтовна вартість S3 CRR для бакету 10 TB — близько $40/місяць. Економія від використання DR-репліки замість щоденних бекапів може сягати $5,000/місяць.

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

Реплікація може працювати без помилок і при цьому давати розбіжності даних — особливо при асинхронній схемі. Для 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 мс. Крос-регіональна реплікація знижує RTO в 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