Estás consultando la documentación de Apigee y Apigee hybrid.
No hay documentación equivalente de
Apigee Edge sobre este tema.
En este tema se describen los pasos que puedes seguir para solucionar problemas con el almacén de datos Cassandra. Cassandra es un
almacén de datos persistente
que se ejecuta en el componente cassandra de la
arquitectura de tiempo de ejecución híbrida.
Consulta también la información general sobre la configuración del servicio del entorno de ejecución.
Los pods de Cassandra se quedan bloqueados en el estado Releasing
Síntoma
Después de intentar actualizar los pods de Cassandra, el almacén de datos informa de que se ha quedado bloqueado en el estado de lanzamiento.
Mensaje de error
Cuando usas kubectl para ver los estados de los pods, verás que uno o varios pods de Cassandra están bloqueados en el estado releasing:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Ack 57s (x7 over 24h) apigee-datastore release started
Posibles motivos
Un pod puede quedarse en el estado de lanzamiento por los siguientes motivos:
| Causa | Descripción |
|---|---|
| Cambios en la capacidad de almacenamiento |
Se han seguido los pasos para cambiar la capacidad de almacenamiento en el archivo override.yaml.
|
| Otros cambios de configuración |
Se han realizado actualizaciones en las propiedades de Cassandra en el archivo override.yaml, pero los cambios no han surtido efecto.
|
Cambios en la capacidad de almacenamiento
Diagnóstico
-
Usa
kubectlpara ver el estado actual del pod deapigeede Datastore:kubectl get apigeeds -n apigee
NAME STATE AGE default releasing 122d
-
Comprueba si se ha modificado el archivo
override.yaml: -
Con tu sistema de control de versiones, compara la versión anterior del archivo
override.yamlcon la versión actual:diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
-
El resultado de una diferencia en el
override.yamlpuede mostrar el posible problema con el tamaño de la capacidad de almacenamiento. Por ejemplo:# Overrides.yaml before: cassandra: storage: capacity: 500Gi # Overrides.yaml after: cassandra: storage: capacity: 100GiSi se ha realizado una operación para cambiar la capacidad de almacenamiento en la que se han omitido pasos y se ha aplicado directamente un nuevo
override.yaml, esto puede provocar que el almacén de datos esté en estado de liberación. -
Comprueba el elemento
statefulsetpara asegurarte de que hay uno paraapigee-cassandra-default:kubectl describe sts -n apigee
La salida tiene un aspecto similar al siguiente:
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
-
Comprueba si hay errores en el controlador de 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"
Resolución
El estado de Cassandra se puede restablecer siguiendo estos pasos para que vuelva a estar en funcionamiento:
-
Inhabilita
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
-
Vuelve a poner el almacén de datos en estado de ejecución con el 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' -
Vuelve a aplicar el archivo
override.yamloriginal con Helm:helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE \ --dry-run=server
Asegúrate de incluir todos los ajustes que se muestran, incluido
--atomicpara que la acción se revierta si falla.Instala el gráfico:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE
-
Habilita
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
-
Espera a que se restaure el almacén de datos y valida que funciona con el siguiente comando:
kubectl get apigeeds --namespace apigee
-
Valida que las implementaciones y los pods de Apigee tengan el estado "Running" y que
apigeedsya no tengan el estado "Releasing":kubectl get ad -n apigee
kubectl get pods -n apigee
kubectl get apigeeds -n apigee
NAME STATE AGE default running 24d
Otros cambios en la configuración
Se han realizado actualizaciones en las propiedades cassandra de override.yaml y los cambios no se han aplicado. Puede tratarse de un cambio de contraseña o de recursos en la override.yaml.
O bien, se ha aplicado erróneamente el override.yaml incorrecto a un clúster.
Diagnóstico
Consulta los pasos en Diagnóstico.
Resolución
Consulta los pasos en la sección Resolución.
Debe recoger información de diagnóstico
Si el problema persiste incluso después de seguir las instrucciones anteriores, recoge la siguiente información de diagnóstico y ponte en contacto con el equipo de Asistencia de Google Cloud:
-
Overrides.yamlpara cada clúster de la instalación. -
Un volcado de información de clúster de Kubernetes de la instalación de Apigee Hybrid:
Generar Kubernetes
cluster-info dump:kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
Comprimir con zip kubernetes
cluster-info dump:zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
Los pods de Cassandra se quedan en el estado Pendiente
Síntoma
Al iniciarse, los pods de Cassandra permanecen en el estado Pendiente.
Mensaje de error
Cuando usas kubectl para ver los estados de los pods, observas que uno o varios pods de Cassandra están bloqueados en el estado Pending. El estado Pending indica que Kubernetes no puede programar el pod en un nodo, por lo que no se puede crear. Por ejemplo:
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
...Posibles motivos
Un pod que se queda en el estado Pending puede deberse a varios motivos. Por ejemplo:
| Causa | Descripción |
|---|---|
| Recursos insuficientes | No hay suficiente CPU o memoria disponible para crear el pod. |
| No se ha creado el volumen | El pod está esperando a que se cree el volumen persistente. |
| Falta el controlador de CSI de Amazon EBS | En las instalaciones de EKS, no se ha instalado el controlador de CSI de Amazon EBS necesario. |
Diagnóstico
Usa kubectl
para describir el pod y determinar la fuente del error. Por ejemplo:
kubectl -n NAMESPACE describe pods POD_NAME
Por ejemplo:
kubectl describe pods apigee-cassandra-default-0 -n apigee
En la salida puede aparecer uno de estos problemas:
- Si el problema es que no hay suficientes recursos, verás un mensaje de advertencia que indica que no hay suficiente CPU o memoria.
- Si el mensaje de error indica que el pod tiene reclamaciones de volumen persistente inmediatas sin enlazar, significa que el pod no puede crear su volumen persistente.
Resolución
Recursos insuficientes
Modifica el grupo de nodos de Cassandra para que tenga suficientes recursos de CPU y memoria. Para obtener más información, consulta Cambiar el tamaño de un grupo de nodos.
No se ha creado el volumen persistente
Si detectas un problema con el volumen persistente, describe la reclamación de volumen persistente (PVC) para determinar por qué no se crea:
- Lista los PVCs del clúster:
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 ...
- Describe el PVC del pod que está fallando. Por ejemplo, el siguiente comando
describe el PVC enlazado al 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
Ten en cuenta que, en este ejemplo, la StorageClass llamada
apigee-scno existe. Para solucionar este problema, crea la StorageClass que falta en el clúster, tal como se explica en Cambiar la StorageClass predeterminada.
Consulta también Depuración de pods.
Falta el controlador de CSI de Amazon EBS
Si la instancia híbrida se ejecuta en un clúster de EKS, asegúrate de que el clúster de EKS utilice el controlador de interfaz de almacenamiento de contenedores (CSI) de Amazon EBS. Consulta las preguntas frecuentes sobre la migración de Amazon EBS CSI para obtener más información.
Los pods de Cassandra se quedan en el estado CrashLoopBackoff
Síntoma
Al iniciarse, los pods de Cassandra permanecen en el estado CrashLoopBackoff.
Mensaje de error
Cuando usas kubectl para ver los estados de los pods, observas que uno o varios pods de Cassandra están en el estado CrashLoopBackoff.
Este estado indica que Kubernetes no puede crear el pod. Por ejemplo:
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
...Posibles motivos
Un pod atascado en el estado CrashLoopBackoff puede deberse a varios motivos. Por ejemplo:
| Causa | Descripción |
|---|---|
| El centro de datos es diferente del anterior | Este error indica que el pod de Cassandra tiene un volumen persistente que contiene datos de un clúster anterior y que los nuevos pods no pueden unirse al clúster antiguo. Esto suele ocurrir cuando los volúmenes persistentes obsoletos persisten del clúster de Cassandra anterior en el mismo nodo de Kubernetes. Este problema puede producirse si eliminas y vuelves a crear Cassandra en el clúster. |
| Actualización de Kubernetes | Una actualización de Kubernetes puede afectar al clúster de Cassandra. Esto puede ocurrir cuando los nodos de trabajador de Anthos que alojan los pods de Cassandra se actualizan a una nueva versión del SO. |
Diagnóstico
Consulta el registro de errores de Cassandra para determinar la causa del problema.
- Lista los pods para obtener el ID del pod de Cassandra que está fallando:
kubectl get pods -n NAMESPACE
- Consulta el registro del pod que falla:
kubectl logs POD_ID -n NAMESPACE
Resolución
Busca las siguientes pistas en el registro del pod:
El centro de datos es diferente del anterior
Si ves este mensaje de registro:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Comprueba si hay PVCs obsoletos o antiguos en el clúster y elimínalos.
- Si se trata de una instalación nueva, elimina todos los PVCs y vuelve a intentar la configuración. Por ejemplo:
kubectl -n NAMESPACE get pvckubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
La actualización de Anthos cambia la configuración de seguridad
Consulta los registros de Cassandra para ver si aparece este mensaje de error:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Si la instancia híbrida es multirregional, retira la instancia híbrida afectada y vuelve a expandirte a la región afectada.
- Si la instancia híbrida es de una sola región, realiza un reinicio gradual en cada pod de Cassandra de la instancia híbrida.
Crear un contenedor de cliente para depuración
En esta sección se explica cómo crear un contenedor de cliente desde el que puedes acceder a las utilidades de depuración de Cassandra, como cqlsh:
el shell de CQL.
Estas utilidades te permiten consultar tablas de Cassandra y pueden ser útiles para depurar.
Crear el contenedor de cliente
Para crear el contenedor de cliente, siga estos pasos:
- El contenedor debe usar el certificado TLS del pod
apigee-cassandra-user-setup. Se almacena como un secreto de Kubernetes. Obtén el nombre del secreto que almacena este certificado:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'Este comando devuelve el nombre del secreto. Por ejemplo:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Lo usarás más abajo en el camposecretNamedel archivo YAML. - Abre un archivo nuevo y pega la siguiente especificación de pod en él:
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
- Guarda el archivo con la extensión
.yaml. Por ejemplo:my-spec.yaml. - Aplica la especificación a tu clúster:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Inicia sesión en el contenedor:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Conéctate a la interfaz
cqlshde Cassandra con el siguiente comando. Introduce el comando exactamente como se muestra:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Eliminar el pod del cliente
Usa este comando para eliminar el pod del cliente de Cassandra:
kubectl delete pods -n apigee cassandra-client
Expansión de región mal configurada: todos los nodos de Cassandra en un centro de datos
Esta situación se produce en una expansión multirregional en las plataformas GKE y GKE On-Prem (Anthos). Intenta no crear todos tus nodos de Cassandra en el mismo centro de datos.
Síntoma
No se pueden crear nodos de Cassandra en el centro de datos de la segunda región.
Mensaje de error
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Resolución
Para reparar la expansión de la región mal configurada, sigue estos pasos:
- Actualice Cassandra
replicaCounta1en el archivooverrides.yamldel segundo centro de datos. Por ejemplo:cassandra: . . . replicaCount: 1
Aplica el ajuste con Helm:
helm upgrade datastore apigee-datastore \ --namespace APIGEE_NAMESPACE \ --atomic \ -f 2ND_DATACENTER_OVERRIDES_FILE \ --dry-run=server
Asegúrate de incluir todos los ajustes que se muestran, incluido
--atomicpara que la acción se revierta si falla.Instala el gráfico:
helm upgrade datastore apigee-datastore \ --namespace APIGEE_NAMESPACE \ --atomic \ -f 2ND_DATACENTER_OVERRIDES_FILE
- Usa
kubectl execpara acceder al pod de Cassandra restante con el siguiente comando:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Retira el resto del pod de Cassandra con el siguiente comando:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Elimina los pods de Cassandra del segundo centro de datos con Helm:
helm uninstall datastore -n APIGEE_NAMESPACE
- Cambia el contexto de Kubernetes al clúster de tu primer centro de datos:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Verifica que no haya nodos de Cassandra inactivos en el primer centro de datos.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Verifica que los nodos de Cassandra mal configurados (destinados al segundo centro de datos) se hayan eliminado del primer centro de datos. Asegúrate de que las direcciones IP que se muestran en la salida del estado de nodetool sean solo las direcciones IP de los pods de Cassandra destinados a tu primer centro de datos. Por ejemplo, en el siguiente resultado, la dirección IP
10.100.0.39debe corresponder a un pod de su primer centro de datos.kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bashnodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD statusDatacenter: 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 - Verifica que el archivo
overrides.yamldel segundo centro de datos contenga el ajuste del nombre del centro de datos en la sección de Cassandra. Por ejemplo:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Actualice el ajuste
cassandra:replicaCounten el archivooverrides.yamldel segundo centro de datos con el número que quiera. Por ejemplo:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Aplica el archivo
overrides.yamlal segundo centro de datos con el argumentodatastore. Por ejemplo:helm upgrade datastore apigee-datastore \ --namespace APIGEE_NAMESPACE \ --atomic \ -f 2ND_DATACENTER_OVERRIDES_FILE \ --dry-run=server
Asegúrate de incluir todos los ajustes que se muestran, incluido
--atomicpara que la acción se revierta si falla.Instala el gráfico:
helm upgrade datastore apigee-datastore \ --namespace APIGEE_NAMESPACE \ --atomic \ -f 2ND_DATACENTER_OVERRIDES_FILE
- Usa
kubectl execpara acceder a uno de los nuevos pods de Cassandra del segundo centro de datos y comprueba que hay dos centros de datos:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Solución alternativa para el problema conocido 388608440
En esta sección se explica cómo comprobar si su instalación se ve afectada por el problema conocido 388608440 y cómo solucionarlo.
Diagnóstico
Para comprobar si te afecta este problema conocido, ejecuta el siguiente 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 ejemplo:
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
Si el número de copias de seguridad restantes es superior a 0 en alguno de tus pods de Cassandra, tu instalación se verá afectada por este problema.
Resolución
Para solucionar este problema, siga los pasos que se indican a continuación y seleccione el tipo de copia de seguridad que utilice y su versión secundaria de Apigee Hybrid:
Copia de seguridad de Cloud Storage
-
Asegúrate de usar la configuración correcta para la copia de seguridad de Cloud Storage. Estos son algunos de los problemas habituales:
- Se usa una cuenta de servicio de Google incorrecta.
- Se ha especificado un nombre de segmento de Cloud Storage incorrecto en cassandra.backup.dbStorageBucket.
- No se puede acceder a la API de Google a través de un proxy (si se usa cassandra.backup.httpproxy ).
Si detectas algún problema con la configuración, corrígelo antes de continuar.
-
Elimina manualmente las instantáneas restantes con el siguiente 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 ejemplo:
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 ejemplo:
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]
- Activa una copia de seguridad manual y comprueba que se completa correctamente.
-
Valida que el archivo de copia de seguridad creado por la tarea de copia de seguridad manual se haya subido correctamente al segmento de Cloud Storage cassandra.backup.dbStorageBucket que hayas especificado en el archivo
overrides.yaml. - Valida que el número de copias de seguridad restantes sea 0 en todos los pods de Cassandra con el comando que se ha indicado anteriormente en la sección Diagnóstico.
Copia de seguridad del servidor remoto
-
Asegúrate de que el servidor de copia de seguridad remoto esté en buen estado y se pueda acceder a él desde los pods de Cassandra.
Consulta la sección Solución de problemas para ver los pasos que debes seguir para verificar la conectividad SSH. Estos son algunos de los problemas habituales:
- El cortafuegos de la red está bloqueando la conexión.
- La clave SSH no está configurada correctamente.
- No se puede acceder al servidor de copia de seguridad remoto.
- El servidor de copias de seguridad remoto se ha quedado sin espacio de almacenamiento.
Si detectas algún problema con el servidor de copia de seguridad remoto, corrígelo antes de continuar.
-
Elimina manualmente las instantáneas restantes con el siguiente 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 ejemplo:
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 ejemplo:
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]
- Activa una copia de seguridad manual y comprueba que se completa correctamente.
- Valida que el archivo de copia de seguridad creado por el trabajo de copia de seguridad manual se haya subido correctamente al servidor de copia de seguridad remoto.
- Valida que el número de copias de seguridad restantes sea 0 en todos los pods de Cassandra con el comando que se ha indicado anteriormente en la sección Diagnóstico.
Recursos adicionales
Consulta la introducción a los manuales de Apigee X y Apigee Hybrid.