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

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

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

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

שרת יחיד

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

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

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

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

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

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

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

אם לא, עוברים לקטע הבא.

קביעת מספרי הגרסה של היעד

אם אתם משתמשים בגרסה 1.0.0 ומעלה של אופרטור AlloyDB Omni, השלבים הבאים תלויים בגרסה של 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 עצמו, לצד אשכול מסד הנתונים. לכל קבוצה של גרסאות AlloyDB Omni שתומכות בגרסה משנית מסוימת של PostgreSQL יש מספר גרסה משויך של אופרטור AlloyDB Omni, שאפשר למצוא בהערות הגרסה של גרסת AlloyDB Omni.

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

אם לא, עוברים לקטע הבא.

שדרוג של אופרטור AlloyDB Omni

כדי לשדרג את אופרטור AlloyDB Omni:

מגדירים את משתני הסביבה הנדרשים:
```
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 שאליה משדרגים – לדוגמה, 1.1.0.

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

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

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

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

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

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

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

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

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

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

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

לדוגמה, בקטע הבא מהמניפסט מוגדר אשכול של מסדי נתונים שפועל בו אופרטור AlloyDB Omni בגרסה 15.5.2, עם אופרטור AlloyDB Omni בגרסה 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.

שדרוג מגרסה קודמת ל-1.0.0 של אופרטור AlloyDB Omni

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

מציגים רשימה של כל אשכולות מסדי הנתונים:
```
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
```
לכל אשכול מסדי נתונים, משתמשים בפקודה pg_dumpall כדי לייצא את כל הנתונים שלו.

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

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

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

כדי לחזור לגרסה הקודמת של 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

כדי להסיר את 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

מחכים עד שהאופרטור של AlloyDB Omni Kubernetes ימחק את כל אשכולות מסדי הנתונים. כדי לבדוק אם נשארו משאבים של מסד הנתונים, משתמשים בפקודה הבאה:
```
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:

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.

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

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

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

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

מעקב אחרי AlloyDB Omni

שרת יחיד

‏Kubernetes

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

רשימת שירותי מעקב

v1.0

גרסה < 1.0

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

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

v1.0

גרסה < 1.0

שדרוג של AlloyDB Omni

שרת יחיד

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

ביצוע השדרוג

‏Kubernetes

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

קביעת מספרי הגרסה של היעד

שדרוג של אופרטור AlloyDB Omni

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

שדרוג מגרסה קודמת ל-1.0.0 של אופרטור AlloyDB Omni

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

הסרת AlloyDB Omni

שרת יחיד

‏Kubernetes

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

הסרת אופרטור AlloyDB Omni

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

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