הגדרת MySQL ב-Compute Engine

‫Compute Engine מציע מגוון של סוגי מכונות ואפשרויות אחסון שונות לקריאה ולכתיבה של נתונים ממסדי הנתונים של MySQL. כדי להבטיח שתקבלו את הביצועים הטובים ביותר ואת העלות הכי נמוכה עבור עומסי העבודה של מסד הנתונים, מומלץ להשתמש במוצרי תשתית כשירות (IaaS) מהדור החדש.

ההמלצות הבאות בנוגע להגדרות מתייחסות לעובדה שעומסי עבודה של MySQL משמשים לעיתים קרובות במערכות שמתבססות על קריאה, כמו עיבוד עסקאות אונליין (OLTP) או מסד הנתונים שמגבה אפליקציית אינטרנט טיפוסית. הם גם מתייחסים לבחירות נפוצות בהגדרות, כמו שימוש בגרסה 8.0 ואילך של MySQL ושימוש במנוע האחסון InnoDB. יכול להיות שתצטרכו לשנות את ההגדרות כדי להתאים אותן לעומסי עבודה שרגישים לביצועים. מומלץ להשתמש במדריך הזה כנקודת התחלה לפריסה, ואז לבדוק את עומס העבודה בפועל כדי לוודא שההגדרה עונה על הצרכים שלכם.

בחירת מכונה וירטואלית (VM)

לגבי עומסי עבודה של MySQL, מומלץ להשתמש בדור האחרון של משפחות המכונות C ו-N, כי הן כוללות צורות שמתאימות לרוב ההגדרות המעשיות של MySQL. Cloud de Confiance by S3NS בפוסט הזה בבלוג יש מבוא לסדרות המכונות האלה. משפחות המכונות האלה משתמשות ב-Titanium ומבוססות על דורות עדכניים של מעבדי Intel,‏ AMD ו-Axion.

התמקדות בביצועים

לסביבות עבודה שרגישות לביצועים, כמו מסדי נתונים של MySQL שחיוניים לעסק, מומלץ להשתמש במכונות C4 ו-C4A העדכניות, אם הן זמינות באזור שלכם. אם אין לכם גישה אליהם, מופעי C3 ו-C3D מציעים התמקדות דומה בביצועים.

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

  • שליטה באירועי תחזוקה של מארחים באמצעות התראה מראש
  • שליטה בהגברת טורבו של ליבה יחידה לשיפור העקביות בביצועים
  • רשת Tier_1 לרוחב פס גבוה יותר ברשת

אם אתם משתמשים במופע C4A,‏ C3 או C3D, אתם יכולים גם להשתמש בכונני SSD מקומיים כדי לעמוד בדרישות ביצועים ספציפיות.

אופטימיזציה של העלויות

לעומסי עבודה שבהם העדיפות העיקרית היא אופטימיזציה של העלויות, כמו מסדי נתונים של MySQL עם רמות תנועה נמוכות עד בינוניות או מסדי נתונים שמשמשים בסביבות בדיקה או פיתוח, מומלץ להשתמש במופעי N4 העדכניים. האינסטנסים האלה משתמשים בניהול דינמי של משאבים מהדור הבא של Compute Engine כדי לבצע אופטימיזציה של העלות הכוללת תוך שמירה על ביצועים טובים, בלי האחריות החזקה שמוצעת ב-C4,‏ C4A,‏ C3 ו-C3D. פרטים נוספים זמינים במאמר בנושא ניהול דינמי של משאבים מהדור הבא.

הגדרת הגודל של מכונה וירטואלית

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

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

אם אתם רוצים להשיג ביצועים גבוהים של שאילתות קריאה לשנייה (QPS), מומלץ מאוד להשתמש במאגר הנתונים הזמני (buffer pool) של MySQL שמבוסס על RAM כדי לשמור במטמון נתונים פעילים ולצמצם את הגישה לדיסק. כדי למקסם את היתרונות האלה, מומלץ לבצע את הפעולות הבאות:

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

כדי לצמצם את העלות של שינוי הגודל של מכונה וירטואלית באופן הזה, מומלץ להשתמש במכונה וירטואלית עם יחס גבוה בין RAM לבין מעבדים וירטואליים (vCPU), כדי להימנע מתשלום על מעבדים וירטואליים שלא נעשה בהם שימוש.

