העברה מ-AWS אל Google Cloud: העברה מ-Amazon RDS ל-SQL Server אל Cloud SQL ל-SQL Server

Last reviewed 2024-06-28 UTC

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

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

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

המסמך הזה הוא חלק מסדרה של מסמכים בנושא מעבר מ-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. בודקים את תוכנית ההעברה.

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

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

הקטעים הבאים מבוססים על המידע במסמך Migrate to Google Cloud: Assess and discover your workloads.

יצירת מלאי של מופעי Amazon RDS

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

יכול להיות שאין תכונות, מפרטים של מופעים או פעולות דומים ב-Amazon RDS וב-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 יכול להמליץ על פתרון Google Cloud יעד, כולל גודל והארכיטקטורה הראשוניים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כדאי לחשוב איך לבצע את המשימות הבאות:

  • הגדרת מדיניות אבטחה והחלתה על המופעים: לדוגמה, יכול להיות שתצטרכו להחליף את קבוצות האבטחה של אמזון. אתם יכולים להשתמש בתפקידים של Google IAM, בכללי חומת האש של VPC וב-VPC Service Controls כדי לשלוט בגישה למופעי Cloud SQL ולהגביל את הנתונים בתוך VPC. אם אתם מתכננים להשתמש באימות Windows עם Cloud SQL ל-SQL Server, אתם צריכים לפרוס את שירות מנוהל ל-Microsoft AD ולהתחבר לתשתית הקיימת של Active Directory.
  • החלת תיקון על המופעים והגדרתם: יכול להיות שתצטרכו לעדכן את כלי הפריסה הקיימים. לדוגמה, יכול להיות שאתם משתמשים בהגדרות תצורה מותאמות אישית בקבוצות פרמטרים או בקבוצות אפשרויות של Amazon. יכול להיות שתצטרכו להתאים את כלי ההקצאה כדי להשתמש ב-Google Cloud Storage או ב-Secret Manager כדי לקרוא רשימות כאלה של הגדרות בהתאמה אישית.
  • ניהול תשתית המעקב וההתראות: קטגוריות המדדים של מופעי מסד הנתונים של מקור Amazon מספקות יכולת צפייה במהלך תהליך ההעברה. קטגוריות המדדים עשויות לכלול את Amazon CloudWatch,‏ Performance Insights,‏ Enhanced Monitoring ורשימות תהליכים של מערכת ההפעלה.

השלמת ההערכה

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

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

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

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

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

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

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

מעקב והתראות

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

העברת מופעים של Amazon RDS ל-SQL Server אל Cloud SQL ל-SQL Server

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • לגיבויים של מסדי נתונים גדולים מ-5TB, צריך להשתמש בגיבוי מפוספס (גיבוי של כמה קבצים).
  • כשמשתמשים בגיבוי מפוספס, אי אפשר לגבות או לשחזר יותר מ-10 קבצי גיבוי בו-זמנית.
  • צריך לגבות לקטגוריית Amazon S3 באותו אזור Amazon שבו נמצא מופע מסד הנתונים של המקור.
  • הגיבויים לא כוללים את ההתחברויות, ההרשאות והתפקידים בשרת SQL, כי הם נמצאים ברמת המופע. כדי להעביר את סוג הנתונים הזה ממופע המקור למופע היעד, צריך להשתמש בסקריפטים של PowerShell או בכלים כמו DBAtools.

לפרטים על מגבלות ושיטות מומלצות, אפשר לעיין במאמרים שיטות מומלצות לייבוא וייצוא נתונים באמצעות Cloud SQL ל-SQL Server ובעיות ידועות ב-Cloud SQL ל-SQL Server.

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

שימוש בגישות אחרות עשוי לספק יותר שליטה וגמישות בתהליך ההעברה של תחזוקה מתוזמנת.

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

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

גישות אחרות:

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

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

  • שימוש באשף הייבוא והייצוא של SQL Server מבית מיקרוסופט: הכלי הזה משתמש ב-SQL Server Integration Services ‏ (SSIS) ומאפשר לייבא נתונים ממקורות שונים, כמו מנועי מסדי נתונים אחרים או קבצים שטוחים.

  • שימוש באשף ליצירה ולפרסום של סקריפטים של SQL Server ובכלי bcp: הכלי הזה הוא חלק מ-Microsoft SQL Server Management Studio.

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

  • שימוש בשכפול של קובץ snapshot, אם המקור שלכם משתמש ב-Amazon RDS Standard:

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

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

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

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

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

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

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

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

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

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

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

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

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

Database Migration Service תומך בהעברות הומוגניות ל-Cloud SQL ל-SQL Server, כשהמקור הוא Amazon RDS.

‫Database Migration Service הוא כלי פשוט וחסכוני. מומלץ להשתמש ב-Database Migration Service במקרים הבאים:

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

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

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

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

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

‫Cloud SQL תומך בשכפול ל-SQL Server. עם זאת, Standard Amazon RDS for SQL Server יכול להיות רק מנוי. שכפול מובנה מ-Amazon RDS Standard לא זמין. אפשר להגדיר רק את Amazon RDS Custom for SQL Server כ-Publisher מובנה.

רשימה של תכונות נתמכות ולא נתמכות ב-Amazon RDS זמינה במאמר בנושא Amazon RDS ל-Microsoft SQL Server.

גישות אחרות להעברה של שכפול רציף

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

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

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

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

    • הקבצים האלה מאוחסנים בקטגוריה של Google Cloud Storage.
    • אפשר לכתוב את הקבצים באופן מיידי למופע מסד הנתונים של היעד באמצעות פונקציות Cloud Run.
    • היכולות של סימון נתונים שהשתנו (CDC) יכולות לעזור לכם להשיג העברה של רפליקות כמעט בזמן אמת.
    • אתם יכולים להזרים CDC אל אגם נתונים ב-Amazon S3 בפורמט Parquet באמצעות AWS Database Migration Service ‏ (AWS DMS).
    • אפשר להטמיע פתרון בהתאמה אישית כדי לקרוא את הקבצים ולכתוב את התוכן שלהם ב-Cloud SQL.

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

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

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

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

  • יתרונות:

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

  • חסרונות:

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

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

  • יתרונות:

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

  • חסרונות:

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

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

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

  • יתרונות:

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

  • חסרונות:

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

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

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

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

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

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

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

TDD

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

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

מטריצת RACI

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

ציר הזמן

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

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

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

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

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

תאריך שלב קטגוריה Tasks תפקיד הספירה לאחור סטטוס
01.11.2023 לפני ההעברה בדיקה יצירת דוח הערכה צוות Discovery -21 הושלמה
11/7/2023 לפני ההעברה הכנה לטירגוט עיצוב סביבת היעד בהתאם לתיאור במסמך העיצוב צוות ההעברה -14 הושלמה
11/15/2023 לפני ההעברה משילות חברה תאריך ההעברה ואישור ההעברה מנהיגות -6 הושלמה
11/18/2023 העברה הגדרת DMS יצירת פרופילי קישוריות Cloud migration engineer -3 הושלמה
11/19/2023 העברה הגדרת DMS יצירה והתחלה של משימות העברה Cloud migration engineer -2 לא הופעל
11/19/2023 העברה מעקב אחרי DMS מעקב אחרי עבודות DMS ושינויים ב-DDL במופע המקור Cloud migration engineer -2 לא הופעל
21.11.2023 העברה Cutover DMS קידום של רפליקה של DMS Cloud migration engineer 0 לא הופעל
21.11.2023 העברה אימות ההעברה אימות של העברת מסד נתונים צוות ההעברה 0 לא הופעל
21.11.2023 העברה בדיקת האפליקציה הפעלת בדיקות של יכולות וביצועים צוות ההעברה 0 לא הופעל
11/22/2023 העברה משילות חברה האם ההעברה תצא לפועל או לא צוות ההעברה 1 לא הופעל
23.11.2023 אחרי ההעברה אימות המעקב הגדרת מעקב צוות התשתית 2 לא הופעל
25.11.2023 אחרי ההעברה אבטחה הסרה של חשבון משתמש ב-DMS צוות האבטחה 4 לא הופעל

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

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

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

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

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

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

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

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

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

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

הכנה של מופע Amazon RDS ודרישות מוקדמות

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

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

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

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

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

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

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

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

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

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

הגדרה של Cloud SQL

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

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

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

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

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

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

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

מידע נוסף על הגדרת Cloud SQL:

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

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

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

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

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

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

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

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

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

מידע נוסף והוראות לגיבויים ספציפיים של מסדי נתונים זמינים במאמרים ייבוא נתונים מקובץ BAK ל-Cloud SQL ל-SQL Server וייצוא נתונים מ-RDS ל-SQL Server. מידע נוסף על אוטומציה של העלאות קובצי יומן עסקאות זמין במאמר בנושא תזמון העלאות של קובצי יומן עסקאות ל-Amazon RDS.

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

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

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

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

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

תהליך ההגדרה המפורט של ההעברה מופיע במאמר העברת מסדי נתונים של SQL Server ל-Cloud SQL ל-SQL Server.

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

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

‫Cloud SQL תומך בשכפול ל-SQL Server. מידע נוסף על רפליקציה משרת חיצוני זמין במאמר העברת נתונים מ-SQL Server 2017 ל-Cloud SQL ל-SQL Server באמצעות רפליקציית snapshot.

כלי צד שלישי

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

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

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

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

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

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

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

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

גיבוי פשוט

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

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

שכפול הפוך

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

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

העברת רפליקציה

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

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

כתיבה כפולה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הכלי לאימות נתונים

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

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

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

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

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

מידע נוסף על DVT זמין במאגר Git ובמאמר Data validation made easy with Google Cloud's Data Validation Tool.

ביצוע ההעברה

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

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

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

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

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

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

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

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

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

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

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

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

ניקוי סביבת המקור והגדרת מכונת Cloud SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • זיהוי משאבים שייתכן שהערכתם הייתה גבוהה מדי:

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

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

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

כדי לצמצם את עלויות הרישוי, במיוחד ב-Cloud SQL ל-SQL Server, מומלץ לשקול את האפשרויות הבאות:

  • אם הסכמי רמת השירות (SLA) מתאימים לדרישות שלכם, תוכלו לעבור ל-SQL Server Standard Edition.
  • משביתים את הריבוי נימים (SMT) ומוסיפים 25% ליבות. יכול להיות שהליבות הנוספות יפצו על ההשפעה על הביצועים כתוצאה מהשבתת SMT. האסטרטגיה הזו יכולה לעזור לכם לצמצם את עלויות הרישוי, אבל היא עלולה להשפיע על הביצועים של המופע. מומלץ לבצע בדיקות עומס במופע כדי לוודא שהסכמי ה-SLA לא מושפעים.
  • כדאי לשקול העברה הטרוגנית מ-Cloud SQL ל-SQL Server אל Cloud SQL ל-PostgreSQL או אל AlloyDB ל-PostgreSQL, בהתאם לעומס העבודה.

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

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

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

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

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

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

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

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

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

  • משנים את ההגדרות הספציפיות למנוע SQL Server כדי שיפעלו בצורה אופטימלית ב-Cloud SQL.

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

  • עדכון נתונים סטטיסטיים באופן קבוע ב-Cloud SQL ל-SQL Server.

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

מידע נוסף על שיפור הביצועים זמין במאמר ביצועים בקטע 'אבחון בעיות' ובמאמר Cloud SQL – ניתוח ביצועים של SQL Server וכוונון שאילתות.

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

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

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

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

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

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

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

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

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

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

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

ב-Cloud SQL ל-SQL Server, כדאי לשקול במיוחד את השיטות המומלצות הבאות:

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

  • אם יש לכם מקרים גדולים, כדאי לפצל אותם למקרים קטנים יותר, אם אפשר:

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

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

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

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

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

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

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

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

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

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

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

מחברים:

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