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

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

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

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

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

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

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

  1. מפעילים את Database Migration Service API.

    תפקידים שנדרשים להפעלת ממשקי API

    כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

    להפעלת ה-API

  2. צריך לוודא שיש לכם בפרויקט את התפקיד או התפקידים הבאים:

    • אחת מהאפשרויות הבאות:
      • ‫Cloud AlloyDB > אדמין של Cloud AlloyDB
      • בסיסי > בעלים
      • בסיסי > עורך
    • צריכה להיות לכם גם ההרשאה compute.networks.list בפרויקט Google Cloud שבו אתם משתמשים. כדי לקבל את ההרשאה הזו תוך הקפדה על העיקרון של הרשאות מינימליות, צריך לבקש מהאדמין להקצות לכם את התפקיד Compute Engine > Compute Network User (roles/compute.networkUser).
    • אדמין של העברת מסדי נתונים

    בדיקת התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

      כניסה לדף IAM
    2. בוחרים את הפרויקט.

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

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

    מתן התפקידים

    1. נכנסים לדף IAM במסוף Google Cloud .

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

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

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

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

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 החדשות שלהם.