מעבר מ-AWS אל Google Cloud: מעבר מ-Amazon RDS ומ-Amazon Aurora ל-MySQL אל Cloud SQL ל-MySQL

Last reviewed 2024-08-16 UTC

ב-Google Cloud יש כלים, מוצרים, הדרכה ושירותים מקצועיים שיעזרו לכם לעבור מ-Amazon Relational Database Service (RDS) או מ-Amazon Aurora ל-Cloud SQL ל-MySQL.

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

המסמך הזה מתמקד בהעברה של מסד נתונים הומוגני, שבה מסד הנתונים של המקור ושל היעד משתמשים באותה טכנולוגיה. במדריך להעברת נתונים (מיגרציה) הזה, המקור הוא Amazon RDS או Amazon Aurora ל-MySQL, והיעד הוא Cloud SQL ל-MySQL.

המסמך הזה הוא חלק מסדרה של מסמכים על העברה מ-AWS ל-Google Cloud , שכוללת את המסמכים הבאים:

כדי לבצע את ההעברה ל- Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה ל- Google Cloud: תחילת העבודה.

התרשים הבא ממחיש את נתיב תהליך המיגרציה שלכם.

נתיב העברה עם ארבעה שלבים.

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

  1. הערכה וגילוי של עומסי העבודה והנתונים.
  2. תכנון ובניית בסיס ב- Google Cloud.
  3. מעבירים את עומסי העבודה והנתונים אל Google Cloud.
  4. אופטימיזציה של Google Cloud הסביבה.

למידע נוסף על השלבים במסגרת הזו, קראו את המאמר העברה אל Google Cloud: תחילת העבודה.

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

הערכת סביבת המקור

בשלב ההערכה, אתם קובעים את הדרישות והתלויות כדי להעביר את סביבת המקור אל Google Cloud.

שלב ההערכה חיוני להצלחת ההעברה. אתם צריכים להבין לעומק את עומסי העבודה שאתם רוצים להעביר, את הדרישות שלהם, את יחסי התלות שלהם ואת הסביבה הנוכחית שלכם. כדי לתכנן ולבצע העברה ל- Google Cloud, צריך להבין את נקודת ההתחלה.

שלב ההערכה כולל את המשימות הבאות:

  1. ליצור מלאי מקיף של עומסי העבודה.
  2. מקמו את עומסי העבודה בקטלוג לפי המאפיינים והתלויות שלהם.
  3. להכשיר וללמד את הצוותים שלכם על Google Cloud.
  4. מפתחים ניסויים והוכחות היתכנות ב- Google Cloud.
  5. לחשב את עלות הבעלות הכוללת (TCO) של סביבת היעד.
  6. בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
  7. בוחרים את כלי ההעברה.
  8. מגדירים את תוכנית ההעברה ואת לוח הזמנים.
  9. מאמתים את תוכנית ההעברה.

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

החלקים הבאים מתבססים על המאמר Migrate to Google Cloud: Assess and discover your workloads, ומשלבים את המידע שמופיע בו.

יצירת מלאי של מכונות Amazon RDS או Amazon Aurora

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

יכול להיות של-Amazon RDS או ל-Amazon Aurora ול-Cloud SQL אין תכונות, מפרטי מכונות או פעולות דומים. יכול להיות שחלק מהפונקציות יוטמעו באופן שונה או לא יהיו זמינות. ההבדלים יכולים להיות בתחומים כמו תשתית, אחסון, אימות ואבטחה, רפליקציה, גיבוי, זמינות גבוהה, מודל קיבולת משאבים, שילובים של תכונות ספציפיות של המנוע של מסד הנתונים ותוספים. בהתאם לסוג המנוע של מסד הנתונים, לגודל המכונה ולארכיטקטורה, יכולים להיות גם הבדלים בערכי ברירת המחדל של הגדרות הפרמטרים של מסד הנתונים.

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

כלים להערכות

כדי לקבל הערכה ראשונית של התשתית הקיימת, מומלץ להשתמש ב-Google Cloud Migration Center בשילוב עם כלים ייעודיים אחרים להערכת מסדי נתונים, כמו migVisor ו-Database Migration Assessment Tool ‏ (DMA).

בעזרת Migration Center אתם יכולים לבצע הערכה מלאה של סביבת האפליקציות ומסדי הנתונים, כולל ההתאמה הטכנית להעברת מסד נתונים אל Google Cloud. אתם מקבלים המלצות לגבי הגודל וההגדרות של כל מסד נתונים במקור, ויוצרים דוח עלות בעלות כוללת (TCO) לשרתים ולמסדי נתונים.

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

בנוסף ל-Migration Center, אתם יכולים להשתמש בכלי הייעודי migVisor. הכלי migVisor תומך במגוון מנועים של מסדי נתונים, והוא מתאים במיוחד להעברות הטרוגניות. למבוא על migVisor, קראו את הסקירה הכללית על migVisor.

‫migVisor יכול לזהות פריטי מידע שנוצרו בתהליך הפיתוח (artifacts) ותכונות לא תואמות של מסדי נתונים קנייניים שעלולות לגרום להעברה כברירת מחדל, ויכול להצביע על פתרונות עקיפים. migVisor יכול גם להמליץ על פתרון Google Cloud יעד, כולל גודל וארכיטקטורה ראשוניים.

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

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

במאמר migVisor – כלי להערכת העברה לענן תוכלו לראות כמה דוגמאות לפלט של הערכה.

חשוב לזכור ש-migVisor מגדיל באופן זמני את השימוש בשרת מסד הנתונים. בדרך כלל, העומס הנוסף הזה הוא פחות מ-3%, ואפשר להריץ אותו בשעות שאינן שעות השיא.

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

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

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

