Risoluzione dei problemi relativi al ripristino di Cassandra

Stai visualizzando la documentazione relativa a Apigee e Apigee ibrido.
Non esiste una equivalente Documentazione di Apigee Edge per questo argomento.

Sintomo

Durante il ripristino di Cassandra in Apigee hybrid, potresti riscontrare errori nel ripristina i log.

Messaggio di errore

Nei log viene visualizzato uno dei seguenti elementi:

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 Le istruzioni di risoluzione dei problemi applicabili a
Sessione di connessione scaduta Questo è 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
Già esistente Questo messaggio di errore non è correlato alla causa del problema ed è una il risultato di un nuovo tentativo di un job di ripristino. Apigee hybrid

Causa: connessione scaduta

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

  1. Se la rete host non è raggiungibile dalla rete dei pod, assicurati che hostNetwork è impostata su false in cassandra in overrides.yaml come mostrato in Ripristino di una regione da un backup.
  2. Per verificare la connettività, accedi all'apigee-mart o apigee-runtime, che si trova nella stessa rete del Job apigee-cassandra-restore. Puoi anche usare qualsiasi altro pod nella rete dei pod.
    1. Ottieni il nome del apigee-mart pod: 
      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    2. Esegui una sessione bash all'interno del pod mart: 
      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 test di connettività rispetto 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 visualizzi un errore Connection timed out nell'output, significa che hai problemi di connettività. Ma se vedi un Connected to, che indica che connessione è riuscita e 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, e ripeti il processo di ripristino. Se l'impostazione è già impostata su false, ma vengono visualizzati errori di connettività, assicurati che Cassandra i pod sono attivi e in esecuzione con il comando seguente: 

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

L'output dovrebbe essere 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

Il seguente errore si verifica se il ripristino scade dopo più di 15 minuti. L'errore indica problemi di I/O, ad esempio problemi di archiviazione e rete 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

  1. Controlla i log di apigee-cassandra-default-0 per notare che timestamp di inizio del ripristino: 

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1

  2. 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 è ancora in fase di creazione delle tabelle dopo che il timeout era superato.

  3. 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 una mancanza di un adeguato StorageClass (SSD) utilizzato.

  4. Testa la larghezza di banda di rete:

    1. Esegui netcat sul pod Cassandra per eseguire 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, ottieni il nome apigee-mart pod: 

      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. Tu 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 netcat è ancora in esecuzione: 

      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 il risultato è inferiore a 10 M/s, la larghezza di banda della rete è molto probabilmente causa del problema.

Risoluzione

Dopo aver confermato la velocità di I/O bassa seguendo i passaggi precedenti, assicurati che la aderisce al minimo Google Cloud e . di archiviazione. Al termine, verifica nuovamente la larghezza di banda.

Causa: esiste già

Diagnosi

Viene 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 verrà visualizzato nei log del primo pod con errore.

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

Se il problema persiste, vai a Devi raccogliere dati diagnostici.

Raccogliere dati diagnostici

Se il problema persiste anche dopo aver seguito le istruzioni riportate sopra, Raccogli le seguenti informazioni diagnostiche e contatta l'assistenza clienti Google Cloud:

  1. Oltre ai soliti dati che potresti dover fornire, raccogli i dati dati diagnostici di 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

  2. 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*
  3. Raccogliere e fornire dal pod di ripristino. Tieni presente che i log sono di breve durata, quindi devono essere raccolti subito dopo l'errore.
  4. Se hai seguito la procedura di diagnostica precedente, raccogli tutti i componenti della console copiarli in un file e allegarlo alla richiesta di assistenza.