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

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

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

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

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

  • ל-AlloyDB Omni אין תפקיד alloydbiamuser.

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

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

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

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

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

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

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

  2. מריצים מעטפת ב-pod של מסד הנתונים כמשתמש root.

    kubectl exec ${DB_POD} -it -- /bin/bash

  3. מוצאים את קובצי היומן בספרייה /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 בכל שירותי המעקב.

  1. מגדירים העברת ליציאה אחרת מהסביבה המקומית לשירות המעקב.

    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

  2. בזמן שהפקודה הקודמת פועלת, אפשר לגשת למדדי המעקב באמצעות 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 ואילך.

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

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

ביצוע השדרוג

כדי לשדרג את ההתקנה של 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.

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

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

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

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

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

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

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

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

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

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

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

  1. מגדירים את משתני הסביבה הנדרשים:

    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.

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

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

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

    kubectl apply -f alloydbomni-operator/crds

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

    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, צריך להגדיר את 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

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

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

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

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

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

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

  3. מסירים את ההתקנה של אופרטור AlloyDB Omni. כולל מחיקה של כל אשכולות מסדי הנתונים.

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

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

  6. אפשר להשתמש ב-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

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

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

    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

  2. מחכים עד ש-AlloyDB Omni Kubernetes Operator ימחק את כל אשכולות מסדי הנתונים. כדי לבדוק אם נשארו משאבי מסד נתונים, משתמשים בפקודה הבאה:

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

  3. מחיקת משאבים אחרים שאופרטור AlloyDB Omni Kubernetes יצר:

    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

  4. להסיר את AlloyDB Omni Kubernetes Operator:

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

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

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

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

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