הגדרת MySQL ב-Compute Engine

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

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

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

לגבי עומסי עבודה של MySQL, מומלץ להשתמש בדור האחרון של משפחות המכונות C ו-N, כי הן כוללות צורות שמתאימות לרוב ההגדרות המעשיות של MySQL. Google Cloud בפוסט הזה בבלוג יש מבוא לסדרות המכונות האלה. משפחות המכונות האלה משתמשות ב-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 יש בערך 8GB של RAM לכל 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

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

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

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

  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 לבין SSD מקומי.
  • משתמשים במנהל נפחים כדי להגדיר Local SSD כמטמון לנתונים שמאוחסנים ב-Hyperdisk הבסיסי.

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

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

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

אחסון SSD מקומי

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

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

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

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

Cloud Monitoring

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

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

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

  • משתמשים במערכת קבצים מתאימה. ‫Google מתמקדת באופטימיזציה של מערכות הקבצים ext4 ו-XFS של Linux, אבל רוב מערכות הקבצים מתאימות לשימוש עם MySQL.
  • משביתים את האפשרות Transparent Huge Pages (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) ופתרון גיבוי

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

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

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

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

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

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

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

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

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

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

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

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

  • מאתרים את המופעים הראשיים ואת מופעי הגיבוי באזורים שונים, בין אם הם נמצאים באותו אזור ובין אם לא.
  • שימוש בשכפול אסינכרוני. הסיבה לכך היא שאם אתם משתמשים בשכפול חצי-סינכרוני, איתור המופעים הראשיים והמופעים ליתירות כשל באזורים נפרדים עלול לגרום לזמן אחזור גבוה של אישורי עסקאות כתיבה.
  • אם אתם צריכים 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 ליצירת snapshot ושיבוט ברמת האחסון

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

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

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

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

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

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

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

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

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

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