Data Replication בפרודקשן: leader-follower, multi-leader וקונפליקטים שלא נעלמים

מאת צוות מדיה דיל · 06.08.2026 · Data Engineering · 13 דק׳

מדריך מעמיק לאסטרטגיות replication: sync מול async, leader-follower מול multi-leader, quorum, conflict resolution, ולמה replication lag הוא לא באג אלא מאפיין מובנה של המערכת.

צוות תשתיות שמוסיף read replica ל-PostgreSQL כדי להוריד עומס מה-DB הראשי, נתקל תוך שבועות בתלונה: 'המשתמש עדכן את הפרופיל שלו, ורענן את הדף — והשינוי נעלם'. מה שקרה בפועל הוא לא באג, אלא replication lag: הכתיבה הלכה ל-primary, אבל ה-read שאחריה הופנה ל-replica שעדיין לא קיבל את העדכון. זו הדוגמה הקלאסית לכך ש-replication הוא לא רק 'להעתיק נתונים' — הוא סדרה של החלטות ארכיטקטוניות עם trade-offs אמיתיים בין ביצועים, זמינות, ועקביות, שמשפיעות ישירות על חוויית המשתמש הסופית.

למה בכלל צריך replication

שלוש סיבות עיקריות מניעות ארגונים להטמיע replication: זמינות גבוהה — אם ה-primary נופל, replica יכול לקחת את מקומו (failover) בלי downtime ממושך; פיזור עומס קריאה — מפזרים queries בין כמה replicas כדי שה-primary יטפל רק בכתיבות; ו-קרבה גיאוגרפית — replica באזור גיאוגרפי אחר מקטין latency למשתמשים מרוחקים. כל אחת מהמטרות האלה דורשת החלטות שונות מעט על אופן ה-replication, ולעיתים יש מתח בין המטרות עצמן.

Synchronous מול Asynchronous replication

ההחלטה הבסיסית ביותר: האם ה-primary מחכה שה-replica יאשר קבלת השינוי לפני שהוא מדווח ללקוח שהכתיבה הצליחה. ב-synchronous replication, ה-primary מחכה לאישור מלפחות replica אחד (או quorum שלם) — זה נותן ערבות חזקה שהנתונים לא יאבדו גם אם ה-primary נופל מיד אחרי הכתיבה, אבל המחיר הוא latency גבוה יותר לכל כתיבה, ובמקרה שה-replica לא זמין, הכתיבות כולן נחסמות. ב-asynchronous replication, ה-primary מדווח על הצלחה מיד, והשינוי מופץ ל-replicas ברקע — latency נמוך יותר, אבל אם ה-primary נופל לפני שה-replica הספיק לקבל את העדכון, השינוי אבד לחלוטין. ברוב מערכות הפרודקשן נמצא compromise: semi-synchronous, שבו ה-primary מחכה לאישור ממספר מוגבל של replicas (למשל אחד מתוך שלושה), נותן איזון סביר בין אמינות לביצועים.

Leader-follower: המודל הנפוץ ביותר

ברוב מערכות ה-replication בעולם (PostgreSQL streaming replication, MySQL replication, MongoDB replica sets), יש leader יחיד שמקבל את כל הכתיבות, ו-followers שמעתיקים ממנו. המודל הזה פשוט להבנה ולתפעול: אין קונפליקטים בין כתיבות כי יש רק מקור אחד לאמת. החיסרון: ה-leader הוא single point of failure לכתיבות — אם הוא נופל, יש צורך במנגנון failover (בחירת leader חדש מבין ה-followers), וזה תמיד כרוך בחלון זמן קצר של חוסר זמינות לכתיבה, וסיכון ל-split-brain אם שני nodes חושבים שהם ה-leader בו-זמנית (בעיה שפתרונות כמו Raft ו-Paxos consensus algorithms נועדו למנוע).

Multi-leader replication: כשצריך כתיבה בכמה מקומות

כשיש דרישה לכתיבה ממספר data centers גיאוגרפיים במקביל (כדי למנוע latency גבוה לכתיבות מרחוק), leader-follower לבד לא מספיק — כל כתיבה מרוחקת תצטרך לחצות את האוקיינוס חזרה ל-leader היחיד. Multi-leader replication מאפשר לכמה nodes לקבל כתיבות במקביל, ולסנכרן ביניהם. הבעיה המרכזית: קונפליקטים — מה קורה כששני leaders מקבלים כתיבות סותרות לאותה רשומה כמעט בו-זמנית? יש כמה אסטרטגיות פתרון: Last-Write-Wins (LWW) — הכתיבה עם ה-timestamp המאוחר יותר מנצחת, פשוט אבל עלול לאבד נתונים בשקט; merge functions מותאמים — לוגיקה עסקית ספציפית שמחליטה איך לשלב שני שינויים (למשל, בעגלת קניות, לאחד את שני הסלים); ו-CRDTs (Conflict-free Replicated Data Types) — מבני נתונים שמעוצבים מתמטית כך שהם תמיד מתכנסים לאותה תוצאה בלי תלות בסדר ההגעה של השינויים, נפוצים בעיקר במערכות collaborative editing.

