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

Last reviewed 2024-09-12 UTC

‫Google Cloud מספקת כלים, מוצרים, הנחיות ושירותים מקצועיים להעברה מ-Amazon Relational Database Service ‏ (RDS) או מ-Amazon Aurora אל Cloud SQL ל-PostgreSQL או אל AlloyDB ל-PostgreSQL.

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

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

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

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

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

מעקב והתראות

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

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

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

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

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

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

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

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

  6. מגדירים תרחישי חזרה לכל משימת הפעלה.

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

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

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

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

  11. ביצוע התאמות ואופטימיזציה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אתם יכולים להשתמש בכלי הגיבוי המובנים של PostgreSQL, ‏ pg_dump ו-pg_dumpall, כדי להעביר את Cloud SQL ל-PostgreSQL ואת AlloyDB ל-PostgreSQL. עם זאת, יש מגבלות כלליות על כלי השירות pg_dump ו-pg_dumapall:

  • כדי להעביר מסדי נתונים בגודל של עד 500GB, צריך להשתמש בכלי הגיבוי המובנים. תהליך הגיבוי והשחזור של מסדי נתונים גדולים יכול להימשך זמן רב, ועשוי לדרוש נפח אחסון וזיכרון משמעותיים.
  • הכלי pg_dump לא כולל משתמשים ותפקידים. כדי להעביר את חשבונות המשתמשים והתפקידים האלה, אפשר להשתמש בכלי pg_dumpall.
  • ב-Cloud Storage יש תמיכה בגודל אובייקט יחיד של עד 5 טרה-בייט (TB). אם יש לכם מסדי נתונים גדולים מ-5TB, פעולת הייצוא ל-Cloud Storage תיכשל. במקרה כזה, צריך לפצל את קובצי הייצוא לפלחים קטנים יותר.

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

  • כדאי לדחוס את הנתונים כדי להקטין את העלות ואת משך ההעברה. אפשר להשתמש באפשרות --jobs עם הפקודה pg_dump כדי להריץ מספר נתון של משימות dump בו-זמנית.
  • משתמשים באפשרות -z עם הפקודה pg_dump כדי לציין את רמת הדחיסה שבה רוצים להשתמש. הערכים הקבילים לאפשרות הזו הם 0 עד 9. ערך ברירת המחדל הוא דחיסה ברמה 6. ערכים גבוהים יותר מקטינים את הגודל של קובץ ה-dump, אבל יכולים לגרום לצריכת משאבים גבוהה במארח הלקוח. אם למארח של הלקוח יש מספיק משאבים, רמות דחיסה גבוהות יותר יכולות להקטין עוד יותר את גודל קובץ ה-dump.
  • כשיוצרים קובץ SQL dump, חשוב להשתמש בדגלים הנכונים.
  • מאמתים את מסד הנתונים המיובא. עוקבים אחרי הפלט של כלי השירות pg_restore כדי לראות אם מופיעות הודעות שגיאה במהלך תהליך השחזור. בודקים את היומנים של PostgreSQL כדי לראות אם מופיעות אזהרות או שגיאות במהלך תהליך השחזור. מריצים שאילתות בסיסיות וסופרים את הטבלאות כדי לוודא שמסד הנתונים תקין.

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

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

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

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

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

דרך נוספת לבצע העברה חד-פעמית של הנתונים היא לייצא את הטבלאות ממסד הנתונים של PostgreSQL שלכם לקובצי CSV או SQL. אחר כך תוכלו לייבא את קובץ ה-CSV או ה-SQL ל-Cloud SQL ל-PostgreSQL או ל-AlloyDB ל-PostgreSQL. כדי לייצא את התאריך של מופע המקור, אפשר להשתמש בתוסף aws_s3 ל-PostgreSQL. אפשר גם להשתמש ב-Amazon Database Migration Service ובקטגוריית S3 כיעד. מידע מפורט על הגישה הזו זמין במקורות המידע הבאים:

אפשר גם לייבא נתונים באופן ידני למכונת AlloyDB ל-PostgreSQL. הפורמטים הנתמכים הם:

  • ‫CSV: בפורמט הקובץ הזה, כל קובץ מכיל את התוכן של טבלה אחת במסד הנתונים. אפשר לטעון את הנתונים לקובץ ה-CSV באמצעות תוכנת שורת הפקודה psql. מידע נוסף זמין במאמר בנושא ייבוא קובץ CSV.
  • ‫DMP: פורמט הקובץ הזה מכיל את הארכיון של מסד נתונים שלם ב-PostgreSQL. כדי לייבא נתונים מהקובץ הזה, משתמשים בכלי pg_restore. מידע נוסף זמין במאמר בנושא ייבוא קובץ DMP.
  • ‫SQL: פורמט הקובץ הזה מכיל את השחזור הטקסטואלי של מסד נתונים של PostgreSQL. הנתונים בקובץ הזה מעובדים באמצעות שורת הפקודה psql. מידע נוסף זמין במאמר בנושא ייבוא קובץ SQL.

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

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

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

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

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

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

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

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

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

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

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

‫Database Migration Service מספק סוג העבודה ספציפי להעברות רציפות. משימות ההעברה הרציפה האלה תומכות בהעברות ברמת דיוק גבוהה אל Cloud SQL ל-PostgreSQL ואל AlloyDB ל-PostgreSQL.

כשמשתמשים ב-Database Migration Service כדי לבצע מיגרציה ל-Cloud SQL ל-PostgreSQL או ל-AlloyDB ל-PostgreSQL, יש דרישות מוקדמות ומגבלות שקשורות לכל מופע יעד:

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

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

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

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

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

אלה המגבלות והדרישות המוקדמות ל-Cloud SQL ל-PostgreSQL:

  • הגרסאות הבאות של Amazon נתמכות:

    • ‫Amazon RDS גרסה 9.6.10 ואילך, גרסה 10.5 ואילך, גרסה 11.1 ואילך, גרסה 12, גרסה 13, גרסה 14
    • ‫Amazon Aurora מגרסה 10.11 ואילך, מגרסה 11.6 ואילך, מגרסה 12.4 ואילך ומגרסה 13.3 ואילך

  • צריך להגדיר את חומת האש של השרת החיצוני כך שתאפשר את טווח כתובות ה-IP הפנימי שהוקצה לגישה לשירותים פרטיים של רשת ה-VPC. מסד הנתונים המשוכפל של Cloud SQL ל-PostgreSQL משתמש ברשת ה-VPC כרשת פרטית.

  • צריך להגדיר את חומת האש של מסד נתוני המקור כך שתאפשר את כל טווח כתובות ה-IP הפנימיות שהוקצה לחיבור הפרטי של השירות לרשת ה-VPC. מופע היעד של Cloud SQL ל-PostgreSQL משתמש ברשת ה-VPC הזו בשדה privateNetwork של ההגדרה IpConfiguration שלו.

  • כשמתקינים את התוסף pglogical במופע Cloud SQL ל-PostgreSQL, צריך לוודא שהגדרתם את האפשרות enable_pglogical ל-on (לדוגמה, cloudsql.enable_pglogical=on).

  • מוודאים שהפרמטר shared_preload_libraries כולל את התוסף pglogical במופע המקור (לדוגמה, shared_preload_libraries=pg_stat_statements,pglogical). מגדירים את הפרמטר rds.logical_replication לערך 1. ההגדרה הזו מפעילה יומני פעולות מקדימות ברמה הלוגית.

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

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

‫AlloyDB ל-PostgreSQL תומך בשכפול באמצעות התוסף pglogical. כדי להפעיל את התוסף pglogical לשכפול, אפשר להשתמש בפקודה CREATE EXTENSION. לפני שמשתמשים בפקודה הזו, צריך להגדיר את הדגלים של מסד הנתונים alloydb.enable_pglogical ו-alloydb.logical_decoding לערך on במופע AlloyDB ל-PostgreSQL שבו רוצים להשתמש בתוסף. כדי להגדיר את הדגלים האלה צריך להפעיל מחדש את המכונה.

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

אתם יכולים להשתמש ב-Datastream כדי לשכפל שינויים כמעט בזמן אמת במופע המקור של PostgreSQL. שירות Datastream משתמש בסימון נתונים שהשתנו (CDC) וברפליקציה כדי לשכפל ולסנכרן נתונים. אחרי מכן תוכלו להשתמש ב-Datastream לשכפול רציף מ-Amazon RDS ומ-Amazon Aurora. אתם משתמשים ב-Datastream כדי לשכפל שינויים ממופע PostgreSQL ל-BigQuery או ל-Cloud Storage. אחר כך אפשר להעביר את הנתונים המשוכפלים למופע של Cloud SQL ל-PostgreSQL ו-AlloyDB ל-PostgreSQL באמצעות Dataflow, על ידי שימוש בתבנית גמישה של Dataflow, או באמצעות Managed Service for Apache Spark.

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

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

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

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

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

  • יתרונות:

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

  • חסרונות:

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

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

  • יתרונות:

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

  • חסרונות:

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

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

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

  • יתרונות:

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

  • חסרונות:

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

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

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

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

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

  • מסמך עיצוב טכני (TDD)
  • מטריצת RACI
  • ציר זמן (למשל תוכנית עם ספירה לאחור)

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

TDD

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

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

מטריצת RACI

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

ציר הזמן

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

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

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

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

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

תאריך שלב קטגוריה Tasks תפקיד T-minus סטטוס
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 לא הופעל
22.11.2023 העברה ממשל חברה אימות ההעברה: אישור או דחייה צוות המיגרציה 1 לא הופעל
11/23/2023 אחרי ההעברה אימות המעקב הגדרת מעקב צוות התשתית 2 לא הופעל
25.11.2023 אחרי ההעברה אבטחה הסרה של חשבון משתמש ב-DMS צוות האבטחה 4 לא הופעל

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

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

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

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

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

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

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

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

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

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

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

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

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

  • יכול להיות שתצטרכו להגדיר קבוצת אבטחה חדשה כדי לאפשר חיבורים מרחוק ביציאות הנדרשות, ולהחיל את קבוצת האבטחה על מופע Amazon RDS או Amazon Aurora:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הגדרת מופע של Cloud SQL ל-PostgreSQL ו-AlloyDB ל-PostgreSQL

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

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

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

  • מעבר לגרסה ראשית תואמת ב-Cloud SQL ל-PostgreSQL וב-AlloyDB ל-PostgreSQL. לדוגמה, אם אתם משתמשים ב-PostgreSQL 14.x ב-Amazon RDS או ב-Amazon Aurora, כדאי לעבור ל-Cloud SQL או ל-AlloyDB ל-PostgreSQL לגרסה 14.x של PostgreSQL.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Database Migration Service משתמש בתוסף pglogical לשכפול ממקור הנתונים למופע של מסד הנתונים היעד. בתחילת המיגרציה, התוסף הזה מגדיר שכפול על ידי דרישת נעילות בלעדיות לטווח קצר בכל הטבלאות במופע המקור של אמזון RDS או אמזון Aurora. לכן, מומלץ להתחיל את המיגרציה כשהעומס על מסד הנתונים הוא הנמוך ביותר, ולהימנע מהצהרות במקור במהלך שלב ה-dump והשכפול, כי הצהרות DDL לא משוכפלות. אם אתם חייבים לבצע פעולות DDL, אתם יכולים להשתמש בפונקציות pglogical כדי להריץ הצהרות DDL במופע המקור, או להריץ ידנית את אותן הצהרות DDL במופע היעד של המיגרציה, אבל רק אחרי ששלב ה-dump הראשוני מסתיים.

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

תהליך ההגדרה המלא של העברת נתונים מפורט במדריכי ההתחלה המהירה של PostgreSQL ושל PostgreSQL אל AlloyDB ל-PostgreSQL.

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

‫Cloud SQL תומך בשני סוגים של שכפול לוגי: השכפול הלוגי המובנה של PostgreSQL והשכפול הלוגי באמצעות התוסף pglogical. ל-AlloyDB ל-PostgreSQL, מומלץ להשתמש בתוסף pglogical לשכפול. לכל סוג של שכפול לוגי יש תכונות ומגבלות משלו.

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

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

pglogical שכפול לוגי כולל את התכונות והמגבלות הבאות:

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

הוראות להגדרת שכפול לוגי מובנה של PostgreSQL משרת חיצוני כמו Amazon RDS או Amazon Aurora ל-PostgreSQL מפורטות במקורות המידע הבאים:

כלי צד שלישי

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

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

אתם משתמשים בזרימה אחת או יותר כדי לארגן את תהליכי המיגרציה האלה באפליקציות המותאמות אישית שלכם. כדי לקודד את האפליקציות המותאמות אישית, אפשר להשתמש בכלי תכנות גרפי או בשפת התכנות Tungsten Query Language‏ (TQL).

למידע נוסף על השימוש ב-Striim, אפשר לעיין במקורות המידע הבאים:

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

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

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

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

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

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

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

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

גיבוי פשוט

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

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

שכפול הפוך

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

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

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

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

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

כתיבות כפולות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Data Validation Tool

כדי לבצע אימות נתונים, מומלץ להשתמש בכלי לאימות נתונים (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 Tool של Google Cloud.

ביצוע ההעברה

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשמבצעים מיגרציה מ-Amazon RDS ומ-Aurora ל-PostgreSQL אל Cloud SQL ל-PostgreSQL, כדאי להביא בחשבון את ההנחיות הבאות:

  • כדאי להשתמש בשמירת נתונים במטמון כדי לשפר את ביצועי הקריאה. אפשר לבדוק את הנתונים הסטטיסטיים השונים בתצוגה pg_stat_database. לדוגמה, היחס blks_hit / (blks_hit + blks_read) צריך להיות גדול מ-99%. אם היחס הזה לא גבוה מ-99%, כדאי להגדיל את ה-RAM של המופע. מידע נוסף זמין במאמר בנושא איסוף נתונים סטטיסטיים ב-PostgreSQL.
  • כך תוכלו לפנות מקום ולמנוע ביצועים נמוכים של האינדקס. בהתאם לתדירות השינויים בנתונים, אפשר להגדיר לוח זמנים להפעלת הפקודה VACUUM ב-Cloud SQL ל-PostgreSQL.
  • מומלץ להשתמש במהדורת Cloud SQL Enterprise Plus כדי להגדיל את מגבלות ההגדרות של המכונה ואת מטמון הנתונים. מידע נוסף על Cloud SQL Enterprise Plus זמין במאמר מבוא למהדורות של Cloud SQL.
  • עוברים אל AlloyDB ל-PostgreSQL. אם תעברו ל-AlloyDB, תוכלו ליהנות מתאימות מלאה ל-PostgreSQL, מעיבוד טוב יותר של טרנזקציות ומעומסי עבודה מהירים של ניתוח נתונים טרנזקציוניים שנתמכים במסד הנתונים לעיבוד. בנוסף, תקבלו המלצה לגבי אינדקסים חדשים באמצעות התכונה 'יועץ האינדקסים'.

מידע נוסף על שיפור הביצועים של התשתית של מסד הנתונים Cloud SQL ל-PostgreSQL זמין במסמכי שיפור הביצועים של Cloud SQL ל-PostgreSQL.

כשמבצעים מיגרציה מ-Amazon RDS ומ-Aurora ל-PostgreSQL אל AlloyDB ל-PostgreSQL, כדאי לפעול לפי ההנחיות הבאות כדי לשפר את הביצועים של מכונת מסד הנתונים של AlloyDB ל-PostgreSQL:

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

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

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

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

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

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

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

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

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

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

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

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

ב-Cloud SQL ל-PostgreSQL וב-AlloyDB ל-PostgreSQL, כדאי לפעול לפי השיטות המומלצות הבאות:

  • כדי להפחית את העומס על המכונה הראשית, מוסיפים רפליקות לקריאה. אפשר גם להשתמש במאזן עומסים כמו HAProxy כדי לנהל את התעבורה אל העותקים. עם זאת, כדאי להימנע מיצירת יותר מדי עותקים כי זה יפריע לפעולה של VACUUM. מידע נוסף על השימוש ב-HAProxy זמין באתר הרשמי של HAProxy.
  • כדי לבצע אופטימיזציה של הפעולה VACUUM, צריך להגדיל את זיכרון המערכת ואת הפרמטר maintenance_work_mem. הגדלת זיכרון המערכת מאפשרת לאגד יותר טפלים בכל איטרציה.
  • מכיוון שסריקת אינדקסים גדולים אורכת זמן רב, צריך להגדיר את הפרמטר INDEX_CLEANUP לערך OFF כדי לנקות ולהקפיא את נתוני הטבלה במהירות.
  • כשמשתמשים ב-AlloyDB ל-PostgreSQL, כדאי להשתמש בלוח הבקרה ובקבצים של יומני הביקורת של AlloyDB ל-PostgreSQL System Insights. בלוח הבקרה System Insights for AlloyDB ל-PostgreSQL מוצגים מדדים של המשאבים שבהם אתם משתמשים, והוא מאפשר לכם לעקוב אחריהם. פרטים נוספים זמינים בנושא מעקב אחרי מופעים במאמרי העזרה בנושא AlloyDB ל-PostgreSQL.

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

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

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

מחברים:

תורם נוסף: Somdyuti Paul | מומחה לניהול נתונים