Fehlerbehebung: Cassandra-Wiederherstellung

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.

Symptom

Während der Cassandra-Wiederherstellung in Apigee Hybrid können Fehler in den Wiederherstellungslogs auftreten.

Fehlermeldung

Ihnen wird in den Logs eines der folgenden Elemente angezeigt:

java.net.ConnectException: Connection timed out (Connection timed out)

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Mögliche Ursachen

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Zeitüberschreitung der Verbindung	Dieser Fehler ist ein Verbindungsfehler zwischen `apigee-cassandra-restore`-Pods und `apigee-cassandra-default-*`-Pods.	Apigee hybrid
Zeitüberschreitung beim Vorgang	Dieser Fehler tritt auf, wenn die Wiederherstellung nach mehr als 15 Minuten abläuft.	Apigee hybrid
Bereits vorhanden	Diese Fehlermeldung hängt nicht mit der Ursache des Problems zusammen und ist das Ergebnis des Wiederholungsvorgangs eines Wiederherstellungsjobs.	Apigee hybrid

Ursache: Zeitüberschreitung bei der Verbindung

Der folgende Fehler ist ein Verbindungsfehler zwischen apigee-cassandra-restore-Pods und apigee-cassandra-default-*-Pods:

java.net.ConnectException: Connection timed out (Connection timed out)

Diagnose

Wenn Ihr Hostnetzwerk nicht vom Pod-Netzwerk aus erreichbar ist, prüfen Sie, ob hostNetwork unter cassandra in overrides.yaml auf false gesetzt ist, wie in Region aus einer Sicherung wiederherstellen gezeigt.
Melden Sie sich zum Testen der Verbindung beim apigee-mart- oder apigee-runtime-Pod an, der sich im selben Netzwerk wie der apigee-cassandra-restore-Job befindet. Sie können auch einen beliebigen anderen Pod im Pod-Netzwerk verwenden.
1. Rufen Sie den Namen des apigee-mart-Pods ab:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
2. Führen Sie eine Bash-Sitzung im Mart-Pod aus:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Ersetzen Sie MART_POD_NAME durch den Namen des MART-Pods. Beispiel: apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
3. Führen Sie Konnektivitätstests für Cassandra-Ports aus:
```
curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:9042
```
```
curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:7001
```
Wenn Sie einen Connection timed out-Fehler in der Ausgabe erhalten, bedeutet dies, dass es Verbindungsprobleme gibt. Wenn Sie jedoch die Connected to-Meldung sehen, die eine erfolgreiche Verbindung meldet, nutzen Sie die Tastenkombination Strg + C, um die Verbindung zu schließen und fortzufahren.

Lösung

Achten Sie darauf, dass die HostNetwork-Einstellung in der overrides.yaml-Datei, die für die Wiederherstellung verwendet wird, auf false gesetzt ist, und wiederholen Sie den Wiederherstellungsprozess. Wenn die Einstellung bereits auf false gesetzt ist, aber dennoch Verbindungsfehler angezeigt werden, prüfen Sie mit folgendem Befehl, ob die Cassandra-Pods ausgeführt werden:

kubectl get pods -n apigee -l app=apigee-cassandra

Ihre Ausgabe sollte in etwa so aussehen:

NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          14m
apigee-cassandra-default-1   1/1     Running   0          13m
apigee-cassandra-default-2   1/1     Running   0          11m
exampleuser@example hybrid-files %

Ursache: Zeitüberschreitung bei Vorgang

Der folgende Fehler tritt auf, wenn bei der Wiederherstellung nach mehr als 15 Minuten eine Zeitüberschreitung auftritt. Der Fehler weist auf E/A-Probleme mit Speicher oder Netzwerk hin, wobei unkomprimierte Inhalte der Sicherung nicht rechtzeitig übertragen werden konnten.

/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client
request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1

Diagnose

Prüfen Sie die apigee-cassandra-default-0-Logs und notieren Sie sich den Zeitstempel des Beginns der Wiederherstellung:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
```
Vergleichen Sie den Zeitstempel mit dem neuesten Log der Tabellenerstellung:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1
```
Die Ergebnisse dieses Vergleichs sollten zeigen, dass der Cassandra-Pod nach der Überschreitung des Zeitlimits noch Tabellen erstellt hat.

Testen Sie die Speicherbandbreite mit folgenden Befehlen:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

kubectl -n apigee exec -it apigee-cassandra-default-1 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

kubectl -n apigee exec -it apigee-cassandra-default-2 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'

Wenn die Schreibgeschwindigkeit weniger als 100 Mbit/s beträgt, kann dies darauf hindeuten, dass nicht die geeignete StorageClass (SSD) verwendet wird.

Testen Sie die Netzwerkbandbreite:
1. Führen Sie netcat auf dem Cassandra-Pod aus, um den Port zu überwachen:
```
kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
```
2. Rufen Sie in einer separaten Shell-Sitzung den Namen des apigee-mart-Pods ab:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
3. Führen Sie eine Bash-Sitzung im apigee-mart-Pod aus. Sie können auch einen beliebigen anderen Pod im Pod-Netzwerk verwenden:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Ersetzen Sie MART_POD_NAME durch den Namen des MART-Pods. Beispiel: apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
4. Führen Sie einen Netzwerkbandbreitentest für den Cassandra-Pod aus, auf dem netcat noch ausgeführt wird:
```
dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456
```
Sie können den Vorgang für andere Cassandra-Pods wiederholen. Beträgt die resultierende Geschwindigkeit weniger als 10 Mio./s, ist die Netzwerkbandbreite wahrscheinlich die Ursache des Problems.

Lösung

Sobald eine langsame E/A-Geschwindigkeit mit den obigen Schritten bestätigt wurde, prüfen Sie, ob Ihr Cluster den Minimalanforderungen an Netzwerk und Speicherkapazität entspricht. Testen Sie die Bandbreite später noch einmal.

Ursache: Bereits vorhanden

Diagnose

Sie erhalten einen Fehler wie den folgenden:

/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists

Lösung

Diese Fehlermeldung hängt nicht mit der Ursache des Problems zusammen und ist das Ergebnis des Wiederholungsvorgangs eines Wiederherstellungsjobs. Die tatsächliche Fehlermeldung sollte in den Logs des ersten fehlgeschlagenen Pods angezeigt werden.

Rufen Sie die Logs des ersten Fehlers ab, um das Problem zu diagnostizieren.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

Erfassen von Diagnoseinformationen erforderlich

Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Apigee-Support:

Erfassen Sie mit folgendem Befehl die Diagnosedaten von den Cassandra-Pods, die eventuell zusätzlich zu den üblichen Daten bereitgestellt werden müssen:

for p in $(kubectl -n apigee get pods -l app=apigee-cassandra --no-headers -o custom-columns=":metadata.name") ; do \
        for com in info describecluster failuredetector version status ring info gossipinfo compactionstats tpstats netstats cfstats proxyhistograms gcstats ; do kubectl \
        -n apigee exec ${p} -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD '"$com"' 2>&1 '\
        | tee /tmp/k_cassandra_nodetool_${com}_${p}_$(date +%Y.%m.%d_%H.%M.%S).txt | head -n 40 ; echo '...' ; done; done

Komprimieren Sie sie und stellen Sie sie im Supportfall bereit:

tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*

Erfassen Sie Logs aus dem Wiederherstellungs-Pod und stellen Sie diese bereit. Beachten Sie, dass Logs kurzlebig sind. Daher sollten sie direkt nach Auftreten eines Fehlers erfasst werden.
Wenn Sie die obigen Diagnoseschritte ausgeführt haben, erfassen Sie alle Ausgaben der Console, kopieren Sie sie in eine Datei und hängen Sie die Datei an die Supportanfrage an.