כדי להשתמש ב-DMA, מורידים את סקריפטי האיסוף של המנוע של מסד הנתונים ממאגר Git ופועלים לפי ההוראות. שולחים את קובצי הפלט אל Google Cloud לניתוח. Google Cloud יוצרת ומספקת דוח הערכה של מסד הנתונים, ומספקת את השלבים הבאים בתהליך ההעברה.

זיהוי ותיעוד של היקף ההעברה וזמן ההשבתה הסביר

בשלב הזה אתם מתעדים מידע חיוני שמשפיע על אסטרטגיית ההעברה ועל הכלים שבהם תשתמשו. עכשיו אתם יכולים לענות על השאלות הבאות:

  • האם מסדי הנתונים שלכם גדולים מ-5TB?
  • האם יש טבלאות גדולות במסד הנתונים? האם הם גדולים מ-16TB?
  • איפה נמצאים מסדי הנתונים (אזורים ו-zones), ומה הקרבה שלהם לאפליקציות?
  • באיזו תדירות הנתונים משתנים?
  • מהו מודל עקביות הנתונים שלכם?
  • מהן האפשרויות למסדי נתונים של יעדים?
  • עד כמה מסדי הנתונים של המקור והיעד תואמים?
  • האם הנתונים צריכים להיות במיקומים פיזיים מסוימים?
  • האם יש נתונים שאפשר לדחוס ולהעביר לארכיון, או נתונים שלא צריך להעביר בכלל?

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

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

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

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

הערכת תהליך הפריסה והניהול

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

חשבו איך אתם מבצעים את המשימות הבאות:

  • להגדיר ולאכוף מדיניות אבטחה למכונות: לדוגמה, יכול להיות שתצטרכו להחליף את קבוצות האבטחה של אמזון. אתם יכולים להשתמש בתפקידים של Google IAM, בכללי חומת האש של VPC וב-VPC Service Controls כדי לשלוט בגישה למכונות של Cloud SQL ולהגביל את הנתונים בתוך VPC.

  • תיקון והגדרה של המכונות: יכול להיות שתצטרכו לעדכן את כלי הפריסה הקיימים. לדוגמה, יכול להיות שאתם משתמשים בהגדרות אישיות בקבוצות של פרמטרים או בקבוצות של אפשרויות ב-Amazon. יכול להיות שתצטרכו להתאים את כלי ההקצאה שלכם לשימוש ב-Google Cloud Storage או ב-Secret Manager כדי לקרוא רשימות של הגדרות אישיות כאלה.

  • ניהול תשתית המעקב וההתראות: קטגוריות של מדדים למכונות של מסד הנתונים של המקור ב-Amazon מספקות יכולת מעקב במהלך תהליך ההעברה. קטגוריות המדדים יכולות לכלול את Amazon CloudWatch, ‏Performance Insights, ‏Enhanced Monitoring ורשימות של תהליכים במערכת ההפעלה.

השלמת ההערכה

אחרי שיוצרים את המלאי מסביבת Amazon RDS או Amazon Aurora, משלימים את שאר הפעילויות של שלב ההערכה, כפי שמתואר במאמר העברה אל Google Cloud: הערכה וגילוי של עומסי העבודה.

תכנון ובניית הבסיס

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

  • תמיכה בעומסי העבודה בסביבת Google Cloud .
  • כדי להשלים את ההעברה, צריך לחבר את סביבת המקור לסביבת Google Cloud .

שלב התכנון והבנייה מורכב מהמשימות הבאות:

  1. בניית היררכיית משאבים.
  2. הגדרת ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
  3. הגדרת חיוב.
  4. מגדירים את החיבור לרשת.
  5. הקשחת האבטחה.
  6. הגדרת רישום ביומן, מעקב והתראות.

מידע נוסף על כל אחת מהמשימות האלה זמין במאמר העברה אל Google Cloud: תכנון ובניית הבסיס.

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

מעקב והתראות

להשתמש ב-Cloud Monitoring של Google, שכולל מרכזי בקרה מוגדרים מראש לכמה מוצרי Google Cloud , כולל מרכז בקרה למעקב אחרי Cloud SQL. לחלופין, אפשר להשתמש בפתרונות מעקב של צד שלישי שמשולבים עםGoogle Cloud, כמו Datadog ו-Splunk. מידע נוסף זמין במאמר מידע על ניטור מסדי נתונים.

העברת מכונות של Amazon RDS ו-Amazon Aurora ל-MySQL אל Cloud SQL ל-MySQL

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

  1. בוחרים את אסטרטגיית ההעברה: רפליקציה רציפה או תחזוקה מתוזמנת.

  2. בוחרים את כלי ההעברה בהתאם לאסטרטגיה ולדרישות שבחרתם.

  3. להגדיר את תוכנית ההעברה ואת לוח הזמנים לכל העברת מסד נתונים, כולל משימות הכנה וביצוע.

  4. להגדיר את משימות ההכנה שצריך לבצע כדי לוודא שכלי ההעברה פועל כמו שצריך.

  5. הגדירו את משימות הביצוע, שכוללות פעילויות עבודה להטמעת ההעברה.

  6. הגדירו תרחישי גיבוי לכל משימת ביצוע.

  7. מבצעים בדיקות ואימות, שאפשר לעשות בסביבת Staging נפרדת.

  8. מבצעים את ההעברה.

  9. מבצעים את המעבר לסביבת הייצור.

  10. מנקים את סביבת המקור ומגדירים את מכונת היעד.

  11. לבצע כוונון ואופטימיזציה.

כל שלב מתואר בקטעים הבאים.

בחירת אסטרטגיית ההעברה

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

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

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

    • שימוש בגישת Y (כתיבה וקריאה), שהיא סוג של העברה מקבילה, שבה משכפלים את הנתונים גם במופע המקור וגם במופע היעד במהלך ההעברה.
    • שימוש במיקרו-שירות לגישה לנתונים, שמפחית את מאמץ ה-refactoring שנדרש בגישת Y (כתיבה וקריאה).

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

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

