Administra la alta disponibilidad en Kubernetes

Selecciona una versión de la documentación:

En esta página, se muestra cómo habilitar y probar la alta disponibilidad (HA) en tu clúster de base de datos de AlloyDB Omni basado en Kubernetes. Para realizar las tareas que se documentan aquí, se requieren conocimientos básicos sobre la aplicación de archivos de manifiesto de Kubernetes y el uso de la herramienta de línea de comandos kubectl.

Descripción general

Puedes habilitar la HA en tu clúster de base de datos si le indicas al operador de Kubernetes de AlloyDB Omni que cree réplicas en espera de tu instancia de base de datos principal. El operador de AlloyDB Omni configura tu clúster de base de datos para actualizar continuamente los datos en esta réplica, de modo que coincidan con todos los cambios en los datos de tu instancia principal.

Habilita la alta disponibilidad

Antes de habilitar la HA en tu clúster de base de datos, asegúrate de que tu clúster de Kubernetes tenga lo siguiente:

  • Almacenamiento para dos copias completas de tus datos
  • Recursos de procesamiento para dos instancias de base de datos que se ejecutan en paralelo

Para habilitar la HA, sigue estos pasos:

  1. Modifica el manifiesto del clúster de base de datos para incluir una sección availability en su sección spec. En esta sección, se define la cantidad de instancias en espera que deseas agregar mediante la configuración del parámetro numberOfStandbys.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Reemplaza NUMBER_OF_STANDBYS por la cantidad de instancias en espera que deseas agregar. El valor máximo es 5. Si estás configurando la HA y no estás seguro de la cantidad de instancias en espera que necesitas, comienza por establecer el valor en 1 o 2.

  2. Vuelve a aplicar el manifiesto.

Inhabilita la alta disponibilidad

Para inhabilitar la HA, sigue estos pasos:

  1. Establece numberOfStandbys en 0 en el manifiesto del clúster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Vuelve a aplicar el manifiesto.

Verifica la HA en un clúster de base de datos

Para ver el estado actual de HA de un clúster de base de datos, verifica la condición HAReady del estado de ese clúster. Si este valor tiene un status establecido en True, significa que la HA está configurada y funciona en el clúster de base de datos.

Para verificar este valor en la línea de comandos, ejecuta el siguiente comando:

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Reemplaza lo siguiente:

  • DB_CLUSTER_NAME: Es el nombre del clúster de base de datos.

  • NAMESPACE: Es el espacio de nombres del clúster de base de datos.

Realiza una conmutación por error a una instancia en espera

Si tu instancia principal deja de estar disponible por más de 90 segundos, el operador de AlloyDB Omni realiza automáticamente una conmutación por error de la instancia de base de datos principal a la instancia en espera.

Las conmutaciones por error son una buena opción cuando deseas recuperarte rápidamente de una falla inesperada y minimizar el tiempo de inactividad, incluso si eso significa perder una pequeña cantidad de datos, en caso de que la base de datos principal deje de estar disponible antes de que la copia de seguridad se actualice por completo.

El operador de AlloyDB Omni admite la conmutación por error automática y manual. La conmutación por error automática está habilitada de forma predeterminada.

La conmutación por error genera la siguiente secuencia de eventos:

  1. El operador de AlloyDB Omni desconecta la instancia de base de datos principal.

  2. El operador de AlloyDB Omni promueve la réplica en espera para que sea la nueva instancia de base de datos principal.

  3. El operador de AlloyDB Omni borra la instancia de base de datos principal anterior.

  4. El operador de AlloyDB Omni crea una nueva réplica en espera.

Inhabilita la conmutación por error automática

Las conmutaciones por error automáticas están habilitadas de forma predeterminada en los clústeres de base de datos.

Para inhabilitar una conmutación por error, sigue estos pasos:

  1. Establece enableAutoFailover en false en el manifiesto del clúster:

    spec:
  availability:
    enableAutoFailover: false

  2. Vuelve a aplicar el manifiesto.

Activa una conmutación por error manual

Para activar una conmutación por error manual, crea y aplica un manifiesto para un nuevo recurso de conmutación por error:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Reemplaza lo siguiente:

  • FAILOVER_NAME: Es un nombre para este recurso, por ejemplo, failover-1.

  • NAMESPACE: Es el espacio de nombres para este recurso de conmutación por error, que debe coincidir con el espacio de nombres del clúster de base de datos al que se aplica.

  • DB_CLUSTER_NAME: Es el nombre del clúster de base de datos al que se realizará la conmutación por error.

Para supervisar la conmutación por error, ejecuta el siguiente comando:

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Reemplaza lo siguiente:

  • FAILOVER_NAME: Es el nombre que asignaste al recurso de conmutación por error cuando lo creaste.

  • NAMESPACE: Es el espacio de nombres del clúster de base de datos.

El comando muestra Success después de que la nueva instancia de base de datos principal está lista para usarse. Para supervisar el estado de la nueva instancia en espera, consulta la siguiente sección.

Realiza un cambio a una instancia en espera

El cambio se realiza cuando deseas probar la configuración de recuperación ante desastres o cualquier otra actividad planificada que requiera cambiar los roles de la base de datos principal y la réplica en espera.

Una vez que se completa el cambio, se invierten los roles de la instancia de base de datos principal y la réplica en espera junto con la dirección de la replicación. Debes optar por los cambios si deseas tener un mejor control sobre el proceso de prueba de la configuración de recuperación ante desastres sin pérdida de datos.

El operador de AlloyDB Omni admite el cambio manual.

El cambio genera la siguiente secuencia de eventos:

  1. El operador de AlloyDB Omni desconecta la instancia de base de datos principal.

  2. El operador de AlloyDB Omni promueve la réplica en espera para que sea la nueva instancia de base de datos principal.

  3. El operador de AlloyDB Omni cambia la instancia de base de datos principal anterior a una réplica en espera.

Realiza un cambio

Antes de realizar un cambio, asegúrate de lo siguiente:

Para realizar un cambio, crea y aplica un manifiesto para un nuevo recurso de cambio:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     NewPrimary: STANDBY_REPLICA_NAME

Reemplaza lo siguiente:

  • SWITCHOVER_NAME: Es un nombre para este recurso de cambio, por ejemplo, switchover-1.

  • DB_CLUSTER_NAME: Es el nombre de la instancia de base de datos principal a la que se aplica la operación de cambio.

  • STANDBY_REPLICA_NAME: Es el nombre de la instancia de base de datos que deseas promover como nueva principal.

    Para identificar el nombre de la réplica en espera, ejecuta el siguiente comando: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Usa la réplica en espera como una instancia de solo lectura

Para usar una réplica en espera como una instancia de solo lectura, completa los siguientes pasos:

  1. Modifica el manifiesto del clúster de base de datos para establecer el parámetro enableStandbyAsReadReplica en true.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Vuelve a aplicar el manifiesto.

  3. Verifica que el extremo de solo lectura se informe en el campo status del objeto DBCluster:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    En el siguiente ejemplo de respuesta, se muestra el extremo de la instancia de solo lectura:

      Status:
  [...]
  Primary:
    [...]
    Endpoints:
      Name: Read-Write
      Value: 10.128.0.81:5432
      Name: Read-Only
      Value: 10.128.0.82:5432