כדי להשיג איזון אופטימלי ברוב עומסי העבודה של MySQL, צריך לקבוע את קבוצת העבודה של עומס העבודה, ואז לבחור את צורת המופע הקטנה ביותר שמתאימה לקבוצת העבודה הזו ב-RAM.highmem לצורות המכונות highmem יש זיכרון RAM בנפח של כ-8GB לכל vCPU. כך תקבלו מספיק זיכרון כדי לשמור במטמון קבוצת עבודה גדולה, ועדיין יהיה לכם מספיק CPU כדי להתמודד עם עומס גבוה של שאילתות.

עבור עומסי עבודה עם קבוצות עבודה גדולות אבל שיעורי שאילתות נמוכים, אפשר להשתמש במופעי N4 כדי לבצע אופטימיזציה נוספת של העלות הכוללת באמצעות סוגי מכונות בהתאמה אישית עם זיכרון מורחב, וכך להגדיל עוד יותר את היחס בין זיכרון ה-RAM ל-vCPU.

הגדרת רוחב הפס ברשת של המכונה הווירטואלית

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

הגדרת אחסון בלוקים

‫Google Cloud Hyperdisk הוא הדור היחיד של אחסון בלוקים עמיד שזמין למשפחות עדכניות של מכונות וירטואליות ב-Compute Engine. אנחנו מאמינים ש-Hyperdisk Balanced הוא האפשרות הכי טובה לרוב עומסי העבודה של MySQL. מידע נוסף על Hyperdisk זמין במאמרי העזרה בנושא Hyperdisk.

Google Cloud Hyperdisk

התכונות של Hyperdisk Balanced:

  • זמן אחזור קצר של כונן SSD במחיר נמוך
  • הגדרות ביצועים גבוהים לאפליקציות שזקוקות להן
  • עמידות של יותר מ-99.999% כדי להגן מפני הסיכון של כשל בחומרה והשחתת נתונים שקטה, שקיימים בכל התעשייה
  • הצפנה של כל הנתונים במצב מנוחה ב-Hyperdisk באמצעות מפתחות הצפנה שמנוהלים על ידי Google או על ידי הלקוח

בחירת רמת הביצועים

ב-Hyperdisk Balanced, אתם בוחרים את רמת הביצועים בנפרד מגודל האחסון של הדיסק, כך שאתם יכולים לבצע אופטימיזציה של ביצועי מסד הנתונים ולשלם רק על משאבי הקלט/פלט (I/O) שדרושים לעומס העבודה. אם מאגר הנתונים הזמני של מסד נתונים מסוג MySQL גדול יותר מקבוצת העבודה שלו, במהלך פעולות במצב יציב הוא יכול להציג כמעט את כל שאילתות הקריאה מתוך מאגר הנתונים הזמני, בלי לגשת לדיסק.

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

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

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

שינוי גודל הדיסק

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

  1. שימוש בהגדרת ברירת המחדל כל דיסק מגיע עם לפחות 3,000 פעולות קלט/פלט בשנייה (IOPS) ועם תפוקה של 140 מיבי-בייט לשנייה (MiBps). זה מספיק לעומסי עבודה בסיסיים של MySQL ולנפחי אתחול של מערכת ההפעלה (OS). אם תרחיש השימוש שלכם יגדל, תוכלו לשנות את ביצועי הקלט/פלט שהוקצו לפי דרישה בלי להפסיק את עומס העבודה.
  2. מדידת השימוש הקיים. אם מסד הנתונים כבר פועל בסביבה אחרת, צריך לתעד את קצב ה-IOPS ואת קצב העברת הנתונים של הדיסק ברמת פירוט של דקה אחת או פחות. אחרי שיהיו לכם נתונים של שבוע עד שבועיים, כך שקבוצת הדגימה תכלול תנודות בעומס ואירועי תחזוקה רגילים, בוחרים ערך גבוה באחוזון ממערך הנתונים הזה ומוסיפים מאגר קטן כדי להתחשב בצמיחה אורגנית או בשימוש לא צפוי.
  3. אפשר להעריך את הצרכים שלכם ולשנות אותם בהמשך. אם אין לכם מקור נתונים קיים, יכול להיות שתצטרכו להעריך את צורכי הביצועים שלכם בהתחלה, ואז לשפר אותם אחרי ההטמעה. מומלץ להקצות ערך גבוה יותר ממה שאתם חושבים שתצטרכו בהתחלה, כדי שלא יהיו צווארי בקבוק בביצועים של עומס העבודה. לאחר מכן, תוכלו להקטין את הביצועים שהוקצו כך שיתאימו לעומס העבודה.

