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 requiere un conocimiento básico sobre cómo aplicar archivos de manifiesto de Kubernetes y usar 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 que actualice continuamente los datos en esta réplica, de modo que coincidan 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 bases de datos que se ejecutan en paralelo

Para habilitar la HA, sigue estos pasos:

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

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

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

  2. Vuelve a aplicar el manifiesto.

Inhabilita la HA

Para inhabilitar la HA, sigue estos pasos:

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

    spec:
  availability:
    numberOfStandbys: 0

  2. Vuelve a aplicar el manifiesto.

Verifica la alta disponibilidad en un clúster de base de datos

Para ver el estado actual de alta disponibilidad 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 bases 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 la base de datos.

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

Conmuta por error a una instancia en espera

Si tu instancia principal deja de estar disponible durante un período configurable, 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. El tiempo predeterminado para activar la conmutación por error automática es de 90 segundos.

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 se actualice por completo la copia de seguridad.

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 la 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 bases de datos.

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

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

    spec:
  availability:
    enableAutoFailover: false

Cómo ajustar la configuración del activador de conmutación por error automática

Puedes usar la configuración para ajustar las conmutaciones por error automáticas de cada clúster de base de datos.

El operador de AlloyDB Omni emite verificaciones de estado periódicas cada 30 segundos. Si una instancia alcanzó el umbral de activación de la conmutación por error automática, el operador de AlloyDB Omni activa una conmutación por error automática.

El valor predeterminado para el umbral de activación de la conmutación por error automática es 3. El valor del umbral es la cantidad de fallas consecutivas de la verificación de estado antes de que se active una conmutación por error. Para cambiar el valor del umbral, establece autoFailoverTriggerThreshold en un valor entero en el manifiesto del clúster:

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

Reemplaza lo siguiente:

  • TRIGGER_THRESHOLD: Es un valor entero que indica la cantidad de fallas consecutivas en la verificación de estado antes de que se active una conmutación por error. El valor predeterminado es 3.

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 de 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 le asignaste al recurso de conmutación por error cuando lo creaste.

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

El comando devuelve 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.

Conmutación por error 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 tu configuración de recuperación ante desastres sin pérdida de datos.

El operador de AlloyDB Omni admite la conmutación por error manual.

El cambio genera la siguiente secuencia de eventos:

  1. El operador de AlloyDB Omni desconecta la instancia de la 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 cumplir con los siguientes requisitos:

Para realizar una conmutación, crea y aplica un manifiesto para un recurso de conmutación nuevo:

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 conmutación, 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 conmutación por error.

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

    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 instancia de solo lectura, completa los siguientes pasos:

  1. Modifica el manifiesto del clúster de la 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 endpoint 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