Esta página foi traduzida pela API Cloud Translation.

Guia de resolução de problemas 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.

Este tópico aborda os passos que pode seguir para resolver problemas com o armazenamento de dados do Cassandra. O Cassandra é um repositório de dados persistente que é executado no componente cassandra da arquitetura de tempo de execução híbrida. Consulte também a vista geral da configuração do serviço de tempo de execução.

Os pods do Cassandra estão bloqueados no estado de lançamento

Sintoma

Depois de tentar fazer uma atualização aos pods do Cassandra, o armazenamento de dados está a comunicar que está bloqueado no estado de lançamento.

Mensagem de erro

Quando usa kubectl para ver os estados do pod, vê que um ou mais pods do Cassandra estão bloqueados no estado de lançamento:

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

Causas possíveis

Um auricular preso no estado de libertação pode dever-se ao seguinte:

Causa	Descrição
Alterações à capacidade de armazenamento	Foram executados passos para alterar a capacidade de armazenamento no ficheiro `override.yaml`.
Outras alterações de configuração	Foram feitas atualizações às propriedades do Cassandra no ficheiro `override.yaml`. No entanto, as alterações não foram aplicadas.

Alterações à capacidade de armazenamento

Diagnóstico

Use kubectl para ver o estado atual do pod apigee datastore:

kubectl get apigeeds -n apigee

NAME STATE AGE
default releasing 122d

Verifique se foram feitas alterações ao ficheiro override.yaml:

Usando o seu sistema de controlo de versões, compare a versão anterior do ficheiro override.yaml com a versão atual:
```
diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
```
A saída de uma diferença no override.yaml pode mostrar o possível problema com o tamanho da capacidade de armazenamento. Por exemplo:
```
# Overrides.yaml  before:
cassandra:
   storage:
      capacity: 500Gi

# Overrides.yaml after:
cassandra:
   storage:
      capacity: 100Gi
```
Se tiver sido realizada uma operação para alterar a capacidade de armazenamento em que foram ignorados passos e foi aplicado diretamente um novo override.yaml, isto pode fazer com que o repositório de dados fique no estado de libertação.

Verifique o statefulset para se certificar de que existe um para apigee-cassandra-default:

kubectl describe sts -n apigee

O resultado tem um aspeto semelhante a este:

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

Verifique se existem erros no controlador do Apigee:

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

Resultados:

"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"

Resolução

Pode repor o estado do Cassandra através dos seguintes passos para o voltar a colocar em execução:

Desative a opção apigee-controller:

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

Devolva o arquivo de dados a um estado de execução com o comando 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'

Volte a aplicar o ficheiro override.yaml original através do Helm:

helm upgrade datastore apigee-datastore/ \
--namespace APIGEE_NAMESPACE \
--atomic \
-f OVERRIDES_FILE \
--dry-run=server

Certifique-se de que inclui todas as definições apresentadas, incluindo --atomic para que a ação seja revertida em caso de falha.

Instale o gráfico:

helm upgrade datastore apigee-datastore/ \
--namespace APIGEE_NAMESPACE \
--atomic \
-f OVERRIDES_FILE

Ative a opção apigee-controller:

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

Aguarde até que o repositório de dados volte a funcionar e valide-o através do seguinte:
```
kubectl get apigeeds --namespace apigee
```

Valide se as implementações e os pods do Apigee estão no estado de execução e se apigeeds já não está no estado de lançamento:

kubectl get ad -n apigee

kubectl get pods -n apigee

kubectl get apigeeds -n apigee

NAME      STATE     AGE
default   running   24d

Outras alterações de configuração

As atualizações feitas às propriedades cassandra no elemento override.yaml não foram aplicadas. Pode ser uma alteração da palavra-passe ou uma alteração aos recursos no override.yaml. Ou aplicar erroneamente o override.yaml errado a um cluster.

Diagnóstico

Consulte os passos em Diagnóstico.

Resolução

Consulte os passos em Resolução.

Tem de recolher informações de diagnóstico

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

Overrides.yaml para cada cluster na instalação.

Uma descarga de cluster-info do Kubernetes da instalação do Apigee Hybrid:

Gerar cluster-info dump do Kubernetes:

kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump

Comprima com o zip do Kubernetes cluster-info dump:

zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*

Os pods do Cassandra estão bloqueados no estado pendente

Sintoma

Ao iniciar, os pods do Cassandra permanecem no estado Pendente.

Mensagem de erro

