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

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

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

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

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

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

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

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

  1. מפעילים את Database Migration Service API, אם הוא עדיין לא מופעל.

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

    כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד "בעלים" (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד "אדמין בממשק 'שימוש בשירות'" (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

    להפעלת ה-API

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

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

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

    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 that you 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 לערך 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.

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

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

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

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

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

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