תרשים זרימה שיעזור לכם לבחור את אסטרטגיית ההעברה.

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

  • האם אתם יכולים להרשות לעצמכם זמן השבתה?

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

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

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

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

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

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

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

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

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

השיטות הנפוצות הבאות יכולות לעזור לכם לצמצם את זמן ההשבתה ואת ההשפעה:

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

בחירת כלי ההעברה

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

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

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

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

היתרונות של שירותי העברה מנוהלים:

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

  • להבטיח את תקינות הנתונים ואת האבטחה שלהם: הנתונים מועברים באופן מאובטח ואמין ממסד הנתונים של המקור למסד הנתונים של היעד.

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

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

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

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

כלים להעברות מתוזמנות לצורך תחזוקה

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

תרשים זרימה שיעזור לכם לבחור כלי להעברות של תחזוקה מתוזמנת.

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

  • האם אתם מעדיפים שירותי העברה מנוהלים?
    • אם כן, מומלץ להשתמש ב-Database Migration Service.
    • אם לא, מומלץ להעביר באמצעות הגיבויים המובנים של המנוע של מסד הנתונים.

בקטע בחירת הכלים להעברה מפורטים היתרונות של שימוש בשירות העברה מנוהל.

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

‫Database Migration Service להעברת תחזוקה מתוזמנת

‫Database Migration Service מנהל גם את הסנכרון הראשוני וגם את הרפליקציה השוטפת של סימון נתונים שהשתנו (CDC), ומספק את הסטטוס של פעולת ההעברה.

באמצעות Database Migration Service, אתם יכולים ליצור משימות העברה שניתן לנהל ולאמת. מומלץ להשתמש ב-Database Migration Service, כי הוא תומך בהעברות ל-Cloud SQL ל-MySQL באמצעות משימות העברה חד-פעמיות. במסדי נתונים גדולים, אתם יכולים להשתמש בהעברה מקבילה של קובצי dump של נתונים ב-Database Migration Service.

מידע נוסף על ארכיטקטורת ההעברה של מסדי נתונים ועל Database Migration Service זמין במאמרים העברת מסד נתונים ל-Cloud SQL ל-MySQL באמצעות Database Migration Service ונאמנות ההעברה ל-MySQL.

מידע נוסף על המגבלות והדרישות המוקדמות של Database Migration Service מופיע במאמרים הבאים:

גיבויים מובנים של המנוע של מסד הנתונים

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

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

לגיבויים של המנוע של מסד הנתונים יש את המגבלות הכלליות הבאות:

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

אם בחרתם בגישה הזו, כדאי להביא בחשבון את המגבלות והשיטות המומלצות הבאות:

  • אם מסד הנתונים קטן יחסית (פחות מ-10GB), מומלץ להשתמש ב-mysqldump. אין מגבלה קבועה, אבל הגודל האידיאלי של מסד נתונים ל-mysqldump הוא בדרך כלל פחות מ-10GB.

  • אם אתם מייבאים מסדי נתונים שגדולים מ-10GB, יכול להיות שתצטרכו אסטרטגיות אחרות כדי לצמצם את זמן ההשבתה של מסד הנתונים. הנה כמה מהאסטרטגיות האלה:

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

בדרך כלל, קובצי dump וגיבויים של מסדי נתונים לא כוללים חשבונות משתמשים ב-MySQL. כשמתכוננים להעברה, צריך לבדוק את כל חשבונות המשתמשים במכונה המקורית. לדוגמה, אפשר להריץ את הפקודה SHOW GRANTS לכל משתמש כדי לבדוק את קבוצת ההרשאות הנוכחית ולראות אם יש הרשאות שמוגבלות ב-Cloud SQL. באופן דומה, אפשר להשתמש בכלי pt-show-grants של Percona כדי להציג רשימה של הרשאות.

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

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

גישות אחרות להעברה של תחזוקה מתוזמנת

כשמשתמשים בייבוא מנוהל כדי להגדיר רפליקציה ממסד נתונים חיצוני של MySQL, מתבצעת טעינה ראשונית של נתונים ממסד הנתונים החיצוני למכונה של Cloud SQL. בגישה הזו משתמשים בשירות שמחלץ נתונים מהשרת החיצוני – במקרה הזה, מכונת ה-RDS – ומייבא אותם ישירות למכונת Cloud SQL.

במסדי נתונים גדולים (כמה TB), דרך מהירה יותר היא להשתמש בטעינה ראשונית של ייבוא בהתאמה אישית, שמשתמשת בכלים mydumper ו-myloader.

אפשר לייצא את הטבלאות ממסד הנתונים של MySQL לקובצי CSV, ואז לייבא אותם ל-Cloud SQL ל-MySQL. כדי לייצא נתונים ממכונת ה-RDS, אתם יכולים להשתמש ב-AWS Database Migration Service‏ (AWS DMS) ובקטגוריית S3 כיעד.

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

כלים להעברות של רפליקציה רציפה

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

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

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

  • מעדיפים להשתמש בשירותי העברה מנוהלים?

    • אם כן, האם אתם יכולים להרשות לעצמכם כמה שניות של זמן השבתה בכתיבה, בהתאם למספר הטבלאות במסד הנתונים?

      • אם כן, כדאי להשתמש ב-Database Migration Service.
      • אם לא, כדאי לבדוק אפשרויות העברה אחרות.

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

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

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

‫Database Migration Service להעברת רפליקה רציפה

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

אם אתם בוחרים בכלי הזה, כדאי להביא בחשבון את המגבלות והשיטות המומלצות הבאות:

  • הימנעו מטרנזקציות ארוכות במהלך ההעברה. במקרים כאלה, אם אתם לא מבצעים העברה מ-AWS Aurora, מומלץ לבצע העברה מעותק משוכפל לקריאה בלבד.
  • לרשימה המלאה של המגבלות

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