Quando usa kubectl para ver os estados dos pods, vê que um ou mais pods do Cassandra estão bloqueados no estado Pending. O estado Pending indica que o Kubernetes não consegue agendar o pod num nó: não é possível criar o pod. Por exemplo:

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
...

Causas possíveis

Um pod bloqueado no estado Pendente pode ter várias causas. Por exemplo:

Causa	Descrição
Recursos insuficientes	Não existe CPU ou memória suficiente disponível para criar o pod.
O volume não foi criado	O pod está a aguardar a criação do volume persistente.
Controlador CSI do Amazon EBS em falta	Para instalações do EKS, o controlador CSI do Amazon EBS necessário não está instalado.

Diagnóstico

Use kubectl para descrever o grupo de anúncios para determinar a origem do erro. Por exemplo:

kubectl -n NAMESPACE describe pods POD_NAME

Por exemplo:

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

O resultado pode mostrar um destes possíveis problemas:

Se o problema for a falta de recursos, é apresentada uma mensagem de aviso que indica CPU ou memória insuficientes.
Se a mensagem de erro indicar que o pod tem PersistentVolumeClaims (PVC) imediatos não associados, significa que o pod não consegue criar o respetivo volume persistente.

Resolução

Recursos insuficientes

Modifique o node pool do Cassandra para que tenha recursos de CPU e memória suficientes. Consulte o artigo Redimensionar um conjunto de nós para ver detalhes.

Volume persistente não criado

Se determinar um problema de volume persistente, descreva o PersistentVolumeClaim (PVC) para determinar por que motivo não está a ser criado:

Liste os PVCs no cluster:

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
...

Descreva o PVC do pod com falhas. Por exemplo, o seguinte comando descreve o PVC associado ao pod 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

Tenha em atenção que, neste exemplo, a StorageClass denominada apigee-sc não existe. Para resolver este problema, crie a StorageClass em falta no cluster, conforme explicado em Alterar a StorageClass predefinida.

Veja também Depurar pods.

Controlador CSI do Amazon EBS em falta

Se a instância híbrida estiver a ser executada num cluster do EKS, certifique-se de que o cluster do EKS está a usar o controlador da interface de armazenamento de contentores (CSI) do Amazon EBS. Consulte as Perguntas frequentes sobre a migração do CSI do Amazon EBS para ver detalhes.

Os pods do Cassandra estão bloqueados no estado CrashLoopBackoff

Sintoma

No arranque, os pods do Cassandra permanecem no estado CrashLoopBackoff.

Mensagem de erro

Quando usa kubectl para ver os estados dos pods, vê que um ou mais pods do Cassandra estão no estado CrashLoopBackoff. Este estado indica que o Kubernetes não consegue criar o pod. Por exemplo:

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
...

Causas possíveis

Um pod preso no estado CrashLoopBackoff pode ter várias causas. Por exemplo:

Causa	Descrição
O centro de dados difere do centro de dados anterior	Este erro indica que o pod do Cassandra tem um volume persistente com dados de um cluster anterior e que os novos pods não conseguem juntar-se ao cluster antigo. Normalmente, isto acontece quando os volumes persistentes desatualizados persistem do cluster do Cassandra anterior no mesmo nó do Kubernetes. Este problema pode ocorrer se eliminar e recriar o Cassandra no cluster.
Atualização do Kubernetes	Uma atualização do Kubernetes pode afetar o cluster do Cassandra. Isto pode acontecer quando os nós de trabalho do Anthos que alojam os pods do Cassandra são atualizados para uma nova versão do SO.

Diagnóstico

Verifique o registo de erros do Cassandra para determinar a causa do problema.

Liste os pods para obter o ID do pod do Cassandra com falhas:
```
kubectl get pods -n NAMESPACE
```
Verifique o registo do pod com falhas:
```
kubectl logs POD_ID -n NAMESPACE
```

Resolução

Procure os seguintes indícios no registo do pod:

O centro de dados difere do centro de dados anterior

Se vir esta mensagem de registo:

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

Verifique se existem PVCs desatualizados ou antigos no cluster e elimine-os.
Se esta for uma instalação recente, elimine todos os PVCs e tente novamente a configuração. Por exemplo:
```
kubectl -n NAMESPACE get pvc
kubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
```

A atualização do Anthos altera as definições de segurança

Verifique se existe esta mensagem de erro nos registos do Cassandra:

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

Se a instância híbrida for multirregional, desative a instância híbrida afetada e expanda novamente para a região afetada.
Se a instância híbrida for uma única região, faça um reinício contínuo em cada pod do Cassandra na instância híbrida.

