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

מדריך לפתרון בעיות ב-Cassandra

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

תאי Cassandra תקועים במצב 'בהמתנה לשחרור'

תיאור הבעיה

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

הודעת השגיאה

כשמשתמשים ב-kubectl כדי להציג את מצבי ה-pod, רואים ש-pod אחד או יותר של Cassandra תקועים במצב releasing:

Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Ack 57s (x7 over 24h) apigee-datastore release started

סיבות אפשריות

יכולות להיות כמה סיבות לכך ש-Pod נתקע במצב releasing:

מטרה	תיאור
שינויים בנפח האחסון	בוצעו פעולות לשינוי קיבולת האחסון בקובץ `override.yaml`.
שינויים אחרים בהגדרות	בוצעו עדכונים במאפייני cassandra בקובץ `override.yaml`, אבל השינויים לא נכנסו לתוקף.

שינויים בנפח האחסון

אבחון

משתמשים ב-kubectl כדי לראות את המצב הנוכחי של apigee ה-pod של מאגר הנתונים:
```
kubectl get apigeeds -n apigee
```
```
NAME STATE AGE
default releasing 122d
```
בודקים אם בוצעו שינויים בקובץ override.yaml:

באמצעות מערכת בקרת הגרסאות, משווים בין הגרסה הקודמת של הקובץ override.yaml לבין הגרסה הנוכחית:
```
diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
```
הפלט של ההשוואה ב-override.yaml עשוי להציג את הבעיה האפשרית בגודל של נפח האחסון. לדוגמה:
```
# Overrides.yaml  before:
cassandra:
   storage:
      capacity: 500Gi

# Overrides.yaml after:
cassandra:
   storage:
      capacity: 100Gi
```
אם הייתה פעולה של שינוי נפח האחסון שבה דילגו על שלבים, והוחל ישירות override.yaml חדש, יכול להיות שמאגר הנתונים יהיה במצב של שחרור.

בודקים את statefulset כדי לוודא שיש בו רשומה אחת של apigee-cassandra-default:

kubectl describe sts -n apigee

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

Name:               apigee-cassandra-default
Namespace:          apigee
CreationTimestamp:  Tue, 18 Jul 2023 00:40:57 +0000
Selector:           app=apigee-cassandra,name=default
Labels:             apigee.cloud.google.com.revision=v1-2cc098050836c6b4
                    apigee.cloud.google.com.version=v1
                    apigee.cloud.google.com/platform=apigee
                    app=apigee-cassandra
                    name=default
Annotations:        <none>
Replicas:           3 desired | 3 total
Update Strategy:    RollingUpdate
  Partition:        0
Pods Status:        3 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:       apigee.cloud.google.com/apigee_servicename=production
                apigee.cloud.google.com/billing_type=subscription
                apigee.cloud.google.com/platform=apigee
                app=apigee-cassandra
                name=default
                revision=v1
                runtime_type=hybrid
  Annotations:  apigee.cloud.google.com/pod-template-spec-hash: 2cc098050836c6b4
                prometheus.io/path: /metrics
                prometheus.io/port: 7070
                prometheus.io/scheme: https
                prometheus.io/scrape: true
  Containers:
   apigee-cassandra:
    Image:       gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra:1.10.1
    Ports:       7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP
    Host Ports:  7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP
    Requests:
      cpu:      500m
      memory:   1Gi
    Readiness:  exec [/bin/bash -c /opt/apigee/ready-probe.sh] delay=0s timeout=5s period=10s #success=1 #failure=2
    Environment:
      POD_NAME:                  (v1:metadata.name)
      POD_IP:                    (v1:status.podIP)
      MAX_HEAP_SIZE:            512M
      HEAP_NEWSIZE:             100M
      CASSANDRA_SEEDS:          apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local
      CASSANDRA_CLUSTER_NAME:   apigeecluster
      CASSANDRA_DC:             dc-1
      CASSANDRA_RACK:           ra-1
      CASSANDRA_OPEN_JMX:       true
      CPS_ADMIN_USER:           <set to the key 'admin.user' in secret 'apigee-datastore-default-creds'>        Optional: false
      CPS_ADMIN_PASSWORD:       <set to the key 'admin.password' in secret 'apigee-datastore-default-creds'>    Optional: false
      APIGEE_JMX_USER:          <set to the key 'jmx.user' in secret 'apigee-datastore-default-creds'>          Optional: false
      APIGEE_JMX_PASSWORD:      <set to the key 'jmx.password' in secret 'apigee-datastore-default-creds'>      Optional: false
      CASS_PASSWORD:            <set to the key 'default.password' in secret 'apigee-datastore-default-creds'>  Optional: false
      APIGEE_JOLOKIA_USER:      <set to the key 'jolokia.user' in secret 'apigee-datastore-default-creds'>      Optional: false
      APIGEE_JOLOKIA_PASSWORD:  <set to the key 'jolokia.password' in secret 'apigee-datastore-default-creds'>  Optional: false
    Mounts:
      /opt/apigee/apigee-cassandra/conf from appsfs (rw)
      /opt/apigee/customer from cwc-volume (ro)
      /opt/apigee/data from cassandra-data (rw)
      /opt/apigee/ssl from tls-volume (ro)
      /var/secrets/google from apigee-cassandra-backup (rw)
      /var/secrets/keys from apigee-cassandra-backup-key-file (rw)
  Volumes:
   cwc-volume:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  config-cassandra-default
    Optional:    false
   tls-volume:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  apigee-cassandra-default-tls
    Optional:    false
   appsfs:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
   apigee-cassandra-backup:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  apigee-cassandra-backup-svc-account
    Optional:    true
   apigee-cassandra-backup-key-file:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  apigee-cassandra-backup-key-file
    Optional:    true
Volume Claims:
  Name:          cassandra-data
  StorageClass:
  Labels:        <none>
  Annotations:   <none>
  Capacity:      10Gi
  Access Modes:  [ReadWriteOnce]
Events:
  Type    Reason            Age   From                    Message
  ----    ------            ----  ----                    -------
  Normal  SuccessfulCreate  47m   statefulset-controller  create Pod apigee-cassandra-default-2 in StatefulSet apigee-cassandra-default successful

בודקים אם יש שגיאות בבקר apigee:

kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore

תוצאות:

"error creating
apigee-cassandra object: failed to update resource
apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\"
is invalid: spec: Forbidden: updates to statefulset spec for fields other than
'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy'
and 'minReadySeconds' are forbiddenerror creating apigee-cassandra object:
failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps
\"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset
spec for fields other than 'replicas', 'template', 'updateStrategy',
'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"

רזולוציה

אפשר לאפס את המצב של Cassandra לפי השלבים הבאים כדי להחזיר אותו למצב פעיל:

משביתים את apigee-controller:

kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false

מחזירים את מאגר הנתונים למצב פעיל באמצעות הפקודה PATCH:

curl -XPATCH \-H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'

מחילים מחדש את הקובץ המקורי override.yaml באמצעות Helm:
```
helm upgrade datastore apigee-datastore/ \
--namespace APIGEE_NAMESPACE \
--atomic \
-f OVERRIDES_FILE \
--dry-run=server
```
חשוב לכלול את כל ההגדרות שמוצגות, כולל --atomic כדי שהפעולה תבוטל אם היא תיכשל.

מתקינים את התרשים:
```
helm upgrade datastore apigee-datastore/ \
--namespace APIGEE_NAMESPACE \
--atomic \
-f OVERRIDES_FILE
```

מפעילים את apigee-controller:

kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true

ממתינים עד שמאגר הנתונים יחזור לפעולה ומבצעים אימות באמצעות הפעולות הבאות:
```
kubectl get apigeeds --namespace apigee
```
מוודאים שהפריסות וה-pods של Apigee נמצאים בסטטוס 'פועל', ושהערך של apigeeds כבר לא במצב 'הפצה':
```
kubectl get ad -n apigee
```
```
kubectl get pods -n apigee
```
```
kubectl get apigeeds -n apigee
```
```
NAME      STATE     AGE
default   running   24d
```