שכפול מובנה של מנוע מסד הנתונים הוא אפשרות חלופית ל-Database Migration Service להעברה רציפה.

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

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

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

דרישות מוקדמות:

  • מוודאים שאתם משתמשים ב-MySQL בגרסה 5.5,‏ 5.6,‏ 5.7 או 8.0 במכונה של Amazon RDS או Amazon Aurora.
  • מוודאים שהיומנים הבינאריים מופעלים.
  • כדי לזרז את שלב ה-dump המלא הראשוני, בחרו מכונה עם מעבד וזיכרון גדולים מספיק.
  • אם אתם צריכים לזרז את שלב ה-CDC, אתם יכולים לנסות להגדיר רפליקציה מקבילה ולהפעיל שטיפה בביצועים גבוהים.
  • אם הרפליקה של Cloud SQL מופעלת עם כתובות IP פנימיות כי כתובת ה-IP היוצאת היא לא סטטית, צריך להגדיר את חומת האש של שרת Amazon RDS או Amazon Aurora כך שתאפשר את טווח כתובות ה-IP הפנימיות שהוקצו לגישה לשירותים פרטיים של רשת ה-VPC שבה הרפליקה של Cloud SQL משתמשת כרשת הפרטית שלה. מידע נוסף זמין במאמרים מידע על שכפול משרת חיצוני והגדרת גישה לשירותים פרטיים.

מגבלות:

  • אם יש לכם טבלאות גדולות בודדות והרבה אינדקסים משניים במסד הנתונים, יכול להיות שה-dump המלא הראשוני יימשך יותר זמן.
  • אם השרת החיצוני מכיל משפטי DEFINER (תצוגות, אירועים, טריגרים או פרוצדורות מאוחסנות), יכול להיות שהשכפול ייכשל, בהתאם לסדר שבו המשפטים האלה מופעלים. DEFINER מידע נוסף על השימוש ועל פתרונות עקיפים אפשריים ב-Cloud SQL.
  • ‫InnoDB הוא המנוע היחיד של מסד הנתונים שנתמך ב-Cloud SQL. העברת MyISAM עלולה לגרום לחוסר עקביות בנתונים ולדרוש אימות נתונים. מידע נוסף זמין במאמר המרת טבלאות מ-MyISAM ל-InnoDB.

גישות אחרות להעברה באמצעות רפליקציה רציפה

גישות אחרות להעברה באמצעות רפליקציה רציפה כוללות את:

  • משנים את מבנה הקוד של האפליקציות כדי לבצע Y (כתיבה וקריאה) או משתמשים במיקרו-שירות (microservice) לגישה לנתונים.

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

  • משכפלים שינויים כמעט בזמן אמת של מכונת MySQL באמצעות Datastream.

    • ‫Datastream הוא שירות ללא שרת (serverless) ל-CDC ולרפליקה, שאפשר להשתמש בו עם Amazon RDS או Amazon Aurora כדי ליצור רפליקה של נתונים ולסנכרן אותם.
    • משתמשים ב-Datastream כדי לשכפל שינויים ממכונת MySQL ל-BigQuery או ל-Cloud Storage, ואז משתמשים ב-Dataflow או ב-Managed Service for Apache Spark כדי להעביר את הנתונים למכונת Cloud SQL.

למידע נוסף על רפליקציה באמצעות Datastream, קראו את המאמרים הבאים:

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

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

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

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

  • היתרונות:

    • מתאים להעברת כמויות גדולות של נתונים והעברות מורכבות.
    • סימון מובנה של נתונים שהשתנו (CDC) ל-SQL Server.
    • תבניות חיבור מוגדרות מראש וצינורות עיבוד נתונים ללא קוד.
    • יכולת לטפל במסדי נתונים גדולים וחיוניים שפועלים בעומס כבד של טרנזקציות.
    • מסירה בדיוק פעם אחת.

  • החסרונות:

למידע נוסף על Striim, קראו את המאמר הפעלת Striim ב- Google Cloud.

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

  • היתרונות:

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

  • החסרונות:

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

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

‫Fivetran היא פלטפורמה אוטומטית להעברת נתונים מחוץ לפלטפורמות של נתונים בענן וביניהן.

  • היתרונות:

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

  • החסרונות:

    • לא קוד פתוח.
    • התמיכה בהמרת נתונים מורכבים מוגבלת.

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

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

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

מומלץ שתיעוד תוכנית ההעברה יכלול את המסמכים הבאים:

  • מסמך עיצוב טכני (TDD)
  • מטריצת RACI
  • לוח זמנים (כמו תוכנית T-Minus)

העברות של מסדי נתונים הן תהליך איטרטיבי, ולעיתים קרובות ההעברות הראשונות איטיות יותר מההעברות הבאות. בדרך כלל, העברות שמתוכננות היטב מתבצעות ללא בעיות, אבל עדיין יכולות לצוץ בעיות לא צפויות. מומלץ שתמיד תהיה לכם תוכנית חזרה למצב קודם. מומלץ לפעול לפי ההנחיות במאמר Migrate to Google Cloud: Best practices for validating a migration plan.

TDD

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

  • דרישות העסק ורמת הקריטיות
  • יעד זמן ההתאוששות (RTO)
  • יעד להתאוששות מאסון (RPO)
  • פרטי ההעברה של מסד הנתונים
  • הערכת המאמץ הנדרש להעברה
  • המלצות לאימות ההעברה

מטריצת RACI

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

ציר הזמן

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

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

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

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

תוכנית T-Minus יכולה להיראות כך:

תאריך שלב קטגוריה Tasks תפקיד T-minus סטטוס
1.11.2023 לפני ההעברה בדיקה יצירת דוח הערכה צוות Discovery -21 הושלמה
07/11/2023 לפני ההעברה הכנת היעד תכנון סביבת היעד כפי שמתואר במסמך התכנון צוות ההעברה -14 הושלמה
15.11.2023 לפני ההעברה ממשל תאגידי תאריך ההעברה ואישור הספירה לאחור מנהיגות -6 הושלמה
18.11.2023 העברה הגדרת DMS יצירת פרופילי חיבור מהנדס העברה לענן -3 הושלמה
19/11/2023 העברה הגדרת DMS יצירה והפעלה של משימות העברה מהנדס העברה לענן -2 לא הופעל
19/11/2023 העברה מעקב אחרי DMS מעקב אחרי משימות DMS ושינויים ב-DDL במכונה של המקור מהנדס העברה לענן -2 לא הופעל
21.11.2023 העברה מעבר חד למערכת אחרת (cutover) ב-DMS קידום רפליקה של DMS מהנדס העברה לענן 0 לא הופעל
21.11.2023 העברה אימות ההעברה אימות העברה של מסדי נתונים צוות ההעברה 0 לא הופעל
21.11.2023 העברה בדיקת האפליקציה הרצת בדיקות של יכולות וביצועים צוות ההעברה 0 לא הופעל
22.11.2023 העברה ממשל תאגידי אימות ההעברה – כן או לא צוות ההעברה 1 לא הופעל
23.11.2023 אחרי ההעברה אימות המעקב הגדרת המעקב צוות התשתית 2 לא הופעל
25.11.2023 אחרי ההעברה אבטחה הסרת חשבון משתמש ב-DMS צוות האבטחה 4 לא הופעל

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

אם יש לכם כמה מסדי נתונים שאתם רוצים להעביר, תוכנית ההעברה צריכה לכלול משימות לכל ההעברות.

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

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

משימות מקבילות להעברת מסדי נתונים.

בדוגמה שמוצגת בתרשים, מסדי הנתונים 1-4 הם קבוצה של מסדי נתונים קטנים שמועברים בו-זמנית.

הגדרת משימות ההכנה

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

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

  • הכנות ודרישות מוקדמות למכונות של Amazon RDS או Amazon Aurora
  • הכנת מסד הנתונים של המקור ודרישות מוקדמות
  • הגדרת Cloud SQL
  • הגדרה ספציפית להעברה

הכנה ודרישות מוקדמות למכונה של Amazon RDS או Amazon Aurora

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

  • בהתאם לנתיב ההעברה, יכול להיות שתצטרכו לאפשר חיבורים מרחוק במכונות ה-RDS. אם מכונת ה-RDS מוגדרת כפרטית ב-VPC, צריך להיות קישוריות RFC 1918 פרטית בין אמזון לבין Google Cloud.

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

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

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

  • כדי לקבל תוצאות אופטימליות, מומלץ להעביר מרפליקה לקריאה בלבד, אלא אם אתם מעבירים מ-Amazon Aurora. בנוסף, מומלץ להתחיל את תהליך ההעברה בתקופה שבה הפעילות במסד הנתונים נמוכה.

  • ב-MySQL, שם המארח מוגבל ל-60 תווים. שמות המארחים של מסדי נתונים ב-Amazon RDS בדרך כלל ארוכים יותר מ-60 תווים. אם זה המצב במסד הנתונים שאתם מעבירים, צריך להגדיר הפניית DNS כדי ליצור רשומת CNAME שמשייכת את שם הדומיין לשם הדומיין של מכונת מסד הנתונים ב-RDS.

  • אם אתם משתמשים ברפליקציה מובנית, אתם צריכים להגדיר את המכונה של Amazon RDS או Amazon Aurora לרפליקציה. כדי להשתמש ברפליקציה מובנית או בכלים שמשתמשים בה, צריך להגדיר את הרישום ביומן הבינארי של MySQL ל-ROW.

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

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

הכנת מסד הנתונים של המקור ודרישות מוקדמות

  • אם אתם בוחרים להשתמש ב-Database Migration Service, אתם צריכים להגדיר את מסד הנתונים של המקור לפני שאתם מתחברים אליו. לפני שמפעילים את משימות ההעברה, בודקים אותן. מידע נוסף זמין במאמר הגדרת המקור ל-MySQL.
  • בהתאם למנוע של מסד הנתונים, יכול להיות שתצטרכו לשנות תכונות מסוימות. לדוגמה, Cloud SQL ל-MySQL תומך רק במנוע מסד הנתונים InnoDB. צריך לשנות את טבלאות MyISAM ל-InnoDB.
  • בחלק מכלי ההעברה של צד שלישי, כל העמודות ב-LOB צריכות להיות ניתנות להגדרה כ-null. אם יש עמודות LOB שהן NOT NULL, צריך להסיר את האילוץ הזה במהלך ההעברה.

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

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

הגדרת Cloud SQL

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

לפני שיוצרים את המכונות של Cloud SQL, צריך לוודא שהמאפיינים והדרישות הבאים מתקיימים, כי אי אפשר לשנות אותם אחר כך בלי ליצור מחדש את המכונות.

  • חשוב לבחור בקפידה את הפרויקט ואת האזור של מכונות היעד ב-Cloud SQL. אי אפשר להעביר מכונות של Cloud SQL בין פרויקטים ואזורים ב- Google Cloud בלי להעביר נתונים.
  • עוברים לגרסה ראשית תואמת ב-Cloud SQL. לדוגמה, אם במקור משתמשים ב-MySQL 8.0.34 ב-Amazon RDS או ב-Amazon Aurora, צריך לעבור ל-Cloud SQL ל-MySQL בגרסה 8.0.34.
  • אם אתם משתמשים בגיבויים מובנים של המנוע של מסד הנתונים או ב-Database Migration Service, אתם צריכים לשכפל את פרטי המשתמשים בנפרד. ב-Cloud SQL, המשתמשים מנוהלים באמצעות Google IAM. לפרטים נוספים, קראו את המגבלות בקטע גיבויים מובנים של המנוע של מסד הנתונים.
  • בודקים את דגלי ההגדרה של המנוע של מסד הנתונים ומשווים בין הערכים של מכונת המקור והיעד. חשוב להבין את ההשפעה שלהם ואם הם צריכים להיות זהים או לא. לדוגמה, מומלץ להריץ את הפקודה SHOW VARIABLES במסד הנתונים של המקור לפני ההעברה, ואז להריץ אותה שוב במסד הנתונים של Cloud SQL. מעדכנים את הגדרות הדגלים לפי הצורך במסד הנתונים של Cloud SQL כדי לשכפל את הגדרות המקור. שימו לב שלא כל הדגלים של MySQL מותרים במכונה של Cloud SQL.

