Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi relativi al ripristino di Cassandra

Stai visualizzando la documentazione di Apigee e Apigee hybrid.
Non esiste una documentazione equivalente di Apigee Edge per questo argomento.

Sintomo

Durante il ripristino di Cassandra in Apigee hybrid, potresti riscontrare errori nei log di ripristino.

Messaggio di errore

Nei log viene visualizzato uno dei seguenti valori:

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

Cause possibili

Causa	Descrizione	Istruzioni per la risoluzione dei problemi applicabili a
Timeout della connessione	Questo errore è un errore di connettività tra `apigee-cassandra-restore` pod e `apigee-cassandra-default-*` pod.	Apigee hybrid
Timeout dell'operazione	Questo errore si verifica se il ripristino scade dopo più di 15 minuti.	Apigee hybrid
Esiste già	Questo messaggio di errore non è correlato alla causa del problema ed è il risultato di un nuovo tentativo di un job di ripristino.	Apigee hybrid

Causa: timeout della connessione

Il seguente errore è un errore di connettività tra apigee-cassandra-restore pod e apigee-cassandra-default-* pod:

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

Diagnosi

Se la tua rete host non è raggiungibile dalla rete di pod, assicurati che hostNetwork sia impostato su false in cassandra in overrides.yaml, come mostrato in Ripristino di una regione da un backup.
Per testare la connettività, accedi al pod apigee-mart o apigee-runtime, che si trova nella stessa rete del job apigee-cassandra-restore. Puoi anche utilizzare qualsiasi altro pod nella rete di pod.
1. Ottieni il nome del pod apigee-mart:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
2. Esegui una sessione bash all'interno del mart pod:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Sostituisci MART_POD_NAME con il nome del pod MART. Ad esempio, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
3. Esegui i test di connettività sulle porte Cassandra:
```
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
```
Se viene visualizzato un errore Connection timed out nell'output, significa che hai problemi di connettività. Tuttavia, se viene visualizzato un messaggio Connected to, indica che la connessione è riuscita e che devi premere Ctrl + C per chiudere la connessione e procedere.

Risoluzione

Assicurati che l'impostazione HostNetwork sia impostata su false nel file overrides.yaml utilizzato per il ripristino, quindi ripeti il processo di ripristino. Se l'impostazione è già impostata su false, ma riscontri errori di connettività, assicurati che i pod Cassandra siano attivi e in esecuzione con il seguente comando:

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

Dovresti vedere un output simile all'esempio seguente:

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 %

Causa: timeout dell'operazione

Se il ripristino scade dopo più di 15 minuti, si verifica il seguente errore. L'errore indica problemi di I/O, ad esempio problemi di archiviazione e rete che non riescono a trasmettere in tempo i contenuti non compressi del backup.

/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

Diagnosi

Controlla i log apigee-cassandra-default-0 per prendere nota del timestamp di inizio del ripristino:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
```
Confronta il timestamp con l'ultimo log di creazione della tabella:
```
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1
```
I risultati di questo confronto dovrebbero mostrare che il pod Cassandra era ancora in fase di creazione delle tabelle dopo il superamento del timeout.

Verifica la larghezza di banda dello spazio di archiviazione con i seguenti comandi:

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'

Se la velocità di scrittura è inferiore a 100 M/s, ciò potrebbe indicare la mancanza di un oggetto StorageClass (SSD) appropriato.

Testa la larghezza di banda di rete:
1. Esegui netcat sul pod Cassandra per l'ascolto sulla porta:
```
kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
```
2. In una sessione di shell separata, recupera il nome del pod apigee-mart:
```
kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
```
3. Esegui una sessione bash all'interno del pod apigee-mart. Puoi anche utilizzare qualsiasi altro pod nella rete di pod:
```
kubectl exec -it MART_POD_NAME -n apigee -- bash
```
  Sostituisci MART_POD_NAME con il nome del pod MART. Ad esempio, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.
4. Esegui un test della larghezza di banda della rete sul pod Cassandra su cui è ancora in esecuzione netcat:
```
dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456
```
Puoi ripetere il processo per altri pod Cassandra. Se la velocità risultante è inferiore a 10 M/s, è molto probabile che la causa del problema sia la larghezza di banda di rete.

Risoluzione

Una volta confermata una velocità di I/O bassa con i passaggi precedenti, assicurati che il cluster rispetti i requisiti minimi di rete e archiviazione. Ricontrolla la larghezza di banda in seguito.

Causa: esiste già

Diagnosi

È stato visualizzato un errore simile al seguente:

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

Risoluzione

Questo messaggio di errore non è correlato alla causa del problema ed è il risultato di un nuovo tentativo di un job di ripristino. Il messaggio di errore effettivo dovrebbe essere visualizzato nei log del primo pod che ha riscontrato l'errore.

Recupera i log dell'errore iniziale per diagnosticare il problema.

Se il problema persiste, vai alla pagina Raccogliere informazioni diagnostiche.

Deve raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, raccogli le seguenti informazioni diagnostiche e contatta l'assistenza Apigee:

Oltre ai dati abituali che ti potrebbe essere chiesto di fornire, raccogli i dati diagnostici da tutti i pod Cassandra con il seguente comando:

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

Comprimilo e forniscilo nella richiesta di assistenza:

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

Raccogli e fornisci i log dal pod di ripristino. Tieni presente che i log hanno durata breve, quindi devono essere raccolti subito dopo l'errore.
Se hai seguito i passaggi della diagnostica precedenti, raccogli tutti gli output della console, copiali in un file e allega il file alla richiesta di assistenza.