שינויים אחרים בהגדרות

העדכונים שבוצעו במאפייני cassandra ב-override.yaml לא נכנסו לתוקף. יכול להיות שזה שינוי סיסמה או שינוי במשאבים ב-override.yaml. או החלה שגויה של override.yaml לא נכון על אשכול.

אבחון

אפשר לעיין בשלבים שבקטע אבחון.

רזולוציה

השלבים מפורטים בקטע פתרון.

צריך לאסוף פרטי אבחון

אם הבעיה נמשכת גם אחרי שמבצעים את ההוראות שלמעלה, צריך לאסוף את נתוני האבחון הבאים ואז לפנות אל Cloud Customer Care:

‫Overrides.yaml לכל אשכול בהתקנה.
‫dump של פרטי אשכול Kubernetes מההתקנה של Apigee Hybrid:

יצירת cluster-info dump של kubernetes:
```
kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
```
דחיסה באמצעות zip kubernetes cluster-info dump:
```
zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
```

תאי Cassandra תקועים במצב Pending

תיאור הבעיה

בזמן ההפעלה, ה-pods של Cassandra נשארים במצב Pending.

הודעת השגיאה

כשמשתמשים בפקודה kubectl כדי להציג את מצבי ה-pod, רואים שאחד או יותר מ-Cassandra pods תקועים במצב Pending. המצב Pending מציין ש-Kubernetes לא יכול לתזמן את ה-Pod בצומת: אי אפשר ליצור את ה-Pod. לדוגמה:

kubectl get pods -n NAMESPACE

NAME                                     READY   STATUS      RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed   0          10m
apigee-cassandra-default-0               0/1     Pending     0          10m
...

סיבות אפשריות

יכולות להיות כמה סיבות לכך ש-Pod תקוע במצב 'בהמתנה'. לדוגמה:

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

אבחון

משתמשים ב-kubectl כדי לתאר את ה-pod ולקבוע את מקור השגיאה. לדוגמה:

kubectl -n NAMESPACE describe pods POD_NAME

לדוגמה:

kubectl describe pods apigee-cassandra-default-0 -n apigee

יכול להיות שיוצגו בתוצאה אחת מהבעיות האפשריות הבאות:

אם הבעיה היא משאבים לא מספיקים, תוצג הודעת אזהרה שמציינת שאין מספיק מעבד או זיכרון.
אם בהודעת השגיאה מצוין שה-pod כולל PersistentVolumeClaims (PVC)‎ לא מאוגדים מיידיים, זה אומר שה-pod לא יכול ליצור Persistent volume משלו.

רזולוציה

אין מספיק משאבים

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

נפח אחסון מתמיד לא נוצר

אם מזהים בעיה בנפח אחסון קבוע, מתארים את PersistentVolumeClaim ‏ (PVC) כדי להבין למה הוא לא נוצר:

מציגים ברשימה את ה-PVC באשכול:

kubectl -n NAMESPACE get pvc

NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cassandra-data-apigee-cassandra-default-0   Bound    pvc-b247faae-0a2b-11ea-867b-42010a80006e   10Gi       RWO            standard       15m
...

מתארים את ה-PVC של הפוד שנכשל. לדוגמה, הפקודה הבאה מתארת את ה-PVC שקשור לפוד apigee-cassandra-default-0:
```
kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0

Events:
  Type     Reason              Age                From                         Message
  ----     ------              ----               ----                         -------
  Warning  ProvisioningFailed  3m (x143 over 5h)  persistentvolume-controller  storageclass.storage.k8s.io "apigee-sc" not found
```
שימו לב שבדוגמה הזו, StorageClass בשם apigee-sc לא קיים. כדי לפתור את הבעיה, צריך ליצור את StorageClass החסר באשכול, כמו שמוסבר במאמר שינוי ברירת המחדל של StorageClass.

