שכפול

בדף הזה מתואר איך הנתונים משוכפלים ב-Spanner, הסוגים השונים של העתקים ב-Spanner והתפקידים שלהם בפעולות קריאה וכתיבה, והיתרונות של השכפול.

סקירה כללית

‫Spanner משכפל באופן אוטומטי ברמת הבייט. כמו שמתואר במאמר Life of Spanner Reads and Writes, הוא מנצל את היכולת הזו במערכת הקבצים הבסיסית שעליה הוא בנוי. ‫Spanner כותב מוטציות של מסד נתונים לקבצים במערכת הקבצים הזו, ומערכת הקבצים דואגת לשכפל ולשחזר את הקבצים כשיש תקלה במכונה או בדיסק.

למרות שמערכת הקבצים המבוזרת שעליה מבוסס Spanner כבר מספקת שכפול ברמת הבייט, Spanner גם משכפל נתונים כדי לספק את היתרונות הנוספים של זמינות הנתונים ומיקום גיאוגרפי. ברמה גבוהה, כל הנתונים ב-Spanner מאורגנים בשורות. מערכת Spanner יוצרת כמה עותקים, או רפליקות, של השורות האלה, ואז מאחסנת את הרפליקות האלה באזורים גיאוגרפיים שונים. ‫Spanner משתמש בסכמת שכפול סינכרונית שמבוססת על Paxos, שבה רפליקות מצביעות על כל בקשת כתיבה לפני שהכתיבה מתבצעת. המאפיין הזה של שכפול גלובלי סינכרוני מאפשר לכם לקרוא את הנתונים העדכניים ביותר מכל רפליקה לקריאה בלבד או לקריאה וכתיבה ב-Spanner.

‫Spanner יוצר רפליקות של כל פיצול של מסד הנתונים. פיצול מכיל טווח של שורות סמוכות, כשהשורות מסודרות לפי מפתח ראשי. כל הנתונים בפיצול מאוחסנים פיזית יחד ברפליקה, ו-Spanner משרת כל רפליקה מתוך אזור כשל עצמאי. מידע נוסף מופיע במאמר סקירה כללית על סכימות.

קבוצה של פיצולים מאוחסנת ומשוכפלת באמצעות Paxos. בכל קבוצת רפליקות של Paxos, רפליקה אחת נבחרת לפעול בתור leader. עותקים משוכפלים של הלידר מטפלים בפעולות כתיבה, ועותקים משוכפלים עם הרשאות קריאה וכתיבה או עם הרשאות קריאה בלבד יכולים לטפל בבקשת קריאה בלי לתקשר עם הלידר. אם מתבקשת קריאה חזקה, בדרך כלל מתבצעת התייעצות עם הלידר כדי לוודא שהעותק לקריאה בלבד קיבל את כל השינויים האחרונים. כדי לעקוב אחרי קצב השינוי וכמות הנתונים שמשוכפלים מהרפליקה הראשית לרפליקות באזורים אחרים בהגדרת המכונה, עיינו במאמר מעקב אחרי שכפול נתונים.

היתרונות של שכפול ב-Spanner

היתרונות של שכפול ב-Spanner כוללים:

  • זמינות הנתונים: ככל שיש יותר עותקים של הנתונים, הם זמינים יותר ללקוחות שרוצים לקרוא אותם. בנוסף, Spanner יכול עדיין לשרת כתיבות גם אם חלק מהרפליקות לא זמינות, כי נדרש רק רוב של רפליקות מצביעות כדי לבצע כתיבה.

  • מיקום גיאוגרפי: היכולת למקם נתונים באזורים ובאזורים גיאוגרפיים שונים באמצעות Spanner מאפשרת למשתמשים ולשירותים שזקוקים לנתונים לגשת אליהם מהר יותר, כי הם נמצאים במיקום גיאוגרפי קרוב יותר.

  • חוויית שימוש במסד נתונים יחיד: ב-Spanner אפשר ליהנות מחוויית שימוש במסד נתונים יחיד, בזכות הרפליקציה הסינכרונית ומודל העקביות החזק הגלובלי.

  • פיתוח אפליקציות פשוט יותר: מכיוון ש-Spanner תואם ל-ACID ומציע מודל עקביות חזק גלובלי, מפתחים שעובדים עם Spanner לא צריכים להוסיף לאפליקציות שלהם לוגיקה נוספת כדי להתמודד עם מודל עקביות הדרגתי, ולכן פיתוח האפליקציות והתחזוקה שלהן מהירים ופשוטים יותר.

סוגי רפליקות

ב-Spanner יש שלושה סוגים של רפליקות: רפליקות לקריאה ולכתיבה, רפליקות לקריאה בלבד ורפליקות עדות. האזורים והטופולוגיות של הרפליקציה שיוצרים את הגדרות המכונה הבסיסיות הם קבועים:

אתם יכולים ליצור הגדרות מותאמות אישית של מופעים ולהוסיף רפליקות לקריאה בלבד להגדרות של מופעים אזוריים ורב-אזוריים.

בטבלה הבאה מפורטים סוגי הרפליקות של Spanner והמאפיינים שלהם:

סוג הרפליקה אפשר להצביע יכול להפוך למוביל יכול להציג קריאות אפשר להגדיר את הרפליקה באופן ידני
קריאה-כתיבה כן כן כן לא
קריאה בלבד לא לא כן כן*
עד כן לא לא לא

* מידע נוסף זמין במאמר בנושא יצירת מופע עם הגדרת מופע בהתאמה אישית.

עותקים לקריאה ולכתיבה

רפליקות לקריאה ולכתיבה תומכות גם בקריאה וגם בכתיבה. העותקים האלה:

  • שמירה של עותק מלא של הנתונים.
  • הצגת קריאות.
  • יכול להצביע אם לשמור את הכתיבה.
  • השתתפות בבחירות להנהגה.
  • עומדים בדרישות להפוך למובילים.
  • הם סוג הרפליקה היחיד שמשמש במופעים אזוריים.

עותקים משוכפלים לקריאה בלבד

ברפליקות לקריאה בלבד יש תמיכה בקריאות בלבד, ולא בכתיבות. העותקים האלה לא מצביעים לבחירת מנהיגים או לאישור פעולות כתיבה, ולכן הם מאפשרים לכם להגדיל את קיבולת הקריאה בלי להגדיל את גודל הקוורום שנדרש לכתיבה. עותקים לקריאה בלבד:

  • שומרים עותק מלא של הנתונים, שמשוכפל מהרפליקה הראשית לקריאה ולכתיבה.
  • לא משתתפים בהצבעה על ביצוע כתיבות. לכן, המיקום של הרפליקות לקריאה בלבד אף פעם לא משפיע על זמן האחזור של פעולות הכתיבה.
  • לא עומדים בדרישות כדי להפוך למובילים.
  • הצגת קריאות.
  • אפשר להגדיל את המידות באופן לא סימטרי. מידע נוסף מופיע במאמר שינוי גודל אוטומטי אסימטרי לקריאה בלבד.
  • הם לא פועלים כפתרון עצמאי להתאוששות מאסון (DR). הזמינות של המכונה נקבעת לפי הקוורום של הרפליקות המצביעות. אם מכונת Spanner עוברת למצב אופליין, גם הרפליקות לקריאה בלבד עוברות למצב אופליין זמן קצר לאחר מכן, ולא יכולות להציג קריאות, כולל קריאות בעבר.

  • אם העותק הוא העותק הקרוב ביותר לאפליקציה, בדרך כלל אפשר להשתמש בו לקריאות לא עדכניות בלי לבצע הלוך ושוב לאזור הראשי, בהנחה שהנתונים לא עדכניים לפחות 15 שניות. אפשר גם להשתמש בקריאות מופנות כדי לנתב טרנזקציות לקריאה בלבד וקריאות בודדות לסוג מסוים של רפליקה או לאזור בהגדרת מופע מרובה אזורים. מידע נוסף זמין במאמר קריאות מכוונות.

    יכול להיות שקריאות חזקות ידרשו הלוך ושוב לרפליקה הראשית. התקשורת הדו-כיוונית נועדה רק כדי להסכים על חותמת הזמן, ולא כדי לשלוח את הנתונים בפועל מה-leader. המשא ומתן על חותמת הזמן הוא פעולה יעילה מבחינת השימוש במעבד (CPU) בשרת הראשי, ובדרך כלל הנתונים כבר בדרך. התקשורת הזו מתבצעת באופן אוטומטי על ידי המערכת.

    מידע נוסף על קריאות חזקות וקריאות לא עדכניות זמין בקטע בקריאות.

רפליקות אופציונליות לקריאה בלבד

אתם יכולים ליצור הגדרת מופע מותאמת אישית לאזור אחד או במספר אזורים ולהוסיף רפליקות אופציונליות לקריאה בלבד כדי להרחיב את הקריאות ולתמוך בקריאות לא עדכניות עם זמן אחזור נמוך. העותק לקריאה בלבד שמוסיפים צריך להיות באזור שלא נכלל בהגדרת מופע הבסיס המוגדרת מראש. רשימת האזורים האופציונליים לקריאה בלבד שאפשר להוסיף מופיעה בעמודה Optional Region בקטע Regional available configurations ו-Multi-region available configurations. אם לא רואים את המיקום של העותק לקריאה בלבד שבחרתם, אפשר לבקש אזור חדש של עותק אופציונלי לקריאה בלבד.

כל הרפליקות האופציונליות לקריאה בלבד כפופות לעלויות של קיבולת מחשוב, אחסון ושכפול.

בנוסף, הוספה של רפליקות לקריאה בלבד להגדרת מכונה בהתאמה אישית לא משנה את הסכמי ה-SLA של Spanner בהגדרת המכונה.

אם אתם בוחרים להוסיף רפליקה לקריאה בלבד ליבשת שונה מהיבשת של האזור הראשי, מומלץ להוסיף לפחות שתי רפליקות לקריאה בלבד. זה עוזר לשמור על זמן אחזור נמוך של קריאה במקרה שאחת מהרפליקות לקריאה בלבד לא זמינה.

מומלץ לבדוק את עומסי העבודה של הביצועים במופעים שאינם מופעי ייצור בהגדרת המופע המותאם אישית. אפשר לעיין בלוח הבקרה של מדדי ההשוואה של זמן האחזור והתפוקה בין אזורים כדי לראות נתונים לגבי זמן האחזור החציוני בין אזורים. לדוגמה, אם יוצרים הגדרה מותאמת אישית של מכונה עם הגדרת הבסיס eur6 שכוללת מספר אזורים ורפליקה אופציונלית לקריאה בלבד ב-us-east1, זמן האחזור הצפוי לקריאה חזקה של לקוח ב-us-east1 הוא כ-100 אלפיות השנייה, בגלל זמן הלוך ושוב לאזור הראשי ב-europe-west4. קריאות לא עדכניות עם רמת עדכניות מספקת לא גוררות את זמן ההלוך ושוב, ולכן הן מהירות הרבה יותר. אפשר גם להשתמש בתובנות לגבי נעילות ובתובנות לגבי עסקאות כדי לזהות עסקאות שמובילות לזמני אחזור ארוכים.

במאמר יצירת הגדרת מכונה בהתאמה אישית מוסבר איך מוסיפים רפליקות אופציונליות לקריאה בלבד.

צפייה בעותקים

רפליקות עדות לא תומכות בקריאות, אבל הן משתתפות בהצבעה על אישור כתיבות. הרפליקות האלה מקלות על השגת קוורומים לכתיבה בלי משאבי האחסון והמחשוב שנדרשים לרפליקות לקריאה ולכתיבה כדי לאחסן עותק מלא של הנתונים ולשרת קריאות. עותקים של העדויות:

  • משמשים במופעים של שני אזורים ומספר אזורים.
  • לא לשמור עותק מלא של הנתונים.
  • לא להציג קריאות.
  • להצביע אם לבצע כתיבות.
  • להשתתף בבחירת מנהיג אבל לא להיות כשיר להפוך לעותק של מנהיג.

התפקיד של העותקים המשוכפלים בפעולות כתיבה וקריאה

בקטע הזה מוסבר התפקיד של העותקים המשוכפלים בפעולות כתיבה וקריאה ב-Spanner. ההסבר הזה עוזר להבין למה Spanner משתמש בעותקים משוכפלים של עדים בהגדרות של שני אזורים ומספר אזורים.

בכתיבה

בקשות כתיבה של לקוחות תמיד מעובדות קודם בעותק הראשי, גם אם יש עותק משני שקרוב יותר ללקוח, או אם העותק הראשי מרוחק מהלקוח מבחינה גיאוגרפית. אם אתם משתמשים בהגדרת מופע של אזור כפול או של כמה אזורים, ואפליקציית הלקוח שלכם נמצאת באזור שאינו האזור הראשי, Spanner משתמש בניתוב שמודע לאזור הראשי כדי לנתב באופן דינמי עסקאות של קריאה וכתיבה, וכך להפחית את זמן האחזור במסד הנתונים. מידע נוסף זמין במאמר בנושא ניתוב שמודע למוביל.

העותק המוביל רושם את פעולת הכתיבה הנכנסת ומעביר אותה, במקביל, לעותקים האחרים שיכולים להצביע על פעולת הכתיבה הזו. כל רפליקה כשירה משלימה את הכתיבה שלה, ואז מגיבה ל-leader בהצבעה אם צריך לבצע commit לכתיבה. פעולת הכתיבה מתבצעת כשרוב העותקים המשוכפלים (או הרוב הדרוש לכתיבה) מסכימים לבצע את פעולת הכתיבה. ברקע, כל העותקים הנותרים (שאינם עותקים של עדים) מתעדים את הפעולה. אם רפליקה לקריאה-כתיבה או לקריאה בלבד לא מצליחה לרשום כתיבות, היא יכולה לבקש את הנתונים החסרים מרפליקה אחרת כדי לקבל עותק מלא ועדכני של הנתונים.

ב-Reads

יכול להיות שבקשות קריאה של לקוח יבוצעו ברפליקה הראשית או ידרשו תקשורת איתה, בהתאם למצב המקבילות של בקשת הקריאה.

  • פעולות קריאה שהן חלק מטרנזקציית קריאה-כתיבה מוגשות מהרפליקה הראשית, כי הרפליקה הראשית שומרת את הנעילות שנדרשות כדי לאכוף את יכולת ההמרה לסדרה.

  • יכול להיות ששיטות קריאה יחידות (קריאה מחוץ להקשר של טרנזקציה) וקריאות בטרנזקציות לקריאה בלבד יצטרכו תקשורת עם הלידר, בהתאם למצב המקבילות של הקריאה. למידע נוסף על מצבי בו-זמניות, ראו סוגי קריאה.

    • בקשות קריאה חזקות יכולות לעבור לכל רפליקה לקריאה-כתיבה או לקריאה בלבד. אם הבקשה מגיעה לרפליקה שהיא לא הרפליקה הראשית, הרפליקה הזו צריכה לתקשר עם הרפליקה הראשית כדי לבצע את פעולת הקריאה.

    • בקשות לקריאה בעבר מועברות לרפליקה הקרובה ביותר לקריאה בלבד או לקריאה וכתיבה, שמעודכנת לחותמת הזמן של הבקשה. יכול להיות שזו העתק של הלידר אם הלידר הוא העתק הכי קרוב ללקוח שהנפיק את בקשת הקריאה.

מעקב אחרי שכפול נתונים

אתם יכולים לעקוב אחרי קצב השינוי וכמות הנתונים שמשוכפלים מהרפליקה הראשית לרפליקות חוצות האזורים בהגדרות של המופע. קצב השינוי הוא בבייטים לשנייה וכמות הנתונים היא בבייטים. כדי לעשות את זה, משתמשים במדד המעקב Cross region replicated bytes (instance/cross_region_replicated_bytes_count).

כדי לראות את המדד הזה במסוף Google Cloud :

  1. במסוף Google Cloud , נכנסים לדף Monitoring:

    מעבר למעקב

  2. בתפריט הניווט, בוחרים באפשרות Metrics explorer (כלי לבחירת מדדים).

  3. בשדה מדד, לוחצים על התפריט הנפתח בחירת מדד.

  4. בשדה Filter by resource or metric name (סינון לפי שם המשאב או המדד), בוחרים באפשרות Cloud Spanner Instance > Instance > Cross region replicated bytes (מופע Cloud Spanner > מופע > בייטים משוכפלים בין אזורים), ואז לוחצים על Apply (החלה).

    המדד הזה זמין רק בקטע Active metrics אם יש פעילות של רפליקציה בין אזורים במכונה. אחרת, הוא יופיע בקטע מדדים לא פעילים. כברירת מחדל, בממשק המשתמש מוצגים רק מדדים פעילים. מבטלים את הסימון של התיבה פעיל כדי לראות מדדים פעילים ולא פעילים.

    בתרשים מוצג קצב השינוי (בבייטים לשנייה) של נתונים משוכפלים בכל מופעי Spanner בטווח הזמן שצוין.

  5. אופציונלי: כדי להציג את כמות הנתונים (בבייטים) שמשוכפלים במקום את קצב השינוי:

    1. בשדה Aggregation (צבירה), לוחצים על התפריט הנפתח Sum (סכום) ובוחרים באפשרות Configure aligner (הגדרת כלי ההתאמה).
    2. בשדה פונקציית התאמה, לוחצים על התפריט הנפתח שיעור ובוחרים באפשרות דלתא.

    3. בוחרים טבלה או גם וגם כסוג הטבלה במקום 'תרשים'.

      בטבלה מוצגת כמות הנתונים (בבייטים) ששוכפלו בטווח התאריכים שצוין.

  6. אופציונלי: כדי לראות את השימוש במכונה או במאפיין מסוימים:

    1. בשדה Filter (מסנן) מוסיפים מסננים, כמו מזהה מופע, מזהה מסד נתונים, אזור מקור, אזור יעד או תג.
    2. לוחצים על הוספת מסנן כדי להוסיף כמה מסננים.

Google Cloud כאן אפשר לראות את הרשימה המלאה של מדדי Google Cloud .

המאמרים הבאים