מידע נוסף על הגדרת Cloud SQL זמין במאמרים הבאים:

הגדרה ספציפית להעברה

אם אתם מייבאים קובצי SQL מוכנים לשימוש ל-Cloud SQL, יכול להיות שתצטרכו ליצור קטגוריה של Cloud Storage. הקטגוריה מאחסנת את ה-dump של מסד הנתונים.

אם אתם משתמשים ברפליקציה, אתם צריכים לוודא שלרפליקה של Cloud SQL יש גישה למסד הנתונים הראשי. אפשר לקבל את הגישה הזו באמצעות אפשרויות הקישוריות המתועדות.

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

ברוב הכלים של צד שלישי, צריך להקצות משאבים ספציפיים להעברה. לדוגמה, כדי להשתמש ב-Striim, צריך להתחיל ב-Google Cloud Marketplace. לאחר מכן, כדי להגדיר את סביבת ההעברה ב-Striim, אתם יכולים להשתמש ב-Flow Designer כדי ליצור ולשנות אפליקציות, או לבחור תבנית קיימת. אפשר גם לכתוב קוד לאפליקציות באמצעות שפת התכנות Tungsten Query Language‏ (TQL). בעזרת לוח הבקרה לאימות נתונים, אתם יכולים לקבל ייצוג חזותי של הנתונים שמטופלים על ידי אפליקציית Striim.

אחרי שההעברה מסתיימת ומאומתת, אתם יכולים להוציא משימוש את המשאבים שמקשרים בין סביבת Amazon לסביבתGoogle Cloud .

למידע נוסף, קראו את המאמרים הבאים:

הגדרת משימות הביצוע

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

גיבויים מובנים של המנוע של מסד הנתונים

כדי לבצע העברה חד-פעמית, משתמשים בכלי mysqldump כדי ליצור גיבוי שמעתיק את הנתונים מ-Amazon RDS למחשב הלקוח המקומי. הוראות מפורטות זמינות במאמר ייבוא קובץ SQL מוכן לשימוש ל-Cloud SQL ל-MySQL.

אתם יכולים לבדוק את הסטטוס של פעולות הייבוא והייצוא של מכונת Cloud SQL.

משימות העברה ב-Database Migration Service

הגדירו משימות העברה ב-Database Migration Service כדי להעביר נתונים ממכונה במקור למסד הנתונים ביעד. משימות ההעברה מתחברות למכונה של מסד הנתונים במקור באמצעות פרופילי חיבור שהמשתמשים מגדירים.

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

ב-Database Migration Service, ההעברה מתחילה בגיבוי מלא ובטעינה ראשונית, ואחריהם מתבצעת העברה רציפה של השינויים ממסד הנתונים במקור למסד הנתונים ביעד.

ל-Database Migration Service נדרשות כמה שניות כדי לקבל את נעילת הקריאה בכל הטבלאות במכונה של Amazon RDS או Amazon Aurora במקור, שנדרשת כדי לבצע את ה-dump המלא הראשוני באופן עקבי. כדי להשיג את נעילת הקריאה, יכול להיות שיהיה צורך בזמן השבתה של כתיבה, בין שנייה אחת ל-49 שניות. זמן ההשבתה תלוי במספר הטבלאות במסד הנתונים, כאשר שנייה אחת תואמת ל-100 טבלאות ו-9 שניות תואמות ל-10,000 טבלאות.

תהליך ההעברה באמצעות Database Migration Service מסתיים בפעולת הקידום. כשמקַדמים מופע של מסד נתונים, מסד הנתונים של היעד מתנתק מהשינויים שמגיעים ממסד הנתונים של המקור, ואז המופע של היעד, שהוא עכשיו עצמאי, מקודם למופע ראשי. הגישה הזו נקראת לפעמים גם "העברה לייצור".

למידע נוסף על משימות העברה ב-Database Migration Service:

במאמר העברת מסד נתונים ל-Cloud SQL ל-MySQL באמצעות Database Migration Service מוסבר בפירוט איך מגדירים את תהליך ההעברה. ב-Database Migration Service, ההעברה מתבצעת על ידי הפעלה והרצה של משימת העברה.

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

אתם יכולים להשתמש ברפליקציה מובנית מ-Amazon RDS למכונה חיצונית של Cloud SQL ל-MySQL.

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

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

הוראות מפורטות להגדרת רפליקציה מובנית משרת חיצוני כמו Amazon RDS או Amazon Aurora ל-MySQL, זמינות במאמרים מידע על רפליקציה משרת חיצוני והגדרת Cloud SQL והשרת החיצוני לרפליקציה.

למידע נוסף ולהנחיות, קראו את המאמרים הבאים:

כלי צד שלישי

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

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

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

כדי להגדיר את סביבת ההעברה ב-Striim, אתם יכולים להשתמש בתכונה Flow Designer כדי ליצור ולשנות אפליקציות, או לבחור מתוך כמה תבניות קיימות. אפשר גם לתכנת אפליקציות באמצעות שפת התכנות TQL.

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

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

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

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

הגדרת תרחישים חלופיים

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

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

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

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

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

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