שיפור הביצועים של הדיסק

אפשר להגדיל את הביצועים של כל דיסק Hyperdisk Balanced עד למקסימום של 160,000 IOPS ו-2,400MBps של תפוקה. גודל המכונה הווירטואלית עוזר לקבוע את מגבלות הביצועים המקסימליות של Hyperdisk, כך שאם אתם רוצים ביצועים גבוהים מאוד של Hyperdisk, יכול להיות שתצטרכו להגדיל את מספר ליבות המכונה הווירטואלית. אם עומסי העבודה התובעניים ביותר שלכם צריכים ביצועים גבוהים יותר של דיסק ממה שדיסק Hyperdisk Balanced יחיד יכול לספק, אתם יכולים להשתמש באחת מהשיטות הבאות כדי ליצור פס של כמה דיסקים מסוג Hyperdisk Balanced:

  • שדרוג ל-Hyperdisk Extreme
  • להשתמש במנגנון אחר של מערך יתיר של דיסקים עצמאיים (RAID), כמו mdadm

כשמגדילים את מסדי הנתונים של MySQL, אפשר להגדיל באופן דינמי את הקיבולת והביצועים של הדיסקים בלי השבתה. הפעולה הזו משפרת את הביצועים של עומסי עבודה בסגנון עיבוד אנליטי אונליין (OLAP) שמבצעים הצטרפויות מורכבות גדולות שלא נכנסות ל-RAM ועוברות לדיסק. במקרים נדירים, עומסי עבודה של MySQL שדורשים זמן אחזור נמוך במיוחד לאחסון ויכולים לסבול אובדן נתונים יכולים לאחסן את מערך הנתונים המלא שלהם ב-Local SSD. אפשר גם להשתמש בפתרונות ההיברידיים הבאים כדי לשפר את זמן האחזור של הקריאה ולהגביל את הירידה בעמידות:

  • שיקוף של קבוצת הנתונים בין Hyperdisk לבין Local SSD.
  • משתמשים במנהל נפחים כדי להגדיר Local SSD כמטמון לנתונים שמאוחסנים ב-Hyperdisk בסיסי.

שימוש בתכונות נוספות של Hyperdisk

בנוסף, Hyperdisk מספקת את התכונות הבאות, שיכולות לשפר או לפשט את תהליכי העבודה של זמינות גבוהה והתאוששות מאסון במקום:

מידע נוסף על הגדרת התכונות האלה באמצעות MySQL ל-Compute Engine מופיע בקטע זמינות גבוהה בהמשך הדף.

אחסון SSD מקומי

בחלק מהקבוצות של מכונות ב-Compute Engine אפשר להשתמש ב-SSD מקומי במקום ב-Hyperdisk. אלה לא אמצעי אחסון עמידים, אבל עומסי עבודה של MySQL משתמשים בהם לעיתים קרובות כדי לאחסן טבלאות זמניות.

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

תכונות נוספות של Compute Engine

אתם יכולים להשתמש בתכונות הבאות של Compute Engine כדי לבצע אופטימיזציה של פריסת MySQL.

Cloud Monitoring

כדי לעקוב אחרי הביצועים של מכונה וירטואלית והשימוש בשירותי התשתית, אפשר להשתמש בCloud de Confiance מסוף. בדף VM Instances (מופעי מכונות וירטואליות), בכרטיסייה Observability (יכולת תצפית), אפשר לעקוב אחרי מדדים שקשורים לביצועים, כמו ניצול המעבד והזיכרון, רוחב הפס ברשת והביצועים שהוקצו למופעים. באופן דומה, בדף Disks, בכרטיסייה Observability, אפשר לעקוב אחרי התפוקה וה-IOPS של נפחי הדיסקים.

כדי להתאים אישית את מדדי הביצועים שמוצגים, אפשר להשתמש ב-Cloud Monitoring כדי ליצור שאילתות. אתם יכולים לבחור את מדדי הביצועים הספציפיים שאתם רוצים לראות בשירותי התשתית. למדדים ספציפיים ל-MySQL,‏ Compute Engine מציע פלאגין של עומס עבודה ב-MySQL.