אפשר לעיין גם במאמר ניפוי באגים ב-Pods.

חסר מנהל התקן CSI של Amazon EBS

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

תאי Cassandra תקועים במצב CrashLoopBackoff

תיאור הבעיה

במהלך ההפעלה, ה-pods של Cassandra נשארים במצב CrashLoopBackoff.

הודעת השגיאה

כשמשתמשים בפקודה kubectl כדי להציג את מצבי ה-pod, רואים שאחד או יותר מ-Cassandra pods נמצאים במצב CrashLoopBackoff. הסטטוס הזה מציין ש-Kubernetes לא יכול ליצור את ה-pod. לדוגמה:

kubectl get pods -n NAMESPACE

NAME                                     READY   STATUS            RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed         0          10m
apigee-cassandra-default-0               0/1     CrashLoopBackoff  0          10m
...

סיבות אפשריות

יכולות להיות כמה סיבות לכך ש-Pod תקוע במצב CrashLoopBackoff. לדוגמה:

מטרה	תיאור
מרכז הנתונים שונה ממרכז הנתונים הקודם	השגיאה הזו מציינת של-Cassandra pod יש נפח אחסון קבוע שמכיל נתונים מקלאסטר קודם, וה-pods החדשים לא יכולים להצטרף לקלאסטר הישן. זה קורה בדרך כלל כשנפחי אחסון מתמיד לא עדכניים נשארים מהאשכול הקודם של Cassandra באותו צומת Kubernetes. הבעיה הזו יכולה לקרות אם מוחקים את Cassandra באשכול ויוצרים אותו מחדש.
שדרוג של Kubernetes	שדרוג של Kubernetes עשוי להשפיע על אשכול Cassandra. זה יכול לקרות כשצמתי העובדים של Anthos שמארחים את ה-pods של Cassandra משודרגים לגרסה חדשה של מערכת ההפעלה.

מטרה

תיאור

מרכז הנתונים שונה ממרכז הנתונים הקודם

השגיאה הזו מציינת של-Cassandra pod יש נפח אחסון קבוע שמכיל נתונים מקלאסטר קודם, וה-pods החדשים לא יכולים להצטרף לקלאסטר הישן. זה קורה בדרך כלל כשנפחי אחסון מתמיד לא עדכניים נשארים מהאשכול הקודם של Cassandra באותו צומת Kubernetes. הבעיה הזו יכולה לקרות אם מוחקים את Cassandra באשכול ויוצרים אותו מחדש.

שדרוג של Kubernetes

שדרוג של Kubernetes עשוי להשפיע על אשכול Cassandra. זה יכול לקרות כשצמתי העובדים של Anthos שמארחים את ה-pods של Cassandra משודרגים לגרסה חדשה של מערכת ההפעלה.

אבחון

כדי לזהות את הגורם לבעיה, צריך לבדוק את יומן השגיאות של Cassandra.

מציגים את רשימת ה-Pods כדי לקבל את המזהה של ה-Pod של Cassandra שנכשל:
```
kubectl get pods -n NAMESPACE
```
בודקים את היומן של ה-Pod שנכשל:
```
kubectl logs POD_ID -n NAMESPACE
```

רזולוציה

מחפשים את הרמזים הבאים ביומן של ה-pod:

מרכז הנתונים שונה ממרכז הנתונים הקודם

אם רואים את הודעת היומן הזו:

Cannot start node if snitch's data center (us-east1) differs from previous data center

בודקים אם יש PVC ישנים או לא עדכניים באשכול ומוחקים אותם.
אם זו התקנה חדשה, צריך למחוק את כל ה-PVC ולנסות להגדיר שוב. לדוגמה:
```
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
```

שינוי הגדרות האבטחה בשדרוג של Anthos

בודקים אם הודעת השגיאה הזו מופיעה ביומני Cassandra:

/opt/apigee/run.sh: line 68: ulimit: max locked memory:
  cannot modify limit: Operation not permitted

אם המופע ההיברידי הוא מופע רב-אזורי, צריך להוציא משימוש את המופע ההיברידי המושפע ולהרחיב מחדש לאזור המושפע.
אם מדובר באזור יחיד, מבצעים הפעלה מחדש מתגלגלת בכל פוד של Cassandra במופע ההיברידי.

יצירת מאגר תגים של לקוח לצורך ניפוי באגים

בקטע הזה מוסבר איך ליצור מאגר לקוחות שממנו אפשר לגשת לכלי ניפוי הבאגים של Cassandra, כמו cqlsh: מעטפת CQL. הכלים האלה מאפשרים לכם לבצע שאילתות בטבלאות Cassandra, והם יכולים להיות שימושיים למטרות ניפוי באגים.

יצירת מאגר תגים בצד הלקוח

כדי ליצור את מאגר התגים של הלקוח:

מאגר התגים צריך להשתמש באישור ה-TLS מ-pod‏ apigee-cassandra-user-setup. הוא מאוחסן כסוד של Kubernetes. מאחזרים את שם הסוד שבו מאוחסן האישור:
```
kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
```
הפקודה הזו מחזירה את שם הסוד. לדוגמה: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. תשתמשו בערך הזה בשדה secretName בקובץ ה-YAML.

פותחים קובץ חדש ומדביקים בו את מפרט ה-pod הבא:

apiVersion: v1
kind: Pod
metadata:
  labels:
  name: CASSANDRA_CLIENT_NAME   # For example: my-cassandra-client
  namespace: apigee
spec:
  containers:
  - name: CASSANDRA_CLIENT_NAME
    image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.5.
    imagePullPolicy: Always
    command:
    - sleep
    - "3600"
    env:
    - name: CASSANDRA_SEEDS
      value: apigee-cassandra-default.apigee.svc.cluster.local
    - name: APIGEE_DML_USER
      valueFrom:
        secretKeyRef:
          key: dml.user
          name: apigee-datastore-default-creds
    - name: APIGEE_DML_PASSWORD
      valueFrom:
        secretKeyRef:
          key: dml.password
          name: apigee-datastore-default-creds
    volumeMounts:
    - mountPath: /opt/apigee/ssl
      name: tls-volume
      readOnly: true
  volumes:
  - name: tls-volume
    secret:
      defaultMode: 420
      secretName: YOUR_SECRET_NAME    # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
  restartPolicy: Never

שומרים את הקובץ עם הסיומת .yaml. לדוגמה: my-spec.yaml.

מחילים את המפרט על האשכול:

kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee

מתחברים למאגר:

kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash

מתחברים לממשק של Cassandra cqlsh באמצעות הפקודה הבאה. מזינים את הפקודה בדיוק כמו שהיא מוצגת:
```
cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
```

מחיקת ה-pod של הלקוח

משתמשים בפקודה הזו כדי למחוק את ה-pod של לקוח Cassandra:

kubectl delete pods -n apigee cassandra-client

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

המצב הזה מתרחש בהרחבה של כמה אזורים בפלטפורמות GKE ו-GKE בארגון (Anthos). מומלץ להימנע מניסיון ליצור את כל צמתי Cassandra באותו מרכז נתונים.

תיאור הבעיה

יצירת צמתים של Cassandra במרכז הנתונים באזור השני נכשלת.

הודעת השגיאה

failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed

רזולוציה

כדי לתקן את ההגדרה השגויה של הרחבת האזור:

מעדכנים את Cassandra replicaCount ל-1 בקובץ overrides.yaml של מרכז הנתונים השני. לדוגמה:
```
cassandra:
  . . .
  replicaCount: 1
```
מחילים את ההגדרה באמצעות Helm:
```
helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE \
--dry-run=server
```
חשוב לכלול את כל ההגדרות שמוצגות, כולל --atomic כדי שהפעולה תבוטל אם היא תיכשל.

מתקינים את התרשים:
```
helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE
```
משתמשים ב-kubectl exec כדי לגשת ל-pod הנותר של Cassandra באמצעות הפקודה הבאה:
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```
משביתים את ה-pod של Cassandra שנותר באמצעות הפקודה הבאה:
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
```
מוחקים את ה-pods של Cassandra ממרכז הנתונים השני באמצעות Helm:
```
helm uninstall datastore -n APIGEE_NAMESPACE
```
משנים את ההקשר של Kubernetes לאשכול של מרכז הנתונים הראשון:
```
kubectl config use-context FIRST_DATACENTER_CLUSTER
```
מוודאים שאין צמתים של Cassandra במצב השבתה במרכז הנתונים הראשון.
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
```
מוודאים שהצמתים של Cassandra שהוגדרו בצורה שגויה (שמיועדים למרכז הנתונים השני) הוסרו ממרכז הנתונים הראשון. מוודאים שכתובות ה-IP שמוצגות בפלט של nodetool status הן רק כתובות ה-IP של פודים של Cassandra שמיועדים למרכז הנתונים הראשון. לדוגמה, בתוצאה הבאה כתובת ה-IP 10.100.0.39 צריכה להיות של יחידת אירוח במרכז הנתונים הראשון.
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status

  Datacenter: dc-1
  ================
  Status=U/D (Up/Down) | State=N/L/J/M (Normal/Leaving/Joining/Moving)
  --  Address      Load      Tokens  Owns (effective)  Host ID                               Rack
  UN  10.100.0.39  4.21 MiB  256     100.0%            a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d  ra-1
```
מוודאים שקובץ overrides.yaml של מרכז הנתונים השני מכיל את ההגדרה של שם מרכז הנתונים בקטע cassandra. לדוגמה:
```
cassandra:
  datacenter: DATA_CENTER_2
  rack: "RACK_NAME" # "ra-1" is the default value.
  . . .
```
מעדכנים את ההגדרה cassandra:replicaCount בקובץ overrides.yaml של מרכז הנתונים השני למספר הרצוי. לדוגמה:
```
cassandra:
  datacenter: DATA_CENTER_2
  . . .
  replicaCount: 3
```
הערה: הערך של cassandra:replicaCount חייב להיות כפולה של 3. צריך להשתמש באותו ערך של replicaCount שציינתם למרכז הנתונים הראשון.
מחילים את הקובץ overrides.yaml על מרכז הנתונים השני באמצעות הארגומנט datastore. לדוגמה:
```
helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE \
--dry-run=server
```
חשוב לכלול את כל ההגדרות שמוצגות, כולל --atomic כדי שהפעולה תבוטל אם היא תיכשל.

מתקינים את התרשים:
```
helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE
```
משתמשים ב-kubectl exec כדי לגשת לאחד מפודי Cassandra החדשים במרכז הנתונים השני ולוודא שיש שני מרכזי נתונים:
```
 "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
```

פתרון עקיף לבעיה ידועה מספר 388608440

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

אבחון

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

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | \
  xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- \
  bash -c 'echo "{}: Found $(nodetool -u cassandra -pw $CASS_PASSWORD listsnapshots | grep -c compaction_history) leftover snapshots"'

לדוגמה:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: Found $(nodetool -u cassandra -pw $CASS_PASSWORD listsnapshots | grep -c compaction_history) leftover snapshots"'

pod/apigee-cassandra-default-0: Found 0 leftover snapshots
pod/apigee-cassandra-default-1: Found 0 leftover snapshots
pod/apigee-cassandra-default-2: Found 0 leftover snapshots

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

רזולוציה

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

גיבוי ב-Cloud Storage

חשוב לוודא שאתם משתמשים בהגדרה הנכונה לגיבוי ב-Cloud Storage. דוגמאות לבעיות נפוצות:
- נעשה שימוש בחשבון שירות לא נכון של Google.
- שם קטגוריה שגוי של Cloud Storage צוין ב-cassandra.backup.dbStorageBucket.
- אי אפשר להגיע אל Google API דרך proxy (אם נעשה שימוש ב-cassandra.backup.httpproxy).
אם מצאתם בעיות בהגדרה, עליכם לתקן אותן לפני שתמשיכו.

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

‫Apigee Hybrid 1.12

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

לדוגמה:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

‫Apigee Hybrid 1.11

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

לדוגמה:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

pod/apigee-cassandra-default-1: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
pod/apigee-cassandra-default-2: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
pod/apigee-cassandra-default-0: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]

מפעילים משימת גיבוי ידני ומוודאים שהיא מסתיימת בהצלחה.
מוודאים שארכיון הגיבוי שנוצר על ידי משימת הגיבוי הידנית הועלה בהצלחה לקטגוריית Cloud Storage‏ cassandra.backup.dbStorageBucket שצוינה בקובץ overrides.yaml.
מוודאים שמספר התמונות שנותרו הוא 0 בכל ה-pods של Cassandra באמצעות הפקודה שמוצגת קודם בקטע אבחון.

גיבוי של שרת מרוחק

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

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

‫Apigee Hybrid 1.12

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

לדוגמה:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot --all)"'

‫Apigee Hybrid 1.11

kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n APIGEE_NAMESPACE -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

לדוגמה:

kubectl -n apigee get pods -l app=apigee-cassandra -o name | xargs -i -P0 kubectl -n apigee -c apigee-cassandra exec {} -- bash -c 'echo "{}: $(nodetool -u cassandra -pw $CASS_PASSWORD clearsnapshot)"'

pod/apigee-cassandra-default-1: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
pod/apigee-cassandra-default-2: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]
pod/apigee-cassandra-default-0: Requested clearing snapshot(s) for [all keyspaces] with [all snapshots]

מפעילים משימת גיבוי ידני ומוודאים שהיא מסתיימת בהצלחה.
מוודאים שארכיון הגיבוי שנוצר על ידי עבודת הגיבוי הידנית הועלה בהצלחה לשרת הגיבוי המרוחק.
מוודאים שמספר התמונות שנותרו הוא 0 בכל ה-pods של Cassandra באמצעות הפקודה שמוצגת קודם בקטע אבחון.

מקורות מידע נוספים

אפשר לעיין במאמר מבוא ל-Apigee X ולמדריכים בנושא Apigee Hybrid.

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

תאי Cassandra תקועים במצב 'בהמתנה לשחרור'

תיאור הבעיה

הודעת השגיאה

סיבות אפשריות

שינויים בנפח האחסון

אבחון

רזולוציה

שינויים אחרים בהגדרות

אבחון

רזולוציה

צריך לאסוף פרטי אבחון

תאי Cassandra תקועים במצב Pending

תיאור הבעיה

הודעת השגיאה

סיבות אפשריות

אבחון

רזולוציה

אין מספיק משאבים

נפח אחסון מתמיד לא נוצר

חסר מנהל התקן CSI של Amazon EBS

תאי Cassandra תקועים במצב CrashLoopBackoff

תיאור הבעיה

הודעת השגיאה

סיבות אפשריות

אבחון

רזולוציה

מרכז הנתונים שונה ממרכז הנתונים הקודם

שינוי הגדרות האבטחה בשדרוג של Anthos

יצירת מאגר תגים של לקוח לצורך ניפוי באגים

יצירת מאגר תגים בצד הלקוח

מחיקת ה-pod של הלקוח

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

תיאור הבעיה

הודעת השגיאה

רזולוציה

פתרון עקיף לבעיה ידועה מספר 388608440

אבחון

רזולוציה

גיבוי ב-Cloud Storage

‫Apigee Hybrid 1.12

‫Apigee Hybrid 1.11

גיבוי של שרת מרוחק

‫Apigee Hybrid 1.12

‫Apigee Hybrid 1.11

מקורות מידע נוספים

מדריך לפתרון בעיות ב-Cassandra