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

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

פתרון בעיות באופרטור AlloyDB Omni Kubernetes

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

בדף הזה מוסבר איך לפתור בעיות באופרטור AlloyDB Omni Kubernetes.

איסוף מידע על תוצאות ניפוי הבאגים

בקטעים האלה מוסבר איך לאסוף יומנים והגדרות לצורך ניפוי באגים.

אחזור יומנים מתרמילי אופרטורים

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

kubectl logs deployments/fleet-controller-manager -c fleet-manager -n alloydb-omni-system > alloydb-omni-system-fleet-controller-manager.out
kubectl logs deployments/local-controller-manager -c local-manager -n alloydb-omni-system > alloydb-omni-system-local-controller-manager.out

אחזור יומנים של פוד מסד נתונים

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

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl logs -c database ${DB_POD} -n DB_CLUSTER_NAMESPACE > ${DB_POD}.log
kubectl logs -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -c database -n DB_CLUSTER_NAMESPACE > dbcluster_DB_CLUSTER_NAME.out

דוגמאות ליומנים של בדיקות תקינות מוצלחות של מסד נתונים:

I0813 11:01:49.210051      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196796      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.196853      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:01:59.209824      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197013      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.197093      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:09.210010      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197368      27 gateway.go:166] "DatabaseHealthCheck: handling request" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.197425      27 database.go:702] "dbdaemon/isRestoreInProgress: starting" log_name="agent" project_ns="default" dbcluster="adb"
I0813 11:02:19.210416      27 gateway.go:184] "DatabaseHealthCheck: request handled successfully" log_name="agent" project_ns="default" dbcluster="adb"

אחזור של postgresql.log

כדי לאחזר את postgresql.log, מריצים את הפקודה הבאה:

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE -it ${DB_POD} -- cat /obs/diagnostic/postgresql.log > dbcluster_DB_CLUSTER_NAME_postgresql.log

אחזור קובץ ה-YAML של DBInstance

כדי לאחזר את קובץ ה-YAML של DBInstance, מריצים את הפקודה הבאה:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

אחזור הגדרות ויומנים לתרחישי HA

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

kubectl get replicationconfig.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > replicationconfig_DB_CLUSTER_NAME.yaml
kubectl get deletestandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > deletestandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > createstandbyjobs_DB_CLUSTER_NAME.yaml
kubectl get failovers.alloydbomni.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > failovers_DB_CLUSTER_NAME.yaml

אחזור סטטוסים של Pod ו-STS

כדי לאחזר את הסטטוסים של ה-Pod ושל StatefulSet ‏ (STS), מריצים את הפקודות הבאות:

DB_POD=$(kubectl get pod -n DB_CLUSTER_NAMESPACE -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}')
kubectl describe pod ${DB_POD} -n DB_CLUSTER_NAMESPACE > pod_${DB_POD}.out
kubectl describe statefulset -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE > statefulset_DB_CLUSTER_NAME.out

זיהוי השגיאות

בקטעים האלה מוסבר איך לזהות שגיאות.

חיפוש של סטטוס שגיאה וקודי שגיאה

כדי לזהות את קוד השגיאה, בודקים את קובץ ה-YAML של DBCluster בקטע status. מידע נוסף מופיע במסמכי התיעוד של קודי השגיאה.

כדי לאחזר את קובץ ה-YAML של DBCluster, מריצים את הפקודה הבאה:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > dbcluster_DB_CLUSTER_NAME.yaml

מחפש את criticalIncidents. בקטע הזה מופיע קוד השגיאה ו-stack trace.

דוגמאות לcriticalIncidents:

status:
    certificateReference:
      certificateKey: ca.crt
      secretRef:
        name: dbs-al-cert-dr-mce
        namespace: dr
    conditions:
    -   lastTransitionTime: "2024-10-07T22:46:03Z"
    ...
    criticalIncidents:
    -   code: DBSE0304
      createTime: "2024-10-03T11:50:54Z"
      message: 'Healthcheck: Health check invalid result.'
      resource:
        component: healthcheck
        location:
          group: alloydbomni.internal.dbadmin.goog
          kind: Instance
          name: bc0f-dr-mce
          namespace: dr
          version: v1
      stackTrace:
      -   component: healthcheck
        message: 'DBSE0304: Healthcheck: Health check invalid result. rpc error: code
          = Code(10304) desc = DBSE0304: Healthcheck: Health check invalid result.
          dbdaemon/healthCheck: invalid timestamp read back from the healthcheck table.
          Lag is 384837.296269 seconds, wanted 35 seconds'