שיטות מומלצות להגדרת מערכת ההפעלה

  • משתמשים במערכת קבצים מתאימה. ‫Google מתמקדת באופטימיזציה של מערכות הקבצים ext4 ו-XFS של Linux, אבל רוב מערכות הקבצים מתאימות לשימוש עם MySQL.
  • משביתים את האפשרות Transparent Huge Pages (THP) בהגדרות של מערכת ההפעלה הבסיסית. הוראות להשבתת THP מופיעות במאמרי העזרה בנושא THP.
  • אם אתם משתמשים ב-Linux, אתם יכולים להשתמש בדגלים relatime ו-lazytime כדי להגדיר את הטעינה של מערכת הקבצים. השינוי הזה מפחית את תקורה הביצועים שקשורה לעדכון הערכים atime,‏ mtime ו-ctime בקבצים כשהם נקראים, משתנים או כשמשנים את המטא-נתונים שלהם.

שיטות מומלצות להגדרת MySQL

מומלץ להשתמש בהגדרות התצורה הבאות ל-MySQL.

  • משתמשים בגרסה עדכנית של MySQL. ‫Google מתמקדת באופטימיזציה ל-MySQL בגרסה 8.0 ובגרסאות מאוחרות יותר.

  • הגדלת הגודל של מאגר הנתונים הזמני. ‫MySQL משתמשת במאגר הנתונים שלה כדי לשפר את ביצועי הקריאה על ידי שמירת נתונים במטמון ב-RAM, וכך מצמצמת את הגישה לדיסק. גודל מאגר הנתונים הזמני של MySQL הוא 128MiB כברירת מחדל, וזה קטן מדי לרוב תרחישי השימוש המעשיים. מומלץ להגדיל את הגודל של innodb_buffer_pool_size כך שיהיה גדול יותר מהגודל של קבוצת העבודה שאליה האפליקציה ניגשת במסד הנתונים. בדרך כלל התהליך כולל את השלבים הבאים:

    1. מודדים או מעריכים את הגודל של קבוצת העבודה בעותק פעיל של מופע MySQL.
    2. בוחרים גודל וצורה של מכונה וירטואלית (VM) עם מספיק זיכרון RAM כדי להתאים לסט העבודה הזה.
    3. מגדירים את הגודל של מאגר הנתונים הזמני במכונה הווירטואלית כך שינצל את רוב זיכרון ה-RAM הזמין.

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

  • מגדירים את הערך של innodb_flush_log_at_trx_commit כ-1. כך אפשר לוודא שעסקאות כתיבה הן עמידות בדיסק כשהן מאושרות.

  • כדי להפחית את התקורה של הביצועים, צריך לציין ערך עבור innodb_flush_method. ב-MySQL מגרסה 8.0.14 ואילך, מגדירים את הערך של innodb_flush_method ל-O_DIRECT_NO_FSYNC, שהוא אופטימלי, אבל הוא קיים רק בגרסאות האלה. בגרסאות MySQL מוקדמות יותר מ-8.0.14, צריך להגדיר את הערך של innodb_flush_method ל-O_DIRECT.

  • בתרחישי שכפול של זמינות גבוהה, מגדירים את הערך של sync_binlog במופע של מסד הנתונים הראשי ל-1. ‫MySQL משתמש ביומן הבינארי כדי להעביר שינויים ממסד הנתונים הראשי למסד הנתונים המשני, ולכן הוא מבטיח שהיומנים הבינאריים יתבצעו בזמן ביצוע העסקאות, עם השהיית שכפול נמוכה ככל האפשר ויעד נקודת שחזור (RPO) בין מסדי הנתונים.

  • כשמשתמשים ב-MySQL בקבוצות של מכונות מסדרת C, מפעילים את innodb_numa_interleave. כך מאפשרים למאגר הנתונים הזמני של MySQL לנצל את מדיניות הגישה לזיכרון לא אחידה (NUMA).

מתי כדאי להשבית את מאגר הכתיבה הכפולה