Crie um contentor de cliente para depuração

Esta secção explica como criar um contentor de cliente a partir do qual pode aceder a utilitários de depuração do Cassandra, como cqlsh: o shell CQL. Estas utilidades permitem-lhe consultar tabelas do Cassandra e podem ser úteis para fins de depuração.

Crie o contentor de cliente

Para criar o contentor de cliente, siga estes passos:

O contentor tem de usar o certificado TLS do pod apigee-cassandra-user-setup. Isto é armazenado como um segredo do Kubernetes. Obtenha o nome do segredo que armazena este certificado:
```
kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'
```
Este comando devolve o nome do segredo. Por exemplo: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Vai usá-lo abaixo no campo secretName do ficheiro YAML.

Abra um novo ficheiro e cole a seguinte especificação do pod no mesmo:

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

Guarde o ficheiro com a extensão .yaml. Por exemplo: my-spec.yaml.

Aplique a especificação ao cluster:

kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee

Inicie sessão no contentor:

kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash

Estabeleça ligação à interface do Cassandra cqlsh com o seguinte comando. Introduza o comando exatamente como mostrado:
```
cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
```

Eliminar o pod do cliente

Use este comando para eliminar o pod do cliente Cassandra:

kubectl delete pods -n apigee cassandra-client

Expansão da região configurada incorretamente: todos os nós do Cassandra num único centro de dados

Esta situação ocorre numa expansão multirregional nas plataformas GKE e GKE On-Prem (Anthos). Tente evitar criar todos os nós do Cassandra no mesmo centro de dados.

Sintoma

Os nós do Cassandra não são criados no centro de dados da segunda região.

Mensagem de erro

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

Resolução

Repare a expansão da região configurada incorretamente com os seguintes passos:

Atualize o Cassandra replicaCount para 1 no ficheiro overrides.yaml para o segundo centro de dados. Por exemplo:

cassandra:
  . . .
  replicaCount: 1

Aplique a definição através do Helm:

helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE \
--dry-run=server

Certifique-se de que inclui todas as definições apresentadas, incluindo --atomic para que a ação seja revertida em caso de falha.

Instale o gráfico:

helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE

Use kubectl exec para aceder ao pod do Cassandra restante com o seguinte comando:
```
kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
```

Desative o pod do Cassandra restante com o seguinte comando:

nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission

Elimine os pods do Cassandra do segundo centro de dados através do Helm:
```
helm uninstall datastore -n APIGEE_NAMESPACE
```
Altere o contexto do Kubernetes para o cluster do seu primeiro centro de dados:
```
kubectl config use-context FIRST_DATACENTER_CLUSTER
```
Verifique se não existem nós do Cassandra num estado inativo no primeiro centro de dados.
```
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
```

Verifique se os nós do Cassandra configurados incorretamente (destinados ao segundo centro de dados) foram removidos do primeiro centro de dados. Certifique-se de que os endereços IP apresentados no resultado do comando nodetool status são apenas os endereços IP dos pods do Cassandra destinados ao seu primeiro centro de dados. Por exemplo, na saída seguinte, o endereço IP 10.100.0.39 deve ser para um pod no seu primeiro centro de dados.

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

Verifique se o ficheiro overrides.yaml do segundo centro de dados contém a definição do nome do centro de dados na secção cassandra. Por exemplo:
```
cassandra:
  datacenter: DATA_CENTER_2
  rack: "RACK_NAME" # "ra-1" is the default value.
  . . .
```
Atualize a definição cassandra:replicaCount no ficheiro overrides.yaml para o segundo centro de dados para o número pretendido. Por exemplo:
```
cassandra:
  datacenter: DATA_CENTER_2
  . . .
  replicaCount: 3
```
Nota: o valor de cassandra:replicaCount tem de ser um múltiplo de 3. Use o mesmo valor para replicaCount que especificou para o seu primeiro centro de dados.

Aplique o ficheiro overrides.yaml para o segundo centro de dados com o argumento datastore. Por exemplo:

helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE \
--dry-run=server

Certifique-se de que inclui todas as definições apresentadas, incluindo --atomic para que a ação seja revertida em caso de falha.

Instale o gráfico:

helm upgrade datastore apigee-datastore \
--namespace APIGEE_NAMESPACE \
--atomic \
-f 2ND_DATACENTER_OVERRIDES_FILE

Use kubectl exec para aceder a um dos novos pods do Cassandra no segundo centro de dados e verifique se existem dois centros de dados:
```
 "nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
```

Solução alternativa para o problema conhecido 388608440

Esta secção explica como verificar se a sua instalação é afetada pelo problema conhecido 388608440 e como resolvê-lo.

Diagnóstico

Para verificar se é afetado por este problema conhecido, execute o seguinte comando:

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"'

Por exemplo:

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

Se o número de instantâneos restantes for superior a 0 para qualquer um dos seus pods do Cassandra, a sua instalação é afetada por este problema.

Resolução

Para resolver este problema, siga os passos abaixo, selecionando o tipo de cópia de segurança que usa e a versão secundária do Apigee Hybrid:

Cópia de segurança do Cloud Storage

Certifique-se de que usa a configuração correta para a cópia de segurança do Cloud Storage. Alguns problemas comuns incluem, entre outros, o seguinte:
- É usada a conta de serviço Google errada.
- Nome do contentor do Cloud Storage errado especificado em cassandra.backup.dbStorageBucket.
- A API Google não está acessível através do proxy (se cassandra.backup.httpproxy for usado).
Se encontrar problemas com a configuração, corrija-os antes de continuar.

Elimine manualmente os instantâneos restantes com o seguinte comando:

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)"'

Por exemplo:

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)"'

Por exemplo:

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]

Acione uma tarefa de cópia de segurança manual e valide se é concluída com êxito.
Valide se o arquivo de cópia de segurança criado pela tarefa de cópia de segurança manual foi carregado com êxito para o contentor do Cloud Storage cassandra.backup.dbStorageBucket que especificou no ficheiro overrides.yaml.
Valide se o número de instantâneos restantes é 0 para todos os pods do Cassandra através do comando apresentado anteriormente na secção Diagnóstico.

Cópia de segurança do servidor remoto

Certifique-se de que o servidor de cópia de segurança remoto está em bom estado e é acessível a partir dos pods do Cassandra. Consulte a secção de resolução de problemas para ver os passos de verificação da conetividade SSH. Seguem-se alguns problemas comuns, entre outros:
- A firewall de rede está a bloquear a ligação.
- A chave SSH não está configurada corretamente.
- Não é possível estabelecer ligação ao servidor de cópia de segurança remoto.
- O servidor de cópias de segurança remoto está sem armazenamento gratuito.
Se encontrar problemas com o servidor de cópia de segurança remota, corrija-os antes de continuar.

Elimine manualmente os instantâneos restantes com o seguinte comando:

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)"'

Por exemplo:

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)"'

Por exemplo:

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]

Acione uma tarefa de cópia de segurança manual e valide se é concluída com êxito.
Valide se o arquivo de cópia de segurança criado pela tarefa de cópia de segurança manual foi carregado com êxito para o servidor de cópia de segurança remoto.
Valide se o número de instantâneos restantes é 0 para todos os pods do Cassandra através do comando apresentado anteriormente na secção Diagnóstico.

Recursos adicionais

Consulte o artigo Introdução aos manuais de procedimentos do Apigee X e do Apigee Hybrid.

Guia de resolução de problemas do Cassandra Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Os pods do Cassandra estão bloqueados no estado de lançamento

Sintoma

Mensagem de erro

Causas possíveis

Alterações à capacidade de armazenamento

Diagnóstico

Resolução

Outras alterações de configuração

Diagnóstico

Resolução

Tem de recolher informações de diagnóstico

Os pods do Cassandra estão bloqueados no estado pendente

Sintoma

Mensagem de erro

Causas possíveis

Diagnóstico

Resolução

Recursos insuficientes

Volume persistente não criado

Controlador CSI do Amazon EBS em falta

Os pods do Cassandra estão bloqueados no estado CrashLoopBackoff

Sintoma

Mensagem de erro

Causas possíveis

Diagnóstico

Resolução

O centro de dados difere do centro de dados anterior

A atualização do Anthos altera as definições de segurança

Crie um contentor de cliente para depuração

Crie o contentor de cliente

Eliminar o pod do cliente

Expansão da região configurada incorretamente: todos os nós do Cassandra num único centro de dados

Sintoma

Mensagem de erro

Resolução

Solução alternativa para o problema conhecido 388608440

Diagnóstico

Resolução

Cópia de segurança do Cloud Storage

Apigee Hybrid 1.12

Apigee Hybrid 1.11

Cópia de segurança do servidor remoto

Apigee Hybrid 1.12

Apigee Hybrid 1.11

Recursos adicionais

Guia de resolução de problemas do Cassandra