אפשר גם לאחזר את הסטטוס על ידי חילוץ שדות ספציפיים בפורמט JSON:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o jsonpath='{.status.criticalIncidents}' | jq

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

[
  {
    "code": "DBSE0085",
    "createTime": "2024-03-14T05:41:37Z",
    "message": "Platform: Pod is unschedulable.",
    "resource": {
      "component": "provisioning",
      "location": {
        "group": "alloydb.internal.dbadmin.goog",
        "kind": "Instance",
        "name": "b55f-testdbcluster",
        "namespace": "dbs-system",
        "version": "v1"
      }
    },
    "stackTrace": [
      {
        "component": "provisioning",
        "message": "DBSE0085: Platform: Pod is unschedulable. 0/16 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/16 nodes are available: 16 No preemption victims found for incoming pod..: Pod is unschedulable"
      }
    ]
  }
]

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

kubectl get instances.alloydbomni.internal.dbadmin.goog -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME -n DB_CLUSTER_NAMESPACE -o yaml > instance_DB_CLUSTER_NAME.yaml
kubectl get pods -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE

ניפוי באגים בבעיות שקשורות לזיכרון

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

הפעלה של heapdump

מומלץ להפעיל את התכונה הזו רק לצורך פתרון בעיות. חשוב לזכור להשבית אותו אחר כך.

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

משנים את הפריסה של האופרטור במרחב השמות alloydb-omni-system עם השם fleet-controller-manager ו-local-controller-manager.
מוסיפים את הארגומנט הבא ל-pod‏ --pprof-address=:8642 או לכל יציאה זמינה אחרת.
מחכים שה-pod של בקר יופעל מחדש.

מעבירים את היציאה הקודמת. לדוגמה:

kubectl port-forward FLEET_CONTROLLER_MANAGER_POD_NAME -n alloydb-omni-system 8642:8642

בטרמינל אחר, מריצים את הפקודה go tool pprof http://localhost:8642/debug/pprof/heap. אם לא משתמשים ב-8642, צריך לשנות את היציאה כך שתתאים ליציאה הקודמת.
מתחברים לכתובת ומריצים פקודות לפתרון בעיות. לדוגמה: top.
אחרי שמסיימים את פתרון הבעיות, מבטלים את הפעולה שבוצעה בשלב 1 על ידי הסרת הארגומנט ומחכים להפעלה מחדש של ה-pod.

קביעת מספר המשאבים שהמפעיל עוקב אחריהם

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

kubectl get backuprepositories -A  | wc -l
kubectl get failovers -A  | wc -l
kubectl get instancebackupplans -A  | wc -l
kubectl get instancebackups -A  | wc -l
kubectl get instancerestores -A  | wc -l
kubectl get instances -A  | wc -l
kubectl get instanceswitchovers -A  | wc -l
kubectl get lrojobs -A  | wc -l
kubectl get replicationconfigs -A  | wc -l
kubectl get sidecars -A  | wc -l
kubectl get deployments -A  | wc -l
kubectl get statefulsets -A  | wc -l
kubectl get certificates.cert-manager.io -A  | wc -l
kubectl get issuers.cert-manager.io -A  | wc -l
kubectl get configmaps -A  | wc -l
kubectl get persistentvolumeclaims -A  | wc -l
kubectl get persistentvolumes -A  | wc -l
kubectl get pods -A  | wc -l
kubectl get secrets -A  | wc -l
kubectl get services -A  | wc -l
kubectl get storageclasses.storage.k8s.io -A  | wc -l

לדוגמה, אם מספר הסודות גבוה, יכול להיות שתוצג שגיאת Out Of Memory ‏(OOM).

kubectl get secrets -A | wc -l

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

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

ההגדרה של AlloyDB Omni HA כוללת שלושה שלבים:

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

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

לכל מופע שמשכפל מופע צריך להיות replicationconfig מצורף. לדוגמה:

kubectl get replicationconfigs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

פלט לדוגמה:

NAME                 PARENT     TYPE       ROLE         READY   HEALTHY   SYNC_U   SYNC_D   SLOT_LOG   SLOT_REPLAY
cd58-adb--58ea-adb   cd58-adb   Physical   Upstream     True    True      true
ds-58ea-adb          58ea-adb   Physical   Downstream   True    True               true

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

משרות בהמתנה

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

createstandbyjobs.alloydbomni.internal.dbadmin.goog
deletestandbyjobs.alloydbomni.internal.dbadmin.goog

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

kubectl get createstandbyjobs.alloydbomni.internal.dbadmin.goog -n DB_CLUSTER_NAMESPACE

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

apiVersion: alloydbomni.dbadmin.gdc.goog/v1
  kind: CreateStandbyJob
  metadata:
    creationTimestamp: "2024-11-05T03:34:26Z"
    finalizers:
    -   createstandbyjob.dbadmin.goog/finalizer
    generation: 1804
    labels:
      dbs.internal.dbadmin.goog/dbc: foo-ha-alloydb1-clone1
    name: foo-ha-alloydb1-clone1--ac00-foo-ha-alloydb1-clone1--6036-foo-ha-alloydb1-clone1-1730777666
    namespace: db
    resourceVersion: "11819071"
    uid: 1f24cedf-b326-422f-9405-c96c8720cd90
  spec:
    attempt: 3
    cleanup: false
    currentStep: SetupSynchronous
    currentStepTime: "2024-11-05T03:45:31Z"
    metadata:
      dbc: foo-ha-alloydb1-clone1
      primaryInstance: ac00-foo-ha-alloydb1-clone1
      retryError: 'etcdserver: leader changed'
      standbyInstance: 6036-foo-ha-alloydb1-clone1
    requeueTime: "2024-11-05T18:33:03Z"
    startTime: "2024-11-05T03:36:56Z"

אימות ראשי

הדבר הראשון שצריך לוודא הוא שהכתובת הראשית מוגדרת בצורה נכונה. צריך ליצור פרופיל שכפול לכל שרת המתנה. אם הערך של isSynchronous הוא true במפרט ובסטטוס, ההגדרה הושלמה. אם הערך של isSynchronous הוא false במפרט ובסטטוס, המשמעות היא שהבקשה עדיין לא הגיעה לשלב 3. בודקים את המשימות במצב המתנה כדי לראות אם יש משימות שפועלות, ואם יש הודעות שגיאה.

  replication:
    profiles:
    -   isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      password:
        name: ha-rep-pw-dbcluster-sample
        namespace: default
      passwordResourceVersion: "896080"
      role: Upstream
      type: Physical
      username: alloydbreplica

מוודאים שההערה disableHealthcheck היא false. ההגדרה הזו מיועדת להשבתה רק במהלך מעבר לגיבוי או מעבר לשרת חלופי.

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

שאילתות

כדי לוודא שהמשאבים ב-DB pod מוגדרים בצורה תקינה, נכנסים למסד הנתונים בתור משתמש האדמין alloydbadmin. לאחר מכן מריצים את השאילתות הבאות:

משבצת שכפול

\x on
select * from pg_replication_slots;

-[ RECORD 1 ]-------+---------------------------------------------
slot_name           | d85d_dbcluster_sample
plugin              |
slot_type           | physical
datoid              |
database            |
temporary           | f
active              | t
active_pid          | 250
xmin                | 16318
catalog_xmin        |
restart_lsn         | 0/CA657F0
confirmed_flush_lsn |
wal_status          | reserved
safe_wal_size       |
two_phase           | f

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

אם הערך של active הוא לא t (true), המשמעות היא שהחיבור למצב המתנה לא מתבצע מסיבה כלשהי (רשת, הגדרת מצב המתנה לא הושלמה וכו'), וכנראה שיהיה צורך להמשיך בניפוי הבאגים בצד של מצב המתנה.

נתונים סטטיסטיים על שכפול

\x on
select * from pg_stat_replication;

-[ RECORD 1 ]----+----------------------------------------------------------------
pid              | 250
usesysid         | 16385
usename          | alloydbreplica
application_name | d85d_dbcluster_sample
client_addr      | 10.54.79.196
client_hostname  | gke-samwise-default-pool-afaf152d-8197.us-central1-a.c.foo
client_port      | 24914
backend_start    | 2024-10-30 21:44:26.408261+00
backend_xmin     |
state            | streaming
sent_lsn         | 0/CA64DA8
write_lsn        | 0/CA64DA8
flush_lsn        | 0/CA64DA8
replay_lsn       | 0/CA64DA8
write_lag        |
flush_lag        |
replay_lag       |
sync_priority    | 2
sync_state       | sync
reply_time       | 2024-11-04 22:08:04.370838+00

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

אימות בהמתנה

למצב ההמתנה צריך להיות פרופיל שכפול שתואם לאותו פרופיל של השרת הראשי:

  replication:
    profiles:
    -   host: 10.54.79.210
      isActive: true
      isSynchronous: true
      name: ha:4c82-dbcluster-sample::d85d-dbcluster-sample
      passwordResourceVersion: "896080"
      port: 5432
      role: Downstream
      type: Physical
      username: alloydbreplica

אם אין חיבור משרת הגיבוי לשרת הראשי, יש שתי אפשרויות נפוצות:

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

כדי לבדוק אם מתרחש תרחיש 1, צריך לקבל את היומנים של ה-pod של מסד הנתונים ולחפש הצהרות ביומן בשם dbdaemon/setupPhysicalReplicationDownstream. ריכזנו כאן דוגמאות ליומני הגדרה מוצלחים:

I1104 22:42:42.604871     103 replication.go:107] "dbdaemon/setupPhysicalReplicationDownstream: begin setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:42,605 INFO waiting for postgres to stop
2024-11-04 22:42:43,566 INFO stopped: postgres (exit status 0)
I1104 22:42:43.567590     103 replication.go:131] "dbdaemon/setupPhysicalReplicationDownstream: about to call pg_basebackup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample" cmd=["-h","10.54.79.210","-D","/mnt/disks/pgsql/pg_basebackup_data","-U","alloydbreplica","-v","-P","-p","5432","-w","-c","fast"]
I1104 22:42:44.206403     103 replication.go:139] "dbdaemon/setupPhysicalReplicationDownstream: pg_basebackup finished" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.206440     103 replication.go:141] "dbdaemon/setupPhysicalReplicationDownstream: replacing data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244749     103 replication.go:148] "dbdaemon/setupPhysicalReplicationDownstream: replaced data directory with pg_basebackup data directory" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.244783     103 replication.go:150] "dbdaemon/setupPhysicalReplicationDownstream: Creating config files" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251565     103 replication.go:155] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql config file for log archiving" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251621     103 replication.go:160] "dbdaemon/setupPhysicalReplicationDownstream: removing postgresql auto config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:44.251689     103 replication.go:165] "dbdaemon/setupPhysicalReplicationDownstream: Successfully wrote to config file" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
2024-11-04 22:42:44,256 INFO spawned: 'postgres' with pid 271
2024-11-04 22:42:45,469 INFO success: postgres entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
I1104 22:42:45.469838     103 replication.go:174] "dbdaemon/setupPhysicalReplicationDownstream: backup replication configuration after changing replication config" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"
I1104 22:42:45.476732     103 replication.go:179] "dbdaemon/setupPhysicalReplicationDownstream: finished standby setup" log_name="agent" project_ns="default" dbcluster="dbcluster-sample"

אם יש שגיאת חיבור, צריך לבדוק את היומנים של db pod ואת קובץ היומן במסד הנתונים בכתובת /obs/diagnostic/postgresql.log ולראות מה השגיאה כשמנסים להתחבר. שגיאה נפוצה אחת היא שאין קישוריות בין השרת במצב המתנה לבין השרת הראשי.

תיקונים ידניים

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

מוחקים ידנית את מכונות ה-Standby.
מתחברים למסד הנתונים הראשי. מריצים שאילתה על משבצות השכפול הנוכחיות ומוחקים את משבצות השכפול של הגיבויים שרוצים למחוק:
```
select pg_drop_replication_slot('REPLICATION_SLOT_NAME');
```
מוחקים את כל פרופילי השכפול מהמופע הראשי שרוצים למחוק.

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

apiVersion: alloydbomni.internal.dbadmin.goog/v1
kind: Instance
metadata:
  annotations:
    dbs.internal.dbadmin.goog/consecutiveHealthcheckFailures: "0"
    dbs.internal.dbadmin.goog/disableHealthcheck: "false"
    dr-secondary: "false"
    forceReconcile: "1730414498"

איסוף יומני ביקורת והמנוע של מסד הנתונים

יומני המנוע של מסד הנתונים ויומני הביקורת זמינים כקבצים בתוך ה-pod של מסד הנתונים (נדרשת גישת root):

obs/diagnostic/postgresql.log
obs/diagnostic/postgresql.audit

DB_POD=$(kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -n DB_CLUSTER_NAMESPACE -o jsonpath='{.items[0].metadata.name}')
kubectl exec -c database -n DB_CLUSTER_NAMESPACE ${DB_POD} -it -- /bin/bash

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

ls -l /obs/diagnostic/