מאגר הנתונים הזמני של MySQL לכתיבה כפולה, שמגן מפני כתיבה קטועה, גורם לתקורה של עד 25% בביצועים של עסקאות כתיבה ב-MySQL, ויכול להגדיל את זמן האחזור של העסקאות. ב-Google Cloud Hyperdisk יש הגנה מובנית מפני כתיבה קטועה. אם אתם משתמשים ב-MySQL כדי לכתוב ישירות למערכת קבצים ext4 שפועלת ב-Hyperdisk, אתם יכולים להשבית את מאגר הנתונים הזמני של הכתיבה הכפולה, בתנאי שהגדרתם בצורה נכונה את מערכת הקבצים ואת שכבות התוכנה המתווכות.

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

  • הפעלת מופע MySQL בתוך קונטיינרים, כולל Google Kubernetes Engine או Kubernetes באירוח עצמי.
  • אחסון קבצי MySQL במערכת קבצים XFS, שלא תומכת בגדלים גדולים מספיק של בלוקים ברוב ההגדרות של ליבת Linux.
  • אחסון קובצי MySQL במערך יתיר של דיסקים עצמאיים (RAID) בהגדרה שגורמת לפסיקת דיסקים, כולל mdadm ל-Linux או Storage Spaces ו-Storage Spaces Direct ל-Windows.
  • אחסון קובצי MySQL מעל מנהל נפחים, כולל Logical Volume Manager‏ (LVM) ל-Linux או Storage Spaces ו-Storage Spaces Direct ל-Windows.

  • אחסון קבצי MySQL ב-Hyperdisk עם כונן SSD מקומי שהוגדר כמטמון, באמצעות lvmcache,‏ dm-cache או bcache ל-Linux או Storage Spaces ל-Windows.

  • הפעלת מופע MySQL בתוך מכונה וירטואלית באמצעות וירטואליזציה מקוננת.

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

(אופציונלי) השבתה של מאגר הנתונים הזמני לכתיבה כפולה

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

  1. במערכת הקבצים ext4, צריך להפעיל את התכונה bigalloc ולהגדיר את גודל האשכול של מערכת הקבצים ל-16KiB או למספר גדול יותר שהוא חזקה של 2 וגם כפולה של 16KiB. כך מוודאים שפעולות הכתיבה של MySQL לא יפוצלו לפעולות קלט/פלט נפרדות על ידי מערכת הקבצים לפני שהן מועברות ל-Hyperdisk. אם לא תגדילו את המגבלה או אם תשתמשו בערך קטן מ-16KiB, לא תהיה הגנה מפני כתיבה קטועה. לדוגמה, אם גודל האשכול הוא 16KiB, ההגדרה הזו מתבצעת בזמן יצירת מערכת הקבצים:

    mkfs.ext4 -O bigalloc -C 16384 /dev/<device-name>

  2. משביתים את innodb_doublewrite ומגדירים את innodb_flush_method לערך O_DIRECT או O_DIRECT_NO_FSYNC (בהתאם לגרסת MySQL, כמו שמתואר למעלה).

הגדרת זמינות גבוהה (HA) ופתרון גיבוי

מומלץ מאוד להגדיר פתרונות לזמינות גבוהה (HA) ולגיבוי לכל עומסי העבודה הקריטיים של MySQL, כדי להגן עליהם. גם לזמינות גבוהה וגם לגיבוי, הגורמים הבאים הם הכי חשובים:

פתרונות HA בדרך כלל מכוונים ל-RTO ו-RPO קרובים לאפס, אבל הם מספקים הגנה רק מפני כשלים בתשתית. פתרונות גיבוי מיועדים לחלונות זמן ארוכים יותר של RTO ו-RPO, אבל הם מספקים כיסוי למגוון רחב יותר של תרחישי כשל, כמו:

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

הגדרת זמינות גבוהה (HA)

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

ב-MySQL אפשר להשתמש ברפליקציה במצבים הבאים:

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

בשני המצבים, ה-RTO נקבע לפי המהירות שבה בדיקות תקינות מבצעות את הפעולות הבאות:

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

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

  • אותו אזור שבו נמצא המופע הראשי
  • תחום אחר באזור שבו נמצא השרת הראשי
  • אזור אחר מהאזור שבו נמצא הקמפיין הראשי

כדי לשמור על זמינות גבוהה גם במהלך הפסקות חשמל אזוריות, מומלץ להשתמש בהגדרה הבאה:

  • מאתרים את המכונות הראשיות ואת מכונות היתירות כשל בתחומים (zones) שונים, בין אם הם נמצאים באותו אזור ובין אם לא.
  • להשתמש בשכפול אסינכרוני. הסיבה לכך היא שאם אתם משתמשים בשכפול חצי-סינכרוני, מיקום של המופעים הראשיים והמופעים למעבר לגיבוי (failover) באזורים נפרדים עלול לגרום לזמן אחזור גבוה של אישורי עסקאות כתיבה.
  • אם אתם צריכים RPO אפס, אתם יכולים להשתמש ב-Hyperdisk Balanced High Availability, שמאפשר לכם לשכפל דיסק באופן סינכרוני בשני אזורים באותו אזור. פרטים נוספים זמינים במדריך של Google בנושא אספקת שירותי זמינות גבוהה באמצעות Hyperdisk High Availability. כשמגדירים Hyperdisk Balanced High Availability, מומלץ לשלב עם קבוצות מנוהלות של מופעים עם שמירת מצב כדי לאבחן בעיות בסטטוס של המופעים ולהפוך את פעולות השחזור לאוטומטיות.

