Resolução de problemas do restauro do Cassandra

Está a ver a documentação do Apigee e do Apigee Hybrid.
Não existe um equivalente na documentação do Apigee Edge para este tópico.

Sintoma

Durante o restauro do Cassandra no Apigee hybrid, pode encontrar erros nos registos de restauro.

Mensagem de erro

Vê uma das seguintes opções nos registos:

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

Causas possíveis

Causa Descrição Instruções de resolução de problemas aplicáveis a
A ligação excedeu o tempo limite Este erro é um erro de conetividade entre os auriculares apigee-cassandra-restore e os auriculares apigee-cassandra-default-*. Apigee Hybrid
A operação excedeu o tempo limite Este erro ocorre se o tempo limite da restauração for excedido após mais de 15 minutos. Apigee Hybrid
Já existe Esta mensagem de erro não está relacionada com a causa do problema e é o resultado de uma operação de repetição de uma tarefa de restauro. Apigee Hybrid

Causa: o tempo limite da ligação foi excedido

O erro seguinte é um erro de conetividade entre os pods apigee-cassandra-restore e os pods apigee-cassandra-default-*: 

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

Diagnóstico

  1. Se a sua rede anfitriã não for acessível a partir da rede do pod, certifique-se de que hostNetwork está definido como false em cassandra em overrides.yaml, conforme mostrado em Restaurar uma região a partir de uma cópia de segurança.
  2. Para testar a conetividade, inicie sessão no pod apigee-mart ou no pod apigee-runtime, que está na mesma rede que a tarefa apigee-cassandra-restore. Também pode usar qualquer outro pod na rede de pods.
    1. Obtenha o nome do agrupamento de anúncios:apigee-mart 
      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
    2. Execute uma sessão bash no pod mart: 
      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Substitua MART_POD_NAME pelo nome do pod MART. Por exemplo, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    3. Execute testes de conetividade em relação às portas do 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 receber um erro Connection timed out na saída, significa que tem problemas de conetividade. No entanto, se vir uma mensagem Connected to, significa que a ligação foi estabelecida com êxito e tem de premir Ctrl + C para fechar a ligação e continuar.

Resolução

Certifique-se de que a definição HostNetwork está definida como false no ficheiro overrides.yaml usado para o restauro, e repita o processo de restauro. Se a definição já estiver definida como false, mas vir erros de conetividade, certifique-se de que os pods do Cassandra estão em funcionamento com o seguinte comando: 

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

O resultado deve ter um aspeto semelhante ao seguinte exemplo:

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: a operação excedeu o tempo limite

O seguinte erro ocorre se o restauro exceder o limite de tempo após mais de 15 minutos. O erro indica problemas de E/S, como o armazenamento e a rede, que não conseguem transmitir o conteúdo não comprimido da cópia de segurança a tempo. 

/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

Diagnóstico

  1. Verifique os registos apigee-cassandra-default-0 para anotar a data/hora do início da restauração: 

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

  2. Compare a data/hora com o registo mais recente da criação da tabela:

    kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1

    Os resultados desta comparação devem mostrar que o pod do Cassandra ainda estava a criar tabelas depois de o limite de tempo ter sido excedido.

  3. Teste a largura de banda de armazenamento com os seguintes comandos:

    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 a velocidade de gravação for inferior a 100 MB/s, isto pode indicar a falta de uma StorageClass adequada (SSD) usada.

  4. Teste a largura de banda da rede:

    1. Execute netcat no pod do Cassandra para ouvir na porta: 

      kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'

    2. Numa sessão de shell separada, obtenha o nome do pod apigee-mart: 

      kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"

    3. Execute uma sessão bash no agrupamento apigee-mart. Também pode usar qualquer outro pod na rede de pods: 

      kubectl exec -it MART_POD_NAME -n apigee -- bash

      Substitua MART_POD_NAME pelo nome do pod MART. Por exemplo, apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl.

    4. Execute um teste de largura de banda da rede no pod do Cassandra que ainda está a executar o comando netcat: 

      dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456

    Pode repetir o processo para outros pods do Cassandra. Se a velocidade resultante for inferior a 10 MB/s, é muito provável que a largura de banda da rede seja a causa do problema.

Resolução

