Información general sobre la restauración de Cassandra

En esta página se ofrece una descripción general de la restauración de Cassandra en Apigee hybrid.

¿Por qué usar la restauración?

Puedes usar copias de seguridad para restaurar la infraestructura de Apigee desde cero en caso de fallos catastróficos, como la pérdida de datos irrecuperable en tu instancia híbrida de Apigee debido a un desastre. La restauración toma los datos de la ubicación de la copia de seguridad y los restaura en un nuevo clúster de Cassandra con el mismo número de nodos. No se toman datos de clúster del clúster de Cassandra antiguo. El objetivo del proceso de restauración es devolver una instalación híbrida de Apigee a un estado operativo anterior mediante los datos de copia de seguridad de una instantánea.

No se recomienda usar copias de seguridad para restaurar datos en los siguientes casos:

  • Fallos de nodos de Cassandra.
  • Eliminación accidental de datos como apps, developers y api_credentials.
  • Una o varias regiones dejan de funcionar en una implementación híbrida multirregión.

Las implementaciones de Apigee Cassandra y la arquitectura operativa se encargan de la redundancia y la tolerancia a fallos de una sola región. En la mayoría de los casos, la implementación de producción multirregión recomendada de la opción híbrida significa que se puede recuperar de un fallo de una región otra región activa mediante procedimientos de retirada y ampliación de regiones en lugar de restaurar desde una copia de seguridad.

Antes de empezar a implementar una restauración a partir de una copia de seguridad de Cassandra, ten en cuenta lo siguiente:

  • Tiempo de inactividad: habrá un tiempo de inactividad durante la restauración.
  • Pérdida de datos: se perderán los datos comprendidos entre la última copia de seguridad válida y el momento en que se complete la restauración.
  • Tiempo de restauración: el tiempo de restauración depende del tamaño de los datos y del clúster.
  • Selección de datos: no puedes seleccionar solo datos específicos para restaurar. Restauración restaura toda la copia de seguridad que selecciones.

Restauraciones multirregionales

Si has instalado Apigee hybrid en varias regiones, debes comprobar el archivo de anulaciones de la región en la que vas a restaurar para asegurarte de que cassandra:hostNetwork esté definido como false antes de realizar la restauración. Para obtener más información, consulta Restaurar en varias regiones.

Requisitos previos

Comprueba que se cumplen todos los requisitos previos. Investiga los errores de los requisitos previos antes de continuar con la restauración.

  1. Verifica que todos los pods de Cassandra estén activos y en funcionamiento con el siguiente comando. 
    kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    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 %
  2. Verifica que el conjunto con estado de Cassandra muestra que todos los pods se están ejecutando con el siguiente comando. 
    kubectl get sts -n APIGEE_NAMESPACE -l app=apigee-cassandra

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    NAME                       READY   AGE
apigee-cassandra-default   3/3     15m
  3. Verifica que el recurso ApigeeDatastore esté en estado running con el siguiente comando. 
    kubectl get apigeeds -n APIGEE_NAMESPACE

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    NAME      STATE     AGE
default   running   16m
  4. Verifica que todos los PVCs de Cassandra tengan el estado Bound con el siguiente comando. 
    kubectl get pvc -n APIGEE_NAMESPACE -l app=apigee-cassandra

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    NAME                                        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
cassandra-data-apigee-cassandra-default-0   Bound    pvc-a14184e7-8745-4b30-8069-9d50642efe04   10Gi       RWO            standard-rwo   17m
cassandra-data-apigee-cassandra-default-1   Bound    pvc-ed129dcb-4706-4bad-a692-ac7c78bad64d   10Gi       RWO            standard-rwo   15m
cassandra-data-apigee-cassandra-default-2   Bound    pvc-faed0ad1-9019-4def-adcd-05e7e8bb8279   10Gi       RWO            standard-rwo   13m
  5. Verifica que todos los PVs de Cassandra tengan el estado Bound con el siguiente comando. 
    kubectl get pv -n APIGEE_NAMESPACE

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                              STORAGECLASS   REASON   AGE
pvc-a14184e7-8745-4b30-8069-9d50642efe04   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-0   standard-rwo            17m
pvc-ed129dcb-4706-4bad-a692-ac7c78bad64d   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-1   standard-rwo            16m
pvc-faed0ad1-9019-4def-adcd-05e7e8bb8279   10Gi       RWO            Delete           Bound    apigee/cassandra-data-apigee-cassandra-default-2   standard-rwo            14m
  6. Verifica que el recurso Apigee Controller tenga el estado Running con el siguiente comando. 
    kubectl get pods -n APIGEE_NAMESPACE-system -l app=apigee-controller

    La salida debería tener un aspecto similar al siguiente ejemplo: 

    NAME                                         READY   STATUS    RESTARTS   AGE
apigee-controller-manager-856d9bb7cb-cfvd7   2/2     Running   0          20m

¿Cómo se restaura?

Los pasos para restaurar Cassandra varían ligeramente en función de si tu Apigee Hybrid se ha desplegado en una o varias regiones. Para ver los pasos detallados de restauración, consulta la siguiente documentación: