במאמר הזה מתועדת גרסה 15.5.2 של AlloyDB Omni באמצעות אפשרות הפריסה containers. בוחרים אפשרות פריסה אחרת.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

ניהול ומעקב אחרי AlloyDB Omni

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

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

ניהול תפקידי משתמשים

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

ל-AlloyDB Omni אין תפקיד alloydbiamuser.
‫AlloyDB Omni כולל תפקיד סופר-משתמש בשם alloydbadmin.

בדומה ל-AlloyDB, מומלץ לפעול לפי השלבים הבאים כשמגדירים מסד נתונים:

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

אתם יכולים ליצור ולהגדיר כמה תפקידי משתמשים חדשים שאתם צריכים. אל תשנו או תמחקו אף אחד מתפקידי המשתמשים שמגיעים עם AlloyDB Omni.

מידע נוסף זמין במאמר בנושא ניהול תפקידי משתמש ב-AlloyDB.

מעקב אחרי AlloyDB Omni

כדי לעקוב אחרי ההתקנה של AlloyDB Omni, צריך לקרוא ולנתח את קובצי היומן שלה.

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

שרת יחיד

הפעילות ב-AlloyDB Omni נרשמת ביומן בשני מקומות:

יומני הפעילות של מסד הנתונים ב-AlloyDB Omni נמצאים בנתיב data/log/postgres, ביחס לתיקייה שהגדרתם בקובץ התצורה dataplane.conf.

אפשר להתאים אישית את השם והפורמט של קובץ היומן הזה באמצעות ההנחיות השונות log_* שמוגדרות ב-/var/alloydb/config/postgresql.conf. מידע נוסף מופיע במאמר בנושא Error Reporting ורישום ביומן.
‫AlloyDB Omni מתעד את ההתקנה, ההפעלה והכיבוי שלו ב-/var/alloydb/logs/alloydb.log.

כדי לבדוק את סטטוס ההפעלה המיידי של השרת, אפשר לעיין במאמר בדיקת הסטטוס של AlloyDB Omni.

‏Kubernetes

איתור קובצי היומן של אשכול מסד הנתונים

אפשר למצוא קבצים מסוג postgresql.audit ו-postgresql.log במערכת הקבצים של ה-pod של מסד הנתונים. כדי לגשת לקבצים האלה:

מגדירים משתנה סביבה שמכיל את השם של פוד מסד הנתונים.
```
export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`
```
מחליפים את DB_CLUSTER_NAME בשם של אשכול מסדי הנתונים. זהו אותו שם של אשכול מסדי הנתונים שהצהרתם עליו כשיצרתם אותו.
מריצים מעטפת (shell) בתא (pod) של מסד הנתונים כמשתמש root.
```
kubectl exec ${DB_POD} -it -- /bin/bash
```
מוצאים את קובצי היומן בספרייה /obs/diagnostic/:
- /obs/diagnostic/postgresql.audit
- /obs/diagnostic/postgresql.log

הצגת רשימה של שירותי ניטור

v1.0

כשיוצרים אשכול מסדי נתונים, AlloyDB Omni יוצר את שירות המעקב הבא לכל CR של מכונה באשכול מסד הנתונים באותו מרחב שמות:

al-INSTANCE_NAME-monitoring-system

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

kubectl get svc -n NAMESPACE | grep monitoring

מחליפים את NAMESPACE במרחב שמות שהאשכול שייך אליו.

בדוגמה הבאה של תגובה מוצגים השירותים al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system ו-al-4bc0-dbc-monitoring-system. כל שירות תואם למופע אחד.

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

גרסה < 1.0

כשיוצרים אשכול מסדי נתונים, AlloyDB Omni יוצר את שירותי המעקב הבאים באותו מרחב שמות כמו אשכול מסדי הנתונים:

DB_CLUSTER-monitoring-db
DB_CLUSTER-monitoring-system

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

kubectl get svc -n NAMESPACE | grep monitoring

מחליפים את NAMESPACE במרחב שמות שהאשכול שייך אליו.

בדוגמה הבאה של תגובה מוצגים השירות al-2953-dbcluster-foo7-monitoring-system והשירות al-2953-dbcluster-foo7-monitoring-db.

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

הצגת מדדי Prometheus משורת הפקודה

היציאה 9187 נקראת metricsalloydbomni בכל שירותי המעקב.

מגדירים העברת ליציאה אחרת מהסביבה המקומית לשירות המעקב.
```
kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫MONITORING_SERVICE: השם של שירות המעקב שרוצים להעביר, לדוגמה al-1060-dbc-monitoring-system.
- ‫NAMESPACE: מרחב השמות שאליו שייך האשכול.
- ‫MONITORING_METRICS_PORT: יציאת TCP מקומית זמינה.
התשובה הבאה מראה שהשירותים מועברים.
```
Forwarding from 127.0.0.1:9187 -> 9187
Forwarding from [::1]:9187 -> 9187
```
בזמן שהפקודה הקודמת פועלת, אפשר לגשת למדדי המעקב באמצעות HTTP ביציאה שציינתם. לדוגמה, אפשר להשתמש ב-curl כדי לראות את כל המדדים כטקסט פשוט:
```
curl http://localhost:MONITORING_METRICS_PORT/metrics
```

הצגת מדדים באמצעות Prometheus API

מפתח התווית alloydbomni.internal.dbadmin.goog/task-type והיציאה metricsalloydbomni זמינים כברירת מחדל לכל שירותי המעקב ב-AlloyDB Omni. אפשר להשתמש בהם יחד עם משאב מותאם אישית יחיד מסוג ServiceMonitor כדי לבחור את כל השירותים לכל מרחבי השמות באשכול מסד הנתונים.

מידע נוסף על השימוש ב-Prometheus API זמין במאמרי העזרה של Prometheus Operator.

הדוגמה הבאה מציגה את השדה spec של המשאב המותאם אישית ServiceMonitor, שכולל את מפתח התווית alloydbomni.internal.dbadmin.gdc.goog/task-type ואת היציאה metricsalloydbomni. המשאב המותאם אישית ServiceMonitor עוקב אחרי כל שירותי Kubernetes בכל מרחבי השמות ואוסף אותם

מידע נוסף על ההגדרה המלאה של ServiceMonitor זמין בהגדרה של משאב מותאם אישית של ServiceMonitor .

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

גרסה < 1.0

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

שדרוג של AlloyDB Omni

שרת יחיד

ההוראות האלה רלוונטיות רק ל-AlloyDB Omni מגרסה 15.2.0 ואילך.

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

במחשב שלכם צריכה להיות מותקנת גרסה 1.2 ואילך של AlloyDB Omni CLI.

ביצוע השדרוג

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

sudo alloydb database-server upgrade

‏Kubernetes

השלבים שצריך לבצע כדי לשדרג את AlloyDB Omni ב-Kubernetes תלויים בגרסה של AlloyDB Omni שמופעלת ובגרסה שאליה משדרגים.

איך קובעים את מספרי הגרסאות הנוכחיים

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

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'

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

‫DB_CLUSTER_NAME: השם של אשכול מסד הנתונים. זהו אותו שם של אשכול מסדי הנתונים שהצהרתם עליו כשיצרתם אותו.
‫NAMESPACE: מרחב השמות של Kubernetes באשכול מסד הנתונים.

אם אתם מריצים גרסה 1.0.0 ואילך של AlloyDB Omni Operator, הפקודה הזו מדפיסה את הגרסה של AlloyDB Omni שנמצאת בשימוש באשכול מסד הנתונים.

כדי לבדוק את הגרסה של AlloyDB Omni Operator שמותקנת באשכול Kubernetes, מריצים את הפקודה הבאה:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'

אם אתם מריצים גרסה 1.0.0 ואילך של AlloyDB Omni Operator, הפקודה הזו תדפיס את מספר הגרסה של AlloyDB Omni Operator שפועלת באשכול Kubernetes שלכם.

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

אחרת, ממשיכים לקטע הבא.

הגדרה של מספרי גרסאות היעד

אם אתם מריצים גרסה של AlloyDB Omni Operator 1.0.0 ואילך, השלבים הבאים תלויים בגרסה של AlloyDB Omni שאליה אתם רוצים לשדרג. לשם כך, צריך להבין את מספר הגרסה של AlloyDB Omni.

מספר הגרסה של AlloyDB Omni מורכב משלושה חלקים:

מספר הגרסה הראשית של התאימות ל-PostgreSQL
מספר הגרסה המשנית של התאימות ל-PostgreSQL
מספר גרסת התיקון של מהדורת AlloyDB Omni הזו

לדוגמה, גרסה 15.5.2 של AlloyDB Omni היא גרסת תיקון 2 של AlloyDB Omni שתומכת בגרסה 15.5 של PostgreSQL.

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

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

אחרת, ממשיכים לקטע הבא.

שדרוג של AlloyDB Omni Operator

כדי לשדרג את AlloyDB Omni Operator:

מגדירים את משתני הסביבה הנדרשים:
```
export GCS_BUCKET=alloydb-omni-operator
export OPERATOR_VERSION=OPERATOR_VERSION
export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz
```
מחליפים את OPERATOR_VERSION בגרסה של AlloyDB Omni Operator שאליה משדרגים – לדוגמה, 1.1.0.

מורידים את הגרסה החדשה יותר של AlloyDB Omni Operator:

gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz

החלת ההגדרות החדשות יותר של משאב מותאם אישית של AlloyDB Omni Operator:
```
kubectl apply -f alloydbomni-operator/crds
```

משדרגים את תרשים ה-Helm של AlloyDB Omni Operator:

helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
--namespace alloydb-omni-system \
--atomic \
--timeout 5m

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

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

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

מגדירים את databaseVersion למספר הגרסה המלא של AlloyDB Omni שאליה רוצים לשדרג את אשכול מסד הנתונים הזה.
אם שדרגתם גם את AlloyDB Omni Operator, צריך להגדיר את controlPlaneAgentsVersion למספר הגרסה המלא של AlloyDB Omni Operator ששדרגתם.

אם אתם משדרגים רק את גרסת התיקון של AlloyDB Omni – לדוגמה, מעדכנים את databaseVersion מגרסה 15.5.1 לגרסה 15.5.2 – אז השלב הזה הוא כל מה שאתם צריכים לעשות.

אם משדרגים את הגרסה המשנית של התאימות ל-PostgreSQL – לדוגמה, מעדכנים את databaseVersion מ-15.4.1 ל-15.5.2 – צריך לעדכן גם את controlPlaneAgentsVersion. במקרה כזה, חשוב לוודא שביצעתם את השלבים הנוספים שמפורטים במאמר שדרוג AlloyDB Omni Operator.

לדוגמה, בקטע המניפסט הבא מוגדר אשכול מסד נתונים שמופעל באמצעות AlloyDB Omni Operator בגרסה 15.5.2, עם AlloyDB Omni Operator בגרסה 1.0.0:

apiVersion: alloydbomni.dbadmin.goog/v1 
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 15.5.2
  controlPlaneAgentsVersion: 1.0.0

בדוגמה הזו, כדי לשדרג את אשכול מסד הנתונים לגרסה 15.5.3 של AlloyDB Omni, משנים את databaseVersion: 15.5.2 ל-databaseVersion: 15.5.3.

שדרוג מ-AlloyDB Omni Operator בגרסה שלפני 1.0.0

אם אתם מריצים גרסה של AlloyDB Omni Operator שקודמת לגרסה 1.0.0, שדרוג של התקנת AlloyDB Omni מבוססת-Kubernetes כולל הסרה והתקנה מחדש של AlloyDB Omni Operator אחרי גיבוי הנתונים. איך לעשות את זה?

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

kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

לכל אשכול מסדי נתונים, משתמשים בפקודה pg_dumpall כדי לייצא את כל הנתונים שלו.

אזהרה: חשוב לא לדלג על השלב הזה. אם לא תייצאו את הנתונים, בשלב הבא הם יימחקו ולא תהיה אפשרות לשחזר אותם.
מסירים את AlloyDB Omni Operator. כולל מחיקה של כל אשכולות מסדי הנתונים.
מתקינים מחדש את AlloyDB Omni Operator. אתם יכולים להשתמש באותן פקודות שבהן השתמשתם כדי להתקין את הגרסה הקודמת של AlloyDB Omni Operator, בלי לציין מספר גרסה חדש.
יוצרים מחדש את אשכולות מסדי הנתונים. אתם יכולים להתאים את אותם קובצי מניפסט שבהם השתמשתם כשיצרתם בעבר את אשכולות מסדי הנתונים. יכול להיות שתצטרכו לעדכן את הקבצים כדי לשקף שינויים ב-API שהוצגו בגרסה 1.0.0 של AlloyDB Omni Operator, כמו מאפיין databaseVersion שמחליף את המאפיין הישן יותר version.
אפשר להשתמש ב-pg_restore או בפקודה \i ב-psql כדי לייבא את הנתונים שייצאתם קודם לאשכולות שנוצרו מחדש.

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

ההוראות האלה רלוונטיות רק ל-AlloyDB Omni מגרסה 15.2.1 עד 15.5.2. הם לא רלוונטיים לפריסות מבוססות-Kubernetes של AlloyDB Omni.

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

sudo alloydb database-server rollback

הסרת AlloyDB Omni

שרת יחיד

כדי להסיר את AlloyDB Omni, מריצים את הפקודה הבאה:

sudo alloydb database-server uninstall

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

‏Kubernetes

מחיקת אשכול מסד הנתונים

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

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

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

הסרה של AlloyDB Omni Operator

כדי להסיר את AlloyDB Omni Kubernetes Operator מאשכול Kubernetes, פועלים לפי השלבים הבאים:

מחיקת כל אשכולות מסדי הנתונים:

for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
done
done

מחכים עד שה-Kubernetes Operator של AlloyDB Omni ימחק את כל אשכולות מסדי הנתונים. משתמשים בפקודה הבאה כדי לבדוק אם נשארו משאבי מסד נתונים:
```
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
```

מחיקת משאבים אחרים שנוצרו על ידי AlloyDB Omni Kubernetes Operator:

kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

מסירים את AlloyDB Omni Kubernetes Operator:

helm uninstall alloydbomni-operator --namespace alloydb-omni-system

מחיקת סודות, תיאורים של משאבים מותאמים אישית ומרחבי שמות שקשורים ל-AlloyDB Omni Kubernetes Operator:

kubectl delete certificate -n alloydb-omni-system --all
kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
kubectl delete crd -l alloydb-omni=true
kubectl delete ns alloydb-omni-system

שינוי הגודל של אשכול מסד נתונים מבוסס Kubernetes

כדי לשנות את הגודל של ה-CPU, הזיכרון או האחסון של אשכול מסד נתונים מבוסס-Kubernetes, צריך לעדכן את השדה resources במניפסטים שמגדירים את ה-Pod שלו. האופרטור AlloyDB Omni מחיל את המפרטים החדשים על ה-pod של מסד הנתונים באופן מיידי.

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

ההגבלות הבאות חלות על שינוי של משאבים באשכול מסדי נתונים פעיל:

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

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

ניהול תפקידי משתמשים

מעקב אחרי AlloyDB Omni

שרת יחיד

‏Kubernetes

איתור קובצי היומן של אשכול מסד הנתונים

הצגת רשימה של שירותי ניטור

v1.0

גרסה < 1.0

הצגת מדדי Prometheus משורת הפקודה

הצגת מדדים באמצעות Prometheus API

v1.0

גרסה < 1.0

שדרוג של AlloyDB Omni

שרת יחיד

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

ביצוע השדרוג

‏Kubernetes

איך קובעים את מספרי הגרסאות הנוכחיים

הגדרה של מספרי גרסאות היעד

שדרוג של AlloyDB Omni Operator

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

שדרוג מ-AlloyDB Omni Operator בגרסה שלפני 1.0.0

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

הסרת AlloyDB Omni

שרת יחיד

‏Kubernetes

מחיקת אשכול מסד הנתונים

הסרה של AlloyDB Omni Operator

שינוי הגודל של אשכול מסד נתונים מבוסס Kubernetes

ניהול ומעקב אחרי AlloyDB Omni