ביצוע שדרוג של גרסה משנית של מסד נתונים ב-AlloyDB Omni ב-Kubernetes

בוחרים גרסת תיעוד:

בדף הזה מוסבר איך לשדרג גרסה משנית של מסד נתונים ב-AlloyDB Omni ב-Kubernetes.

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

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

מגבלות

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

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

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

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

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

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

אם באשכול מסדי הנתונים יש רק גיבוי אחד, צריך להפעיל את LDTM באופן ידני על ידי הוספת ההערה dbcluster.dbadmin.goog/enableLDTM=true לאשכול מסדי הנתונים:

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

מחליפים את המשתנה הבא:

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסד הנתונים שסיפקתם כשיצרתם אותו. מידע נוסף זמין במאמר התקנת AlloyDB Omni ב-Kubernetes.

שדרוג גרסת AlloyDB Omni

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

הדוגמה הבאה היא החלק הראשון של קובץ מניפסט שמציין את גרסה 18.4.0 של databaseVersion ואת גרסה 1.9.0 של controlPlaneAgentsVersion:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "DB_VERSION"
    controlPlaneAgentsVersion: "CONTROL_PLANE_AGENTS_VERSION"
    # It is recommended to switch to UBI9 for improved security and
    # compatibility.
    # If you need to stick to Debian, set this field to "Debian".
    databaseImageOSType: "OS_TYPE"
...

מחליפים את המשתנה הבא:

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסדי הנתונים שסיפקתם כשנוצר. מידע נוסף זמין במאמר התקנת AlloyDB Omni ב-Kubernetes.
  • ‫DB_VERSION: גרסת מסד הנתונים שאליה משדרגים.
  • ‫CONTROL_PLANE_AGENTS_VERSION: הגרסה של סוכני מישור הבקרה.
  • ‫OS_TYPE: אופציונלי. מערכת ההפעלה הבסיסית של תמונת מסד הנתונים. הערכים התקינים הם Debian ו-UBI9. אם לא מציינים את זה, האופרטור מגדיר את זה אוטומטית ל-Debian אם databaseVersion קטן מ-16.9.0, ול-UBI9 אם databaseVersion גדול מ-16.9.0 או שווה לו.

מעקב אחרי תהליך השדרוג

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

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

מחליפים את המשתנה הבא:

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסדי הנתונים שסיפקתם כשנוצר. מידע נוסף זמין במאמר התקנת AlloyDB Omni ב-Kubernetes.

בזמן שהתהליך מתבצע, סטטוס התנאי הוא true. כשהתהליך מסתיים, הסטטוס של התנאי משתנה ל-false והסיבה מתעדכנת ל-UpgradeComplete או ל-UpgradeFailed.

פתרון בעיות

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

כשלים לפני השדרוג

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

אם רוצים לעקוף את הודעת השגיאה שלפני השדרוג, אפשר להפעיל את ההערה force-upgrade.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

מחליפים את המשתנה הבא:

  • ‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסד הנתונים שסיפקתם כשיצרתם אותו. למידע נוסף, אפשר לעיין במאמר בנושא התקנת AlloyDB Omni ב-Kubernetes.

אחרי שתהליך השדרוג מסתיים, מגדירים את ההערה force-upgrade לערך false.

שדרוגים שנכשלו

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

הודעה על כשל תיאור פעולות נדרשות של משתמשים
Standby instance upgrade succeeded but its replication lag is too high to be promoted to a synchronous standby. Please monitor replication status. המכונה במצב המתנה שודרגה בהצלחה, אבל לא הצליחה להדביק את הפער מול המכונה הראשית מספיק מהר כדי לעמוד בסף הרפליקציה הסינכרונית לפני חלון הזמן הקצוב לתפוגה. בדרך כלל זה קורה בגלל תנועת כתיבה כבדה במכונה הראשית.

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

  1. מחכים שהתנועה של פעולות הכתיבה תפחת כדי שמכונה במצב המתנה תתעדכן בהדרגה. אופרטור AlloyDB Omni מקדם אותו באופן אוטומטי אחרי שהוא מסונכרן.
  2. (אופציונלי) אפשר להגדיר את ההערה upgrade.alloydbomni.dbadmin.google/standby-catch-up-timeout-in-minutes ב-DBCluster כדי להגדיל את הזמן הקצוב לתפוס את הפער.
All standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby. המכונות במצב המתנה שודרגו, אבל תהליך המעבר האוטומטי שנועד לקדם מכונה משודרגת במצב המתנה למכונה ראשית נכשל.

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

  1. בודקים את הסטטוס של המשאב המותאם אישית של המעבר כדי לזהות את שורש הבעיה:
    kubectl get switchovers.alloydbomni.dbadmin.goog -n NAMESPACE
  2. בודקים את היומנים והאירועים של בקר המעבר כדי לזהות בעיות כמו חלוקת הרשת או זמן האחזור של ה-API.
  3. בוחרים אפשרות בקטע תיקון מכונות ראשיות ומכונות במצב המתנה עם גרסאות משניות שונות.
Standby instance upgrade failed but rollback to the previous versions succeeded השדרוג של המכונה במצב המתנה נכשל, אבל אופרטור AlloyDB Omni החזיר את המכונה לגרסה הקודמת שפעלה. מכיוון שלא בוצעו שינויים במופע הראשי, מסד הנתונים שלכם נשאר תקין בגרסה הקודמת.

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

  1. כדי לאבחן את כשל השדרוג, בודקים את היומנים והאירועים של ה-pod במצב המתנה:
    kubectl describe pod -l alloydbomni.dbadmin.goog/instance=[standby-name] -n NAMESPACE
  2. אחרי שפותרים את הבעיה שמונעת את השדרוג, למשל ניצול יתר של משאבי הצומת או taints, בוחרים אפשרות בקטע תיקון מכונות ראשיות ומכונות במצב המתנה עם גרסאות משניות שונות.
Standby instance upgrade failed and rollback to the previous versions failed השדרוג של המכונה במצב המתנה נכשל, וגם הניסיון האוטומטי של אופרטור AlloyDB Omni להחזיר אותה לגרסה הקודמת נכשל. המכונה במצב המתנה נשארת במצב לא תקין או לא שמיש (מה שמפחית את היתירות של הזמינות הגבוהה), והמכונה הראשית ממשיכה לטפל בתנועת הקריאה/כתיבה בגרסה הקודמת.

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

  1. מוחקים את המכונה הלא תקינה במצב המתנה על ידי הגדרת מספר המכונות במצב המתנה ל-0 במפרט של DBCluster:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 0}}}'
  2. מחכים עד שהמופע הפגום במצב המתנה וה-pod שלו יימחקו לגמרי.
  3. מגדילים את מספר המכונות במצב המתנה כדי להקצות מכונה נקייה במצב המתנה שתסתנכרן אוטומטית עם המכונה הראשית הפעילה:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 1}}}'

פתרון בעיות במכונות ראשיות ובמכונות במצב המתנה עם גרסאות משניות שונות

כדי לפתור את הבעיה, אפשר לבחור באחת מהאפשרויות הבאות:

  • אם הבעיה שגרמה לשדרוג להיכשל נפתרה, אתם יכולים להתחיל את השדרוג מחדש. כדי שהאופרטור של AlloyDB Omni ייצור זמן התחלה חדש וינסה שוב, צריך להסיר את ההערה start-time של השדרוג מ-DBCluster:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-

    מחליפים את DB_CLUSTER_NAME בשם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסדי הנתונים שסיפקתם כשנוצר. מידע נוסף זמין במאמר התקנת AlloyDB Omni ב-Kubernetes.

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

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