‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

שדרוג פריסה של Spanner Omni

במאמר הזה מוסבר איך לשדרג פריסה של Spanner Omni מגרסה קודמת לגרסה חדשה יותר.

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

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

נתיבי שדרוג נתמכים

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

למידע נוסף, קראו את מדיניות התמיכה בגרסאות.

תהליך השדרוג

תהליך השדרוג של Spanner Omni מורכב מכמה שלבים עוקבים:

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

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

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

יש לכם פריסה פעילה של Spanner Omni. מידע נוסף זמין במאמרים יצירת פריסה ב-Kubernetes ויצירת פריסה במכונות וירטואליות.
הורדתם והתקנתם את Spanner Omni CLI.
יש לכם גישה ברשת לכל היציאות הפנימיות של Spanner Omni (מ-TCP 15000 עד 15027) מהמכונה שבה אתם מריצים את פקודות ה-CLI, או גישה ברשת לנקודת הקצה של הפריסה.
אם אתם משתמשים בהצפנה מסוג Transport Layer Security ‏ (TLS) או Mutual TLS ‏ (mTLS), ודאו שאישורים תקפים זמינים בספריית הבסיס בנתיב BASE_DIR/tls או שהם מותקנים באשכול.
זיהיתם את הגרסה הרצויה:
- בפריסות של מכונות וירטואליות: מורידים את חבילת הגרסה הרצויה spanner-omni-server-TARGET_VERSION.tar.gz.
- בפריסות של Helm ו-Kubernetes: מזהים את קובץ האימג' של קונטיינר היעד ב-Artifact Registry, למשל us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION.
אדמינים של פריסות Spanner Omni צריכים לתזמן חלונות זמן לתחזוקה לצורך שדרוגים. מומלץ לא לבצע פריסות בארגון במהלך חלונות הזמן לתחזוקה של השדרוג.

שלב 1: הכנה לשדרוג הסכימה

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

בוחרים את הכרטיסייה של סביבת הפריסה:

VM

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

נכנסים לשרת בפריסה שיש לו גישה ברשת לכל היציאות הפנימיות של Spanner Omni (‏TCP 15000 עד 15027).
מורידים ומחלצים את חבילת הגרסה הרצויה:
```
tar -xzf spanner-omni-server-TARGET_VERSION.tar.gz -C EXTRACT_DIR
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה 2026.r5.
- ‫EXTRACT_DIR: הספרייה שבה חילצתם את חבילת הגרסה, לדוגמה /tmp/target_spanner/.
מפעילים את ההכנה להשקה על ידי הרצת הפקודה rollouts prepare מה-CLI שחולץ:
```
EXTRACT_DIR/bin/spanner deployment rollouts prepare \
  --target-server-binary=EXTRACT_DIR/bin/spanner_server \
  --root-server=ROOT_SERVERS \
  --base-dir=BASE_DIR
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫EXTRACT_DIR: ספריית החילוץ שמכילה את ה-CLI של bin/spanner ואת הקובץ הבינארי של bin/spanner_server.
- ‫ROOT_SERVERS: נקודת קצה אחת של שרת בסיס או רשימה מופרדת בפסיקים של כמה שרתי בסיס, לדוגמה localhost:15000 או server1:15000,server2:15000,server3:15000.
- ‫BASE_DIR: ספריית הבסיס של Spanner Omni, לדוגמה /spanner.
- אם הפריסה משתמשת בהצפנת TLS או mTLS, מוסיפים את --ca-certificate-file=CA_CERT_FILE ו---client-certificate-directory=CERT_DIR שמפנים לאישורים תקינים.

הגה

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

פריסות בכמה שרתים (זמינות גבוהה / סביבת ייצור): Helm מטפל בהכנת הסכימה באופן אוטומטי. כשמריצים את helm upgrade בשלב 3: עדכון הקובץ הבינארי או קובץ האימג' של הקונטיינר, תרשים ה-Helm מפעיל את משימת ה-hook של spanner-prepare-for-upgrade לפני השדרוג כדי להריץ את העברות הסכימה לפני עדכון של StatefulSets. עוברים ישירות אל שלב 2: אימות מצב ההשקה הפעיל.
פריסות של שרת יחיד (deployment.singleServer=true): מכיוון שמצב שרת יחיד מחייב שירותים פנימיים לממשק הלולאה החוזרת (127.0.0.1), משימות רשת לא יכולות להגיע אליהם. מריצים את העברת הסכימה באופן מקומי בתוך ה-pod שפועל, באמצעות קונטיינר זמני לניפוי באגים עם קובץ האימג' של קונטיינר היעד:
```
kubectl debug pod/POD_NAME -n NAMESPACE \
  --image=us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION \
  --container=upgrade-prepare -i \
  -- /google/spanner/bin/spanner_server prepare_for_upgrade --root_server=127.0.0.1
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫POD_NAME: השם של ה-pod של השרת, לדוגמה spanner-a-0.
- ‫NAMESPACE: מרחב השמות של הפריסה ב-Kubernetes, לדוגמה spanner-ns.
- ‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה 2026.r5.

‫Kubernetes עצמאי

אם אתם פורסים את Spanner Omni ב-Kubernetes בלי Helm, הריצו משימת אצווה עצמאית ב-Kubernetes כדי להעביר את הסכימה לשרת הבסיס הפעיל באמצעות קובץ האימג' של היעד.

יוצרים קובץ בשם spanner-prepare-upgrade.yaml עם המניפסט הבא של המשימה:

apiVersion: batch/v1
kind: Job
metadata:
  namespace: NAMESPACE
  name: spanner-prepare-for-upgrade
spec:
  # Fail fast on the first error to stop the rollout immediately.
  backoffLimit: 0
  template:
    metadata:
      namespace: NAMESPACE
    spec:
      restartPolicy: Never
      containers:
        - name: spanner-upgrade
          image: us-docker.pkg.dev/spanner-omni/images/spanner-omni:TARGET_VERSION
          command: ["/google/spanner/bin/spanner_server"]
          args:
            - "prepare_for_upgrade"
            - "--root_server=ROOT_SERVER_ENDPOINT"
          volumeMounts:
            - name: tls-certs
              mountPath: "/spanner/tls"
              readOnly: true
            - name: spanner-data
              mountPath: /spanner
      volumes:
        - name: tls-certs
          secret:
            secretName: tls-certs
            optional: true
            defaultMode: 256
        - name: spanner-data
          emptyDir: {}

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

‫NAMESPACE: מרחב השמות של הפריסה ב-Kubernetes, לדוגמה spanner-ns.
‫TARGET_VERSION: גרסת היעד לשדרוג, לדוגמה 2026.r5.
‫ROOT_SERVER_ENDPOINT: נקודת הקצה של pod פעיל בשרת הבסיס, לדוגמה spanner-a-0.pod.spanner-ns.

מחילים את המניפסט כדי להריץ את משימת ההכנה:
```
kubectl apply -f spanner-prepare-upgrade.yaml
```

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

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

מציגים את רשימת ההשקות הפעילות כדי לאחזר את מזהה ההשקה:
```
spanner deployment rollouts list \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT
```
מחליפים את DEPLOYMENT_ENDPOINT בנקודת הקצה של שרת בפריסה, לדוגמה localhost:15000 או spanner-a-0.pod.spanner-ns:15000.

הפלט אמור להיראות כך:
```
NAME                         STATE          TARGET_VERSION    START_TIME                     END_TIME
rollouts/1788942172101727    IN_PROGRESS    2026.r3-beta      2026-09-09T08:22:52.101727Z    -
```
בודקים את הסטטוס המפורט של שלב ההשקה:
```
spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫ROLLOUT_ID: המזהה המספרי של ההשקה, לדוגמה 1788942172101727.
- ‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.
הפלט אמור להיראות כך:
```
name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: IN_PROGRESS
    - name: rollouts/1788942172101727/phases/finalize
      state: PENDING
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: IN_PROGRESS
targetVersion: 2026.r3-beta
```
לפני שממשיכים, צריך לוודא את הסטטוסים הבאים של השלבים:
- ‫schema: מוצג הערך SUCCEEDED, שמציין שההעברות הפנימיות של סכימת מסד הנתונים הושלמו.
- ‫binary: מוצג הערך IN_PROGRESS, שמציין שמנוע ההשקה מוכן לעדכונים בינאריים.
- ‫finalize: מוצג הערך PENDING, עד להשלמת השלב הבינארי.

שלב 3: מעדכנים את הקובץ הבינארי או את קובץ האימג' של הקונטיינר

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

בוחרים את הכרטיסייה של סביבת הפריסה:

VM

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

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

הגה

בפריסות של Helm, מריצים את helm upgrade תוך שמירה על ערכי התצורה הקיימים על ידי העברת --reuse-values או מתן קובץ ערכים:

פריסות בכמה שרתים (ייצור / זמינות גבוהה):
```
helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
  --version CHART_VERSION \
  -n NAMESPACE \
  --reuse-values \
  --set image.tag=TARGET_VERSION \
  --timeout 30m
```
‫Helm מפעיל באופן אוטומטי את שלב 1 באמצעות ה-hook שלפני השדרוג, ואז מתחיל עדכון הדרגתי (rolling) של ה-StatefulSets (rollout.staggered: true) לפי אזורים.
פריסות בשרת יחיד (deployment.singleServer=true):

מעבירים באופן מפורש את --set skipPrepareUpgrade=true כדי ש-Helm ידלג על המשימה של ה-hook לפני השדרוג, כי כבר השלמתם את שלב 1 באופן מקומי:
```
helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
  --version CHART_VERSION \
  -n NAMESPACE \
  --reuse-values \
  --set skipPrepareUpgrade=true \
  --set image.tag=TARGET_VERSION \
  --timeout 30m
```

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

‫CHART_VERSION: הגרסה של תרשים Helm, לדוגמה 1.1.0.
‫NAMESPACE: מרחב השמות של הפריסה ב-Kubernetes, לדוגמה spanner-ns.
‫TARGET_VERSION: תג קובץ האימג' של קונטיינר היעד, לדוגמה 2026.r5.

‫Kubernetes עצמאי

בפריסות מותאמות אישית של Kubernetes בלי Helm, מעדכנים את קובץ האימג' של הקונטיינר במפרטי פריסה של StatefulSet או Deployment ל-TARGET_VERSION.

מבצעים עדכון בהדרגה (rolling) בדומיינים של כשל, מעדכנים אזור אחד בכל פעם ומפעילים מחדש לא יותר מ-5% מה-pods בו-זמנית כדי לשמור על הקוורום.

שלב 4: מוודאים שההתקדמות בשלבים הבינאריים תקינה

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

בודקים את הסטטוס של שלב ההשקה:

spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

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

‫ROLLOUT_ID: המזהה המספרי של ההשקה, לדוגמה 1788942172101727.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

הפלט אמור להיראות כך:

name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/finalize
      state: PENDING
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: IN_PROGRESS
targetVersion: 2026.r3-beta

מוודאים שהסטטוס של השלב binary משתנה ל-SUCCEEDED. סטטוס ההשקה הכולל נשאר IN_PROGRESS עד שכל השלבים הנותרים מסתיימים. אחרי שהמצב של phases/binary משתנה ל-SUCCEEDED, אפשר להמשיך לשלבים הבאים של הפריסה.

שלב 5: מתזמנים ומבצעים את השלבים הנותרים

אחרי שהשלב הבינארי מסתיים בהצלחה ואתם מוודאים שהפריסה יציבה, אתם יכולים לתזמן את השלבים הנותרים להשקה עד לשלב finalize. השלב finalize (השלב האחרון בהשקה) חותם את הגרסה החדשה בכל הפריסה. אפשר להריץ את הפקודה הזו מכל מכונה שיש לה גישה לרשת של שירות Spanner Omni, על ידי ציון --deployment-endpoint.

בכל שלב שנותר במצב PENDING (למשל enable_features אם הוא קיים, ואחריו finalize), מבצעים את הפעולות הבאות:

תזמון השלב:

spanner deployment rollouts phases schedule PHASE_NAME \
  --rollout=ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

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

‫PHASE_NAME: שם השלב שרוצים לתזמן, לדוגמה finalize או enable_features.
‫ROLLOUT_ID: המזהה המספרי של ההשקה, לדוגמה 1788942172101727.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

הפלט מציין שהשלב המתוזמן הוא IN_PROGRESS:

name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/finalize
      state: IN_PROGRESS
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: IN_PROGRESS
targetVersion: 2026.r3-beta

מחכים שהשלב יסתיים בהצלחה ומאמתים את הסטטוס שלו:

spanner deployment rollouts describe ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

חוזרים על השלבים האלה בכל אחד מהשלבים שנותרו, עד שכל השלבים עד finalize (כולל) הושלמו.

אחרי שהשלב האחרון (finalize) מסתיים, כל השלבים והמצב הכולל של ההשקה עוברים ל-SUCCEEDED:

endTime: "2026-09-09T08:45:43.949702Z"
name: rollouts/1788942172101727
phases:
    - name: rollouts/1788942172101727/phases/schema
      startTime: "2026-09-09T08:22:52.101727Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/binary
      startTime: "2026-09-09T08:23:29.585375Z"
      state: SUCCEEDED
    - name: rollouts/1788942172101727/phases/finalize
      startTime: "2026-09-09T08:45:43.898111Z"
      state: SUCCEEDED
sourceVersion: 2026.r2-beta.3
startTime: "2026-09-09T08:22:52.101727Z"
state: SUCCEEDED
targetVersion: 2026.r3-beta

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

spanner deployment rollouts list \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

הפלט מאשר שההשקה הושלמה:

NAME                         STATE        TARGET_VERSION    START_TIME                     END_TIME
rollouts/1788942172101727    SUCCEEDED    2026.r3-beta      2026-09-09T08:22:52.101727Z    2026-09-09T08:45:43.949702Z

חזרה לגרסה קודמת של שדרוג

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

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

חזרה לגרסה קודמת של הקובץ הבינארי או של קובץ האימג' של הקונטיינר

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

VM

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

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

הגה

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

helm upgrade spanner-omni oci://us-docker.pkg.dev/spanner-omni/charts/spanner-omni \
  --version CHART_VERSION \
  -n NAMESPACE \
  --reuse-values \
  --set image.tag=SOURCE_VERSION \
  --timeout 30m

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

‫CHART_VERSION: הגרסה של תרשים Helm, לדוגמה 1.1.0.
‫NAMESPACE: מרחב השמות של הפריסה ב-Kubernetes, לדוגמה spanner-ns.
‫SOURCE_VERSION: התג הקודם של קובץ האימג' של הקונטיינר שרוצים לחזור אליו, לדוגמה 2026.r2-beta.3.

‫Kubernetes עצמאי

בפריסות Kubernetes בהתאמה אישית בלי Helm, מעדכנים את קובץ האימג' של הקונטיינר במפרטים של StatefulSet או Deployment בחזרה ל-SOURCE_VERSION.

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

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

spanner deployment rollouts rollback ROLLOUT_ID \
  --deployment-endpoint=DEPLOYMENT_ENDPOINT

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

‫ROLLOUT_ID: המזהה המספרי של ההשקה.
‫DEPLOYMENT_ENDPOINT: נקודת הקצה של שרת בפריסה.

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

איך מתחזקים פריסה
איך משנים את קנה המידה של פריסת Kubernetes או איך משנים את קנה המידה של פריסת VM.
מידע ולמידה על סקירה כללית על Monitoring

שדרוג פריסה של Spanner Omni קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

נתיבי שדרוג נתמכים

תהליך השדרוג

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

שלב 1: הכנה לשדרוג הסכימה

VM

הגה

‫Kubernetes עצמאי

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

שלב 3: מעדכנים את הקובץ הבינארי או את קובץ האימג' של הקונטיינר

VM

הגה

‫Kubernetes עצמאי

שלב 4: מוודאים שההתקדמות בשלבים הבינאריים תקינה

שלב 5: מתזמנים ומבצעים את השלבים הנותרים

חזרה לגרסה קודמת של שדרוג

חזרה לגרסה קודמת של הקובץ הבינארי או של קובץ האימג' של הקונטיינר

VM

הגה

‫Kubernetes עצמאי

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

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

שדרוג פריסה של Spanner Omni