Simple fallback

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

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

רפליקציה הפוכה

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

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

רפליקציה קדימה

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

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

כתיבה כפולה

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

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

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

ביצוע בדיקות ואימות

המטרות של השלב הזה הן לבדוק ולאמת את הדברים הבאים:

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

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

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

יכול להיות שהגדרות האחסון בסביבת המקור לא ימופו ישירות ליעדים בסביבתGoogle Cloud . לדוגמה, הגדרות מאמצעי אחסון מסוג General Purpose SSD (gp2 ו-gp3) עם ביצועי IOPS מתפרצים או Provisioned IOPS SSD. כדי להשוות בין מכונות היעד ולהתאים את הגודל שלהן, צריך להשוות בין מכונות המקור בשלבי ההערכה והאימות.

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

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

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

  • ‫HammerDB: כלי בקוד פתוח להשוואה בין מסדי נתונים ולבדיקת עומסים. הוא תומך בעומסי עבודה מורכבים של עסקאות וניתוח נתונים, על סמך תקנים מקובלים בתחום, בכמה מנועים של מסדי נתונים (גם TPROC-C וגם TPROC-H). ל-HammerDB יש תיעוד מפורט וקהילת משתמשים רחבה. אתם יכולים לשתף ולהשוות תוצאות בין כמה מנועים של מסדי נתונים והגדרות אחסון. מידע נוסף זמין במאמרים בדיקת עומסים של SQL Server באמצעות HammerDB והשוואה בין ביצועי Amazon RDS SQL Server באמצעות HammerDB.
  • כלי ההשוואה לשוק DBT2: השוואה לשוק שמותאמת ל-MySQL. קבוצה של ערכות עומסי עבודה של מסדי נתונים מדמה אפליקציה של חברה שבבעלותה מחסנים, וכוללת שילוב של טרנזקציות קריאה וכתיבה. הכלי הזה מתאים אם אתם רוצים להשתמש בבדיקת עומס מוכנה מראש של עיבוד עסקאות אונליין (OLTP).
  • ‫DbUnit: כלי לבדיקת יחידות בקוד פתוח שמשמש לבדיקת אינטראקציות של מסדי נתונים רלציוניים ב-Java. ההגדרה והשימוש פשוטים, והוא תומך בכמה מנועים של מסדי נתונים (MySQL,‏ PostgreSQL,‏ SQL Server ועוד). עם זאת, לפעמים ביצוע הבדיקה יכול להיות איטי, בהתאם לגודל ולמורכבות של מסד הנתונים. אנחנו ממליצים על הכלי הזה כשחשוב שהתהליך יהיה פשוט.
  • ‫DbFit: מסגרת לבדיקת מסדי נתונים בקוד פתוח, שתומכת בפיתוח קוד מבוסס-בדיקות ובבדיקות אוטומטיות. הוא משתמש בתחביר בסיסי ליצירת מקרי בדיקה, וכולל בדיקות מבוססות-נתונים, ניהול גרסאות ודיווח על תוצאות הבדיקות. עם זאת, התמיכה בשאילתות ובעסקאות מורכבות מוגבלת, ואין לו תמיכה קהילתית גדולה או תיעוד נרחב בהשוואה לכלים אחרים. אנחנו ממליצים על הכלי הזה אם השאילתות שלכם לא מורכבות ואתם רוצים לבצע בדיקות אוטומטיות ולשלב אותן בתהליך האינטגרציה הרציפה וההעברה הרציפה.

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

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

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

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

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

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

אם אתם משתמשים ב-Database Migration Service ככלי להעברה, קראו את המאמר אימות העברה.

Data Validation Tool

כדי לבצע אימות נתונים, מומלץ להשתמש ב-Data Validation Tool ‏ (DVT). כלי ה-DVT הוא כלי CLI של Python בקוד פתוח, שנתמך על ידי Google ומספק פתרון אוטומטי וניתן לחזרה לאימות בסביבות שונות.

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

הכלי DVT תומך בהרבה Google Cloud מקורות נתונים, כולל AlloyDB ל-PostgreSQL,‏ BigQuery,‏ Cloud SQL,‏ Spanner,‏ JSON וקובצי CSV ב-Cloud Storage. אפשר גם לשלב אותו עם פונקציות Cloud Run ו-Cloud Run כדי להפעיל ולתזמר אירועים.

ה-DVT תומך בסוגי האימות הבאים:

  • השוואות ברמת הסכימה
  • עמודה (כולל "AVG",‏ "COUNT",‏ "SUM",‏ "MIN",‏ "MAX",‏ "קיבוץ לפי" ו-"STRING_AGG")
  • שורה (כולל גיבוב והתאמה מדויקת בהשוואות בין שדות)
  • השוואה בין תוצאות של שאילתות בהתאמה אישית

מידע נוסף על DVT זמין במאגר Git ובמאמר אימות נתונים בקלות באמצעות Data Validation Tool של Google Cloud.

ביצוע ההעברה

משימות ההעברה כוללות את הפעילויות שתומכות בהעברה ממערכת אחת לאחרת.

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

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

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

ביצוע המעבר לייצור

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

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

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

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

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

כדאי לפעול לפי השיטות המומלצות הבאות למעבר לסביבת הייצור:

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

ניקוי סביבת המקור והגדרת המכונה של Cloud SQL או AlloyDB ל-PostgreSQL

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

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

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

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

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

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

בנוסף לניקוי סביבת המקור, צריך לבצע את ההגדרות הקריטיות הבאות במכונות של Cloud SQL:

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

אל תתחילו פעולה ניהולית לפני שהפעולה הקודמת הסתיימה.

למידע נוסף על תחזוקה ושיטות מומלצות, קראו את המאמר מידע על תחזוקה במכונות Cloud SQL.

אופטימיזציה של הסביבה אחרי ההעברה