Quorum-based replication: NoSQL וה-N/W/R model

מסדי נתונים כמו Cassandra ו-DynamoDB משתמשים במודל שונה לגמרי, מבוסס quorum. עם N replicas, W הוא מספר ה-replicas שחייבים לאשר כתיבה לפני שהיא נחשבת מוצלחת, ו-R הוא מספר ה-replicas שצריך לקרוא מהם כדי לקבל תשובת query. הכלל המתמטי המבטיח strong consistency הוא W + R > N — כך שכל קריאה חופפת לפחות עם replica אחד שקיבל את הכתיבה האחרונה. זה נותן שליטה עדינה: אפשר לכוונן W=1, R=N (כתיבה מהירה, קריאה איטית ומדויקת) או W=N, R=1 (כתיבה איטית, קריאה מהירה), בהתאם לצרכי העומס בפועל. הגמישות הזו היא בדיוק מה שהופך מסדי נתונים כאלה לאטרקטיביים כשצריך לכוונן consistency ו-latency לפי workload ספציפי, במקום להסתפק בברירת המחדל הבינארית של leader-follower.

Replication lag: לא באג, מאפיין

replication lag — הפער בזמן בין כתיבה ל-primary לבין שיקופה ב-replica — הוא תוצאה בלתי נמנעת של asynchronous replication, לא סימן לתקלה. אבל הוא יוצר בעיות UX אמיתיות שצריך לתכנן סביבן במפורש: read-your-writes consistency — משתמש שכתב נתון וצריך לראות אותו מיד; monotonic reads — מניעת מצב שבו משתמש רואה נתון, מרענן, ורואה גרסה ישנה יותר (יכול לקרות אם requests שונים מגיעים ל-replicas שונים עם lag שונה); ו-consistent prefix reads — שמירה על סדר סיבתי בין כתיבות קשורות. הפתרונות הפרקטיים: sticky sessions שמפנים את אותו משתמש תמיד לאותו replica למשך זמן קצוב, קריאה מה-primary ישירות לאחר כתיבה קריטית, או version vectors שמאפשרים ל-client לוודא שה-replica שהוא קורא ממנו לפחות עדכני כמו הכתיבה האחרונה שהוא ביצע.

Cross-region replication: כשמרחק הוא פרמטר פיזיקלי

כשה-replicas פזורים על פני continents שונים, latency הרשת הפיזי (בסדר גודל של 100-200 מילישניות בין יבשות) הופך לגורם מגביל שלא ניתן לעקוף עם שום אופטימיזציית קוד. זה משפיע ישירות על הבחירה בין sync ל-async: synchronous replication בין data centers מרוחקים גיאוגרפית פירושה שכל כתיבה תמתין למאות מילישניות, מה שלרוב בלתי קביל עבור אפליקציות אינטראקטיביות. הפתרון המקובל הוא async replication ל-regions מרוחקים עם awareness מפורש ב-UI לגבי staleness אפשרי, ביחד עם synchronous replication רק בתוך אותו region (בין availability zones קרובות, עם latency בסדר גודל מילישניות בודדות) כדי לשמור על durability חזק בלי לשלם את מחיר ה-cross-region latency בכל כתיבה.

CDC-based replication מול native database replication

יש הבדל חשוב בין replication ברמת ה-storage engine (streaming replication ב-PostgreSQL, שמעתיק WAL segments גולמיים) לבין replication ברמה לוגית מבוססת CDC (Debezium וכדומה). replication ברמת storage engine מהיר ומדויק, אבל דורש בדרך כלל את אותו מנוע DB בשני הצדדים — לא אפשר לשכפל מ-PostgreSQL ל-MySQL בדרך הזו. CDC לוגי, לעומת זאת, מאפשר replication הטרוגני בין מנועי DB שונים לגמרי, במחיר של overhead עיבוד נוסף ומורכבות תפעולית גבוהה יותר. הבחירה תלויה בשאלה אם המטרה היא high availability בתוך אותו מנוע DB (storage-level) או אינטגרציה בין מערכות שונות (logical/CDC).

Failover: מה קורה בפועל כשה-leader נופל

