Replication
רפליקציה היא טכניקה המשמשת במערכות מבוזרות כדי להשיג:
- הגדלת זמינות נתונים (availability),
- שיפור היכולת להתרחב (scalability),
- הגברת עמידות הנתונים (durability).
היא כוללת אחסון של אותו מאגר נתונים במספר צמתים (שנקראים רפליקות) כך שאם אחד מהם קורס (Server Down), ניתן לבקש בקשות מהצמתים האחרים.
במילים פשוטות, כאשר בסיס נתונים אחד לא יכול לטפל בכל הבקשות הנכנסות ה Replication נכנס לתמונה. Replication כולל יצירת עותק של בסיס הנתונים הנקרא רפליקה.
הרפליקה(ות) מאוחסנת(ות) במכונה או שרת נפרד, והוא מתואם בזמן אמת עם בסיס הנתונים המקורי.
עם זאת, היתרון של זמינות מוגברת המגיע עם Replication מביא עימו סדרה של מורכבויות חדשות.
אז השאלה שנשאלת כעת היא איך מיישמים העתקה (Replication) ?
בסיס הנתונים המקורי הוא leader or master, בעוד שהרפליקה (המקום אליו מעתיקים נתונים) הוא הfollower or slave.
בארכיטקטורת leader/follower, זרימת הדאטה נעה מ leader ל follower , וה leader הוא זה שאחראי לעדכן את ה follower קרי ה follower לא מקבל לעולם עדכון באופן ישיר אלא רק דרך ה leader. אבל כמובן אפשר לבצע פעולת קריאה ממנו.
ישנן שתי דרכים בהן מתרחשת Replication: באופן אסינכרוני ובאופן סינכרוני.
Synchronous Replication
בהעתקה סינכרונית, הleader משיב ללקוח על כך שהעדכון הושלם רק לאחר שהתקבלו אישורים (acknowledgments) מהרפליקות האחרות שהן גם ביצעו את העדכון אצלם.
דבר זה מבטיח שהלקוח יוכל לראות את העדכון בקריאה מאוחרת, ללא תלות באיזו רפליקה הלקוח קורא.
בנוסף, רפליקציה סינכרונית מספקת עמידות (durability) טובה יותר. זה מכיוון שהעדכון אינו אבוד גם אם הleader קורס מיד לאחר שהוא אישר את העדכון. עם זאת, הטכניקה הזו יכולה להאט את בקשות הכתיבה (latency). וזאת משום שה leader צריך לחכות עד שהוא מקבל ״אישורים״ מכל הרפליקות.
Asynchronous Replication
ברפליקציה אסינכרונית, ה leader משיב ללקוח על כך ש העדכון הושלם כאשר הוא מבצע את העדכון באחסון המקומי שלו, מבלי לחכות לאישורים (acknowledgments) מהרפליקות האחרות.
הטכניקה הזו מגדילה משמעותית את הביצועים עבור בקשות כתיבה. מכיוון שכעת הleader מחזיר ישר תשובה כאשר הוא עדכן את הנתונים אצלו.
עם זאת, זה בא במחיר של חוסר עקביות וחוסר עמידות.
חוסר עקביות (consistency): לאחר שלקוח מקבל תגובה לבקשת עדכון, הלקוח עשוי לקרוא ערכים ישנים (לא עדכניים) בקריאה מאוחרת. זה אפשרי רק אם הפעולה מתרחשת באחת הרפליקות שעדיין לא ביצעו את העדכון.
חוסר עמידות (durability): אם צומת הleader קורס מיד לאחר שהלקוח קיבל ack (והוא ביצע עדכון) אך הרפליקות האחרות עדין לא ביצעו את בקשות העדכון, נוצרת בעיה.
מכיוון שהרפליקות לא ביצעו את העדכון האחרון והלקוח שיבצע אליהם קריאה יקבל את התוצאה הישנה. יחד עם זאת הleader כן ביצע עדכון אבל הוא קרס. לפיכך במקרה זה לא משנה מאיזה צומת הלקוח יבצע קריאה תמיד הוא יקבל נתונים ישנים.
Multi-Master Replication
העתקה מרובת-מאסטרים היא טכניקת רפליקציה אלטרנטיבית המעדיפה זמינות גבוהה וביצועים על פני עקביות נתונים.(טכניקה זו ידועה גם כרפליקציה רבת-ראש).
בטכניקה זו, כל העתקים שווים ויכולים לקבל בקשות כתיבה. הם גם אחראים להפצת השינויים בנתונים לשאר הקבוצה.
לרפליקציה מרובת-מאסטרים יש הבדל משמעותי מרפליקציה בעלת מאסטר יחיד.
ברפליקציה מרובת-מאסטרים, אין צומת leader יחיד שמסדיר את הבקשות ומכתיב סדר אחד, כיוון שבקשות הכתיבה מטופלות במקביל על ידי כל הצמתים. הבעיה אם שיטה זו היא שיכול להיות לנו סתירות בדטהבייס שלנו
למשל:
המצב בא להמחיש לנו שני משתמשים שונים A וB יכול להיות גם אותו בן אדם מטלפון או מחשב.
משתמש B כותב בשעה 10:59
משתמש A כותב לרשומה x בשעה 11:00
דטה-בייס A מעדכן את דטב-בייס B לשנות את רשומה x ב 11:01
כלומר מה שיקרה כאן שאני אקבל עדכון ישן יותר על רשומה X ממשתמש B למרות משתמש A כתב מאוחר יותר…!!!!
פתרון סתירות – מזהים ייחודיים:
אחת הדרכים האפשריות לקבוע את סדר הפעולות הכתיבה המתבצעות על פני מאסטרים מרובים היא להקצות מזהים ייחודיים הגדלים בצורה מונוטונית לכל פעולת כתיבה.
כאשר מתגלה קונפליקט, פעולת הכתיבה עם המזהה הגדול ביותר הוא זה שצריך להתבצע.
הגישה זו דומה לסדר פעולות כתיבה במאסטר יחיד. המזהה הייחודי הגדל בצורה מונוטונית מעניק סדר סמוי לכתיבות כדי לקבוע איזו מהן הייתה האחרונה ובכך ליישם את עקרון "הכתיבה האחרונה מנצחת".
כלומר במקרה זה אני אדע לעדכן את רשומה X למשתמש A מכיוון שה id שלו גדול יותר, כך אני ימנע את העדכון שיגיע ב 11:01, כלומר אני אדחה אותו כי הוא עם מזהה קטן יותר 2>1
חשיפת פתרון סתירות ללקוחות:
כאשר יש סתירה, הגרסאות הזמינות חוזרות ללקוח. הלקוח לאחר מכן בוחר בגרסה הנכונה ומחזיר אותה למערכת. זה פותר את הסתירה.
דוגמה לכך היא אפליקציית עגלת קניות, שבה הלקוח בוחר בגרסה הנכונה של העגלה.
לסיכום יתרונות:
זמינות גבוהה (availability) : על ידי אחסון עותקים של הנתונים במספר מכונות מארחות, מסד הנתונים עמיד בפני כישלון של מכונות מארחות יחידות ויכול לנתב בבטחה את הקריאות והכתיבות למכונות מארחות פעילות.
הפצת עומס (Load distribution): מסד הנתונים יכול להפציץ את השאילתות לקריאה וכתיבה למספר מכונות מארחות, ובכך למנוע עומס על מכונת מארחת יחידה.
הפחתת זמן תגובה (latency): ניתן למקם את המכונות המארחות המרובות גיאוגרפית קרוב יותר למשתמש, ובכך להפחית את זמן התגובה על המשתמש הקצה.
פוסטים ומאמרים נוספים ניתן למצוא בדף הלינקדין shay Sarussi Elshten
