שכפול נתונים בין אזורים לשחזור מאסון

לאחר תקלה במרכז נתונים ראשי ב-us-east-1, גילינו שכל הגיבויים היו באותו אזור. השחזור מאזור אחר ארך 8 שעות במקום יעד ה-RTO של 15 דקות. אז הבנו: שכפול בין-אזורי הוא הדרך היחידה לעמוד ב-RPO/RTO. עם ניסיון של למעלה מ-5 שנים ב-DR, הגדרנו עשרות פתרונות עבור PostgreSQL, MySQL ו-S3 עבור חברות הדורשות RPO מתחת לדקה אחת. הצוות שלנו השלים יותר מ-50 פרויקטים של שחזור מאסון, עם RPO ממוצע שהושג של 2 שניות באמצעות שכפול אסינכרוני.

שכפול PostgreSQL בין אזורים

שכפול סטרימינג דרך האינטרנט עובד, אך דורש ערוץ מאובטח. ההתקנה הטיפוסית: VPN או VPC Peering בין אזורים, שכפול סינכרוני או אסינכרוני בהתאם לדרישות RPO.

עבור שכפול אסינכרוני בין אזורים, Patroni עם etcd בכל אזור הוא הבחירה הנכונה. אבל יש לסמן במפורש את העותק הבין-אזורי כלא משתתף בבחירות מנהיג:

# 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

ניטור פיגור שכפול הוא קריטי. אם # 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 בעותק ה-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 מפשט החלפת מנהיג ושחזור לאחר פיצול:

# 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: מופעל ברמת מדיניות ה-bucket ועובד אוטומטית. נקודה חשובה — CRR משכפל רק אובייקטים חדשים לאחר ההפעלה; קיימים חייבים להיות מועתקים בנפרד באמצעות pg_wal_lsn_diff:

# Настройка 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::BLACKSPARC-dr-eu-west-1",
          "StorageClass": "STANDARD_IA",
          "ReplicationTime": {
            "Status": "Enabled",
            "Time": {"Minutes": 15}
          },
          "Metrics": {
            "Status": "Enabled",
            "EventThreshold": {"Minutes": 15}
          }
        },
        "DeleteMarkerReplication": {"Status": "Enabled"}
      }
    ]
  }'

rsync + inotifywait עבור מתקנים מקומיים: עבור שרתי קבצים מחוץ לענן — שכפול רציף באמצעות -- На мастере: проверить лаг 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'; או rsync המתוזמן דרך cron. # 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 משתמש ב-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, 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::BLACKSPARC-dr-eu-west-1", "StorageClass": "STANDARD_IA", "ReplicationTime": { "Status": "Enabled", "Time": {"Minutes": 15} }, "Metrics": { "Status": "Enabled", "EventThreshold": {"Minutes": 15} } }, "DeleteMarkerReplication": {"Status": "Enabled"} } ] }' או checksums ברמת האפליקציה.

עבור S3 — רישום תקופתי והשוואת אובייקטים בין אזורים באמצעות AWS Data Sync או סקריפטים מותאמים.

מדוע שכפול אסינכרוני הוא הבחירה הבסיסית עבור בין-אזורי?

שכפול סינכרוני בין מרכזי נתונים במרחק של מעל 1000 ק"מ מוסיף לפחות 10 אלפיות שנייה לכל חבילה, ומפחית את תפוקת הכתיבה לשליש מהביצועים המקומיים. שכפול אסינכרוני מציג פיגור של 0.5–5 שניות אך שומר על ביצועי המאסטר. ב-90% ממקרי ה-DR, שכפול אסינכרוני עם RPO של עד 10 שניות מספיק. Patroni עם התג lsyncd מבטיח שעותק ה-DR לא יקודם אוטומטית עד שהמפעיל יחליט. השוואה: שכפול סינכרוני נותן RPO=0 אך מפחית TPS ב-40% — אנו ממליצים עליו רק לעסקאות פיננסיות בתוך אותה עיר. שכפול אסינכרוני מהיר פי 50 ב-TPS בפיגורים >10 אלפיות שנייה.

כיצד לוודא עקביות נתונים לאחר שכפול?

עבור PostgreSQL, השתמש ב-lsyncd וב--- /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 Мбит/с } } . עבור טבלאות גדולות (10+ TB), השוואת checksums של כל קובץ WAL מספיקה. עבור S3, הפעל pg_checksums שבועי כדי לזהות פערים בשמות אובייקטים וב-hashes. המהנדסים שלנו כוללים בדיקות כאלה באוטומציה כברירת מחדל.

טעויות נפוצות ורשימת בדיקה להקמת DR

מה כלול בעבודת הקמת DR

הערכות זמנים

התמחור מחושב באופן אישי לאחר ביקורת תשתית. קבלו ייעוץ — המהנדסים שלנו יעריכו את ההתקנה שלכם ויציעו פתרון סוהר אופטימלי עם ערבויות RTO/RPO. הקימו DR שבאמת עובד — צרו קשר כדי לדון בפרטי הפרויקט שלכם.

מקורות

• שכפול סטרימינג של PostgreSQL
• שכפול בין-אזורי של AWS S3