Depois de confirmar a velocidade de E/S lenta com os passos acima, certifique-se de que o cluster cumpre os requisitos mínimos de rede e armazenamento. Teste novamente a largura de banda.

Causa: já existe

Diagnóstico

For apresentado um erro semelhante ao seguinte: 

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

Resolução

Esta mensagem de erro não está relacionada com a causa do problema e é o resultado de uma operação de repetição de uma tarefa de restauro. A mensagem de erro real deve ser apresentada nos registos do primeiro pod com falha.

Obtenha os registos da falha inicial para diagnosticar o problema.

Se o problema persistir, aceda a Informações de diagnóstico necessárias.

Solução alternativa para o problema conhecido 391861216

Diagnóstico

O pod do Cassandra com o número mais elevado está no estado CrashLoopBackoff após o restauro. Isto pode ocorrer devido ao problema conhecido 391861216. É apresentado um erro no registo do pod do Cassandra semelhante ao seguinte: 

Cannot change the number of tokens from 512 to 256

Resolução

Siga os passos abaixo para resolver o problema subjacente. Isto permite que o Cassandra seja iniciado normalmente, preservando os dados.

  1. Inicie a eliminação do PVC para o pod do Cassandra bloqueado no estado CrashLoopBackoff. Defina POD_NAME para o nome do pod no estado CrashLoopBackoff. Defina APIGEE_NAMESPACE para o espaço de nomes do cluster no qual o Apigee está instalado. 

    kubectl delete pvc cassandra-data-POD_NAME -n APIGEE_NAMESPACE --wait=false

  2. Elimine o pod no estado CrashLoopBackoff. 

    kubectl delete pod POD_NAME -n APIGEE_NAMESPACE

  3. Altere manualmente o anfitrião inicial do Cassandra para o pod com o número mais elevado. Por exemplo, se tiver 3 réplicas, SEED_POD_NAME deve ser apigee-cassandra-default-2. Só precisa de fazer isto uma vez e pode ignorar este passo para agrupamentos subsequentes. 

    kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":"SEED_POD_NAME.apigee-cassandra-default.APIGEE_NAMESPACE.svc.cluster.local"}}}}}'

  4. Remova o nó com 512 tokens do anel do Cassandra. 

    kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status' | awk '/^DN .*\?.* 512 / {print $6; exit}; /^DN .* [KMG]iB.* 512 / {print $7; exit}' | xargs -I {} kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD removenode {}'

  5. Aguarde que o pod do Cassandra seja recuperado, reinicie-o possivelmente mais do que uma vez e atinja um estado de Ready2/2. O pod seguinte mais elevado passa para o estado CrashLoopBackoff. 

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

  6. Atualize POD_NAME e repita os passos anteriores para os restantes pods, um de cada vez, à medida que entram no estado CrashLoopBackoff até que todos os pods estejam num estado Ready de 2/2 e tenham um estado Running.

  7. Verifique se todos os pods aderiram com êxito ao anel do Cassandra. 

    kubectl exec -n APIGEE_NAMESPACE -t sts/apigee-cassandra-default -c apigee-cassandra -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD status'

    Todos os nós do Cassandra devem ter o estado UN e 256 tokens.

  8. Reverta a alteração ao anfitrião inicial do Cassandra. 

    kubectl patch apigeeds/default -n APIGEE_NAMESPACE --type='merge' -p '{"spec": {"components": {"cassandra": {"properties": {"externalSeedHost":""}}}}}'

    O controlador do Apigee Datastore reinicia novamente os pods do Cassandra, uma vez que reverte a alteração do anfitrião inicial.

Tem de recolher informações de diagnóstico

Se o problema persistir mesmo depois de seguir as instruções acima, reúna as seguintes informações de diagnóstico e, em seguida, contacte o apoio ao cliente do Google Cloud:

  1. Além dos dados habituais que lhe podem ser solicitados, recolha os dados de diagnóstico de todos os pods do Cassandra com o seguinte 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. Comprima-o e faculte-o no registo de apoio técnico:

    tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*
  3. Recolha e faculte registos do pod de restauro. Tenha em atenção que os registos têm uma duração curta, pelo que devem ser recolhidos imediatamente após a falha.
  4. Se seguiu os passos de diagnóstico acima, recolha todas as saídas da consola, copie-as para um ficheiro e anexe o ficheiro ao registo de apoio técnico.