הגדרת תוכנית לגיבוי ולעמידות נתונים

תוכניות גיבוי וחוסן נתונים עוזרות למנוע אובדן נתונים במהלך כשלים כמו מחיקת נתונים בטעות, מתקפות תוכנת כופר ואסונות טבע. אפשר גם להשתמש בהם כאחסון נתונים בשימוש נדיר (cold storage) לצורכי תאימות וביקורת. ב-MySQL יש הרבה מתודולוגיות גיבוי שאפשר לבחור מתוכן. חלק מהן פועלות ברמת מסד הנתונים וחלק ברמת נפח האחסון. כשבוחרים מתודולוגיה, צריך להתחשב בעיקר בדרישות של RTO ו-RPO.

גיבוי ברמת מסד הנתונים

לגיבויים ברמת מסד הנתונים, כדאי להשתמש באפשרויות הבאות ש-MySQL מספקת:

  • גיבויים מצטברים שמבוססים על רישום ביומן בינארי,שיוצרים קובצי dump של נתונים לוגיים. לדוגמה:
  • כלים שמנהלים את תהליך הגיבוי בשבילכם, כמו MySQL Enterprise Backup.

מידע נוסף על אפשרויות הגיבוי ברמת מסד הנתונים ב-MySQL זמין במאמר גיבוי ושחזור במסמכי התיעוד של MySQL.

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

שימוש ב-Hyperdisk ליצירת תמונת מצב ושיבוט ברמת האחסון

לגיבויים ברמת האחסון, מומלץ להשתמש במוצרי Hyperdisk כדי ליצור snapshot, לשכפל ולתעד בדרכים אחרות תצוגה של מסד הנתונים של MySQL בנקודת זמן מסוימת. ה-RPO בגישה הזו תלוי בתדירות שבה אתם מצלמים תמונות מצב של מסד הנתונים, וה-RTO תלוי בפתרון הספציפי שבו אתם משתמשים.

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

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

קובצי ה-Snapshot המיידיים של Hyperdisk, וגם קובצי ה-Snapshot הרגילים והארכיוניים שלו, הם עקביים במקרה של קריסה בדיסק יחיד. המשמעות היא שכשתבצעו שחזור מתמונת מצב, מסד הנתונים של MySQL יצטרך להריץ את שלבי השחזור הרגילים של InnoDB כדי להחזיר את היומנים וקובצי הנתונים למצב עקבי. בהתאם להגדרות של יומן Redo של InnoDB, יכול להיות שהדבר יאריך את זמן ההתאוששות. הדפוסים הבאים יכולים לסבך עוד יותר את המאמצים שלכם ליצור תמונת מצב עקבית של מסד הנתונים:

  • קבצי מסד הנתונים של MySQL מפוזרים בכמה אמצעי אחסון.
  • אתם משתמשים בכלי RAID של תוכנת Linux, כמו mdadm.
  • הפרדתם את מיקומי האחסון המוגדרים של MySQL במערכות קבצים בדיסקים שונים.

כדי ליצור תמונת מצב שלא דורשת שחזור אחרי שחזור תמונת מצב, מבצעים את השלבים הבאים:

  1. לנעול באופן זמני את גישת הכתיבה למסד הנתונים של MySQL.
  2. כדי לנקות את כל המאגרים בתהליך לכונן, משתמשים בפקודות LOCK INSTANCE FOR BACKUP ו-FLUSH TABLES WITH READ LOCK.
  3. מפעילים את הפעולות של תמונת המצב.

  4. בתרחישים של כמה דיסקים, אחרי שמבצעים flush ברמת MySQL, מריצים את הפקודות sync ו-fsfreeze בשרת כדי לבצע flush של כל הכתיבות שמתבצעות לדיסק ולהשהות כתיבות נכנסות חדשות ברמת מערכת הקבצים.

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

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