failover נשמע פשוט בתיאוריה — "בוחרים leader חדש" — אבל בפועל הוא אחד התהליכים המורכבים והמסוכנים ביותר בניהול מסדי נתונים. השלבים כוללים: זיהוי שה-leader באמת נפל (לא רק network partition זמני — כאן נכנסים אלגוריתמי consensus כמו Raft שמשתמשים ב-heartbeats ו-timeouts כדי להבחין בין השניים), בחירת ה-follower המתאים ביותר להיות ה-leader החדש (בדרך כלל זה עם ה-replication offset הכי מעודכן, כדי למזער אובדן נתונים), עדכון כל שאר ה-followers להתחיל לעקוב אחרי ה-leader החדש, ועדכון clients וlayer ה-connection pooling/proxy כדי שיפנו לכתובת הנכונה. כלים כמו Patroni (עבור PostgreSQL) או המנגנון המובנה ב-MongoDB replica sets מטפלים בזה אוטומטית, אבל תהליך שנכשל באמצע — למשל split-brain שבו שני nodes בו-זמנית חושבים שהם ה-leader — יכול לגרום לאובדן נתונים חמור בהרבה מ-downtime זמני. לכן, לפני שסומכים על failover אוטומטי בפרודקשן, חובה לבדוק אותו באופן יזום (chaos engineering — הפלת ה-leader בכוונה בסביבת staging) ולא רק לקוות שהוא יעבוד כשבאמת יידרש.

טעויות נפוצות בפרודקשן

הטעות הראשונה: להניח ש-replica תמיד "כמעט מסונכרן" בלי לנטר בפועל את ה-lag — תחת עומס כתיבה גבוה, lag יכול לקפוץ מ-milliseconds לדקות שלמות, ואף אחד לא ישים לב בלי alerting מפורש. הטעות השנייה: לכוון traffic של קריאות קריטיות (כמו בדיקת יתרה לפני חיוב) ל-replica בלי לחשוב על ההשלכות של stale data. הטעות השלישית: ב-multi-leader, לא להגדיר מראש אסטרטגיית conflict resolution ברורה, ולגלות בפרודקשן שהמערכת פשוט בוחרת "מה שהגיע אחרון" בלי שזה תואם את הלוגיקה העסקית הרצויה. הטעות הרביעית: failover אוטומטי בלי בדיקות split-brain — שני nodes שחושבים שהם ה-leader בו-זמנית יכולים לגרום לאובדן נתונים חמור בהרבה מ-downtime זמני.

ניטור replication: מה חייב להיות ב-alerting

מעבר למדד ה-lag הבסיסי, ניטור רציני של replication כולל מעקב אחר: replication slot disk usage (ב-PostgreSQL, אם replica קורס והlag מצטבר, ה-WAL על ה-primary פשוט גדל ללא הפסקה עד שהדיסק מתמלא), replica connection health (replica שמאבד חיבור אבל לא מזוהה מיד כ-down יכול לתת תשובות stale ללא אזהרה), ו-consistency checks תקופתיים — checksum periodic על טבלאות קריטיות כדי לוודא שאין data drift בלתי מוסבר בין primary ל-replicas שלא נובע רק מ-lag רגיל. ארגונים בשלים מריצים גם game days תקופתיים שבהם מדמים כשל replica בכוונה כדי לוודא שהצוות יודע להגיב נכון בלחץ אמיתי, לא רק בתיאוריה.

מתי לבחור כל גישה

Leader-follower מתאים לרוב המערכות שצריכות בעיקר high availability ופיזור עומס קריאה, בלי דרישת כתיבה מרובת-אזורים. Multi-leader מתאים כשיש דרישה אמיתית לכתיבה מכמה מיקומים גיאוגרפיים במקביל, ומוכנים להתמודד עם המורכבות של conflict resolution. Quorum-based מתאים כשצריך שליטה עדינה על ה-trade-off בין latency לconsistency ברמת ה-workload, ובדרך כלל מגיע יחד עם המעבר ל-NoSQL database ייעודי מלכתחילה.

הקשר בין replication ל-backup: לא תחליף אחד לשני

נקודה שחשוב להבהיר: replication ו-backup פותרים בעיות שונות לגמרי, וטעות נפוצה היא לחשוב שreplica יכול לשמש כתחליף ל-backup. אם מישהו מריץ DROP TABLE בטעות על ה-primary, השינוי הזה יתפשט לכל ה-replicas תוך שניות — replication משכפל גם טעויות, לא רק נתונים תקינים. Backup, לעומת זאת, הוא snapshot בנקודת זמן שניתן לשחזר ממנו, בדרך כלל עם point-in-time recovery שמאפשר לחזור בדיוק לרגע לפני הטעות. מערכת פרודקשן רצינית צריכה את שניהם: replication לזמינות גבוהה ופיזור עומס, ו-backup נפרד (עדיף גם off-site) להגנה מפני טעויות אנוש ו-corruption.

סיכום

Replication הוא לא רק "עותק גיבוי" — הוא כלי ארכיטקטוני שמשפיע ישירות על זמינות, ביצועים, ועקביות הנתונים שהמשתמש רואה. ההחלטה הנכונה דורשת הבנה מפורשת של איזה סוג consistency העסק באמת צריך, לא רק "כמה replicas יש לנו" — כי בסופו של דבר, replication lag תמיד קיים, והשאלה היחידה היא איך המערכת מתמודדת איתו.

תגיות: data replication · leader-follower · multi-leader replication · replication lag · quorum · conflict resolution · CRDT

← חזרה לבלוג · צור קשר