אופטימיזציה היא השלב האחרון בהעברה. בשלב הזה חוזרים על משימות האופטימיזציה עד שסביבת היעד עומדת בדרישות האופטימיזציה. השלבים של כל איטרציה הם:

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

חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.

מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים העברה ל- Google Cloud: אופטימיזציה של הסביבה ו-Google Cloud Well-Architected Framework: אופטימיזציה של הביצועים.

הגדרת דרישות האופטימיזציה

כדאי לעבור על דרישות האופטימיזציה הבאות לסביבת Google Cloudולבחור את אלה שהכי מתאימות לעומסי העבודה שלכם:

שיפור האמינות והזמינות של מסד הנתונים

ב-Cloud SQL אתם יכולים להטמיע אסטרטגיה של זמינות גבוהה ותוכנית התאוששות מאסון (DR) שתואמת ליעד זמן ההתאוששות (RTO) וליעד נקודת ההתאוששות (RPO). כדי לשפר את האמינות והזמינות, כדאי:

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

למידע נוסף על שיפור האמינות והזמינות של מסד הנתונים, ראו:

שיפור היעילות מבחינת עלות של תשתית מסד הנתונים

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

  • כדי להקצות למסד הנתונים את נפח האחסון המינימלי הנדרש:

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

  • זיהוי משאבים שאולי הוקצו להם יותר מדי משאבים:

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

  • מזהים מכונות שלא דורשות הגדרות של זמינות גבוהה או תוכנית התאוששות מאסון, ומסירים אותן מהתשתית.

  • הסירו טבלאות ואובייקטים שכבר לא נחוצים. אפשר לאחסן אותם בגיבוי מלא או בקטגוריה של Cloud Storage לאחסון בארכיון.

  • בדקו מהו סוג האחסון הכי משתלם (SSD או HDD) לתרחיש לדוגמה שלכם.

    • ברוב תרחישי השימוש, SSD הוא האפשרות היעילה והמשתלמת ביותר.
    • אם מערכי הנתונים שלכם גדולים (10TB או יותר), לא רגישים לזמן אחזור או שהגישה אליהם לא תכופה, יכול להיות ש-HDD יתאים יותר.
    • למידע נוסף, קראו את המאמר בחירה בין אחסון SSD ל-HDD.

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

  • להשתמש ב-Active Assist כדי לקבל תובנות והמלצות לגבי עלויות.

    למידע נוסף ולאפשרויות נוספות, קראו את המאמר Do more with less: Introducing Cloud SQL cost optimization recommendations with Active Assist.

שיפור הביצועים של תשתית מסד הנתונים

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

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

  • מוודאים שהמכונה לא מוגבלת בזיכרון או במעבד (CPU).

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

  • כדי לשפר את ביצועי השאילתות, אפשר להשתמש בלוח הבקרה המוגדר מראש של Query Insights ב-Cloud Monitoring (או בתכונות מובנות דומות של המנוע של מסד הנתונים). מזהים את הפקודות הכי יקרות ומנסים לבצע להן אופטימיזציה.

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

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

  • כדאי להשתמש במהדורת Cloud SQL Enterprise Plus כדי ליהנות ממגבלות מוגדלות של הגדרות המכונה וממטמון נתונים. מידע נוסף זמין במאמר מבוא למהדורות של Cloud SQL.

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

שיפור יכולות התצפיתיות של מסד הנתונים

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

  • ב-Cloud SQL נעשה שימוש בסוכנים מותאמים אישית בזיכרון המובנה כדי לאסוף נתוני טלמטריה של שאילתות.

    • אתם יכולים להשתמש ב-Cloud Monitoring כדי לאסוף מדידות של השירות ושל משאבי Google Cloudשבהם אתם משתמשים. ב-Cloud Monitoring יש מרכזי בקרה מוגדרים מראש לכמה מוצרים של Google Cloud , כולל מרכז בקרה למעקב אחרי Cloud SQL.
    • אתם יכולים ליצור לוחות בקרה בהתאמה אישית שיעזרו לכם לעקוב אחרי המדדים, ולהגדיר מדיניות התראות כדי לקבל התראות בזמן.
    • לחלופין, אפשר להשתמש בפתרונות מעקב של צד שלישי שמשולבים עם Google Cloud, כמו Datadog ו-Splunk.

  • Cloud Logging אוסף נתוני רישום ביומן מרכיבים נפוצים באפליקציות.

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

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

שיטות מומלצות כלליות והנחיות תפעוליות ל-Cloud SQL

כדי להגדיר ולכוונן את מסד הנתונים, כדאי ליישם את השיטות המומלצות ל-Cloud SQL.

הנה כמה המלצות כלליות וחשובות ל-Cloud SQL:

  • אם יש לכם מכונות גדולות, מומלץ לפצל אותן למכונות קטנות יותר, כשאפשר.
  • הגדרת האחסון כך שיתאים לתחזוקה קריטית של מסד הנתונים. חשוב לוודא שיש לכם לפחות 20% מקום פנוי כדי לאפשר פעולות תחזוקה קריטיות של מסד הנתונים ש-Cloud SQL עשוי לבצע.
  • אם יש יותר מדי טבלאות במסד הנתונים, זה יכול להשפיע על משך הזמן של שדרוג מסד הנתונים. באופן אידיאלי, כדאי שיהיו פחות מ-10,000 טבלאות לכל מכונה.
  • בחרו את הגודל המתאים למכונות שלכם כדי להביא בחשבון את שמירת יומן הטרנזקציות (הבינארי), במיוחד במכונות עם פעילות כתיבה גבוהה.

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

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

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

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

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

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

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

לפרטים נוספים, קראו את המאמרים שיטות מומלצות כלליות והנחיות תפעוליות ל-Cloud SQL ל-MySQL.

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

שותפים ביצירת התוכן

מחברים:

תורמים אחרים: