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

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

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

תאימות של אשכולות וגרסאות PostgreSQL

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

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

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

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

  1. שדרוג הגרסה הראשית במקום, שמומלץ להשתמש בו.
  2. העברת הנתונים באמצעות ייצוא נתונים מבוסס-קבצים.
  3. שימוש ב-Database Migration Service.

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

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


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

שדרוג הגרסה הראשית במקום

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

העברה באמצעות ייצוא נתונים מבוסס-קובץ

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

איך לעשות את זה?

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

  2. מגדירים את האשכול החדש עם הגרסה הראשית החדשה כך שתתאים להגדרות של האשכול הנוכחי:

    1. יוצרים מופעים נוספים של מאגר קריאה לפי הצורך.

    2. יוצרים אשכולות משניים לפי הצורך.

      כשיוצרים אשכולות משניים, לא צריך לציין מספר גרסה ראשי של PostgreSQL. ‫AlloyDB מחיל את גרסת PostgreSQL של האשכול הראשי על כל האשכולות המשניים שלו.

    3. מעדכנים את הדגלים של מסד הנתונים של האשכול החדש כך שיתאימו להגדרות הדגלים של האשכול הנוכחי.

    4. מפעילים את כל התוספים שהאפליקציות צריכות.

  3. מייצאים את הנתונים מהאשכול הישן לקבצים באמצעות psql או pg_dump.

  4. מייבאים את הנתונים מהקבצים אל האשכול החדש.

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

העברה באמצעות Database Migration Service

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

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

שיקולים חשובים

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

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

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

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

מגבלות על שכפול

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

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

לפני שמתחילים

  1. Enable the Database Migration Service API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  2. Make sure that you have the following role or roles on the project:

    • One of the following:
      • Cloud AlloyDB > Cloud AlloyDB admin
      • Basic > Owner
      • Basic > Editor
    • You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
    • Database Migration admin

    Check for the roles

    1. In the Google Cloud console, go to the IAM page.

      Go to IAM
    2. Select the project.

    3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.

    4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.

    Grant the roles

    1. In the Google Cloud console, go to the IAM page.

      כניסה לדף IAM
    2. בוחרים את הפרויקט.
    3. לוחצים על ‎ Grant access.

    4. בשדה New principals, מזינים את מזהה המשתמש. ‫ בדרך כלל מזהה המשתמש הוא כתובת האימייל של חשבון Google.

      ‫
    5. לוחצים על בחירת תפקיד ומחפשים את התפקיד.
    6. כדי לתת עוד תפקידים, לוחצים על Add another role ומוסיפים את כולם.
    7. לוחצים על Save.
  3. מוודאים שרשת ה-VPC ב Google Cloud הפרויקט שבו אתם משתמשים מוגדרת לגישה לשירותים פרטיים ל-AlloyDB.
  4. מחליטים באיזה אזור רוצים ליצור את אשכול היעד. כל הישויות של Database Migration Service (פרופילים של חיבורים, משימות העברה) צריכות להיווצר באותו אזור שבו נמצא אשכול היעד.
  5. מכינים משתמש במסד הנתונים שרוצים להתחבר אליו באשכול ומריצים הצהרות העברה במסדי הנתונים של המקור. משתמש מסד הנתונים הזה דורש קבוצה ספציפית של הרשאות ותפקידים. מומלץ ליצור משתמש חדש במסד הנתונים ולהקצות אותו במיוחד למטרה של ביצוע ההעברה.

    6. הגדרת מופעי המקור

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

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

    1. מגדירים את הדגלים של מסד הנתונים בכל מופע באשכול המקור. משתמשים בערכים הבאים:
      סימון ערך
      alloydb.logical_decoding ההגדרה היא on.
      alloydb.enable_pglogical ההגדרה היא on.
      max_replication_slots הדגל הזה מגדיר את המספר המקסימלי של משבצות שכפול שמופע המקור יכול לתמוך בהן. הערך המינימלי של הדגל הזה הוא 50.

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

      (the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)

      נניח שהתנאים הבאים מתקיימים:

      • אין לך רפליקות לקריאה במקור.
      • יש לכם 30 מסדי נתונים במופע של המקור הראשי.
      • אתם רוצים ליצור 2 משימות העברה לאשכול המקור.
      • רוצים להשתמש ב-10 משבצות לשכפול טבלאות.
      במקרה כזה, מספר max_replication_slots חייב להיות לפחות 70, שמחושב לפי 30 * 2 + 10 + 0.
      max_wal_senders צריך להגדיר את הדגל הזה לערך שהוא לפחות 10 יותר מהערך של max_replication_slots בתוספת מספר השולחים שכבר נמצאים בשימוש במופע שלכם.

      לדוגמה, אם הגדרתם את max_replication_slots flag לערך 70 ואתם כבר משתמשים ב-2 שולחים, אז הערך של max_wal_senders צריך להיות לפחות 82 (מחושב כ-70 + 10 + 2 = 82).

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

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

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

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

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

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

    2. מריצים את הפקודה הבאה כדי להתקין את התוסף pglogical:

      CREATE EXTENSION IF NOT EXISTS pglogical;

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

      GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫SCHEMA_NAME: השם של סכימה שקיימת במסד הנתונים
      • ‫USER_NAME: השם של משתמש מסד הנתונים שהכנתם בקטע לפני שמתחילים

      חוזרים על השלב הזה לכל סכימה במסד הנתונים חוץ מ הסכימה information וסכימות שהשמות שלהן מתחילים בקידומת pg_. אפשר להציג את כל סכימות מסד הנתונים באמצעות המטא-פקודה ‎\dn.

    4. נותנים את שאר ההרשאות הנדרשות. מריצים את ההצהרות הבאות:

      GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;

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

    5. מתחברים לכל מסד נתונים אחר במופע וחוזרים על שלבים 2, 3 ו-4.

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

      • אפשר לעבור למסד נתונים אחר בלי לאפס את החיבור של הלקוח psql באמצעות הפקודה \connect {database_name_here}.

    6. חוזרים על התהליך הזה לכל מופע באשכול AlloyDB של המקור.

    הפעלת ההעברה ב-Database Migration Service

    איך לעשות את זה?

    1. יוצרים פרופיל של חיבור למקור עבור אשכול AlloyDB. משתמשים בערכים הבאים:

      • המנוע של מסד הנתונים: בוחרים באפשרות PostgreSQL.
      • שם מארח/כתובת IP: משתמשים בכתובת ה-IP של המופע הראשי באשכול.
      • שם משתמש/סיסמה: מזינים את פרטי הכניסה של משתמש מסד הנתונים שהכנתם בקטע לפני שמתחילים.
      • יציאה: מזינים 5432.
      • אזור: בוחרים את האזור שבו נמצא אשכול היעד.
      • סוג הצפנה: בוחרים באפשרות ללא.

    2. יוצרים ומריצים את עבודת ההעברה.

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

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

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

    3. כשהסטטוס של משימת ההעברה משתנה ל-CDC, מקדמים את משימת ההעברה. אפשר לבדוק את הסטטוס של משימת ההעברה בדף הסקירה הכללית של ההעברה. אפשר לעיין במאמר בנושא בדיקת משימת העברה בתיעוד של Database Migration Service.

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

    4. (אופציונלי) בודקים אם יש הצהרות חסרות בטבלאות שאין להן מפתחות ראשיים.

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

    5. מעבירים את האפליקציה לאשכול החדש. האפליקציות שלכם יכולות עכשיו להתחבר למופעים של האשכול החדש בכתובות ה-IP החדשות שלהם.