Gestionar la alta disponibilidad en Kubernetes

Selecciona una versión de la documentación:

En esta página se explica cómo habilitar y probar la alta disponibilidad (HA) en tu clúster de base de datos AlloyDB Omni basado en Kubernetes. Para llevar a cabo las tareas que se describen en este artículo, debes tener conocimientos básicos sobre cómo aplicar archivos de manifiesto de Kubernetes y usar la herramienta de línea de comandos kubectl.

Información general

Puedes habilitar la alta disponibilidad en tu clúster de base de datos indicando al operador de AlloyDB Omni Kubernetes que cree réplicas de 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 de esta réplica, de forma que coincidan con todos los cambios que se produzcan en los datos de tu instancia principal.

Habilitar alta disponibilidad

Antes de habilitar la alta disponibilidad 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 computación de dos instancias de bases de datos que se ejecutan en paralelo

Para habilitar la alta disponibilidad, sigue estos pasos:

  1. Modifique el archivo de manifiesto del clúster de base de datos para incluir una sección availability en la sección spec. En esta sección se define el número de elementos de reserva que quieres añadir configurando el parámetro numberOfStandbys.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Sustituye NUMBER_OF_STANDBYS por el número de copias de seguridad que quieras añadir. El valor máximo es 5. Si vas a configurar la alta disponibilidad y no sabes cuántos elementos de reserva necesitas, empieza configurando el valor en 1 o 2.

  2. Vuelve a aplicar el archivo de manifiesto.

Inhabilitar alta disponibilidad

Para inhabilitar la alta disponibilidad, sigue estos pasos:

  1. Asigna el valor 0 a numberOfStandbys en el archivo de manifiesto del clúster:

    spec:
  availability:
    numberOfStandbys: 0

  2. Vuelve a aplicar el archivo de manifiesto.

Verificar la alta disponibilidad en un clúster de bases de datos

Para ver el estado de alta disponibilidad actual de un clúster de bases de datos, consulta la HAReadycondición del estado de ese clúster. Si este valor tiene un status definido como True, la alta disponibilidad se ha configurado y funciona en el clúster de bases de datos.

Para comprobar 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

Haz los cambios siguientes:

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

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

Conmutar por error a una instancia de espera

Si tu instancia principal no está disponible durante un periodo configurable, el operador de AlloyDB Omni conmutará automáticamente por error de la instancia de base de datos principal a la instancia de 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 si quieres recuperarte rápidamente de un error inesperado y minimizar el tiempo de inactividad, aunque eso suponga perder una pequeña cantidad de datos, en caso de que la base de datos principal no esté 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 da lugar a la siguiente secuencia de eventos:

  1. El operador de AlloyDB Omni pone sin conexión la instancia de base de datos principal.

  2. El operador AlloyDB Omni convierte la réplica de espera en la nueva instancia de base de datos principal.

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

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

Inhabilitar 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. Asigna el valor false a enableAutoFailover en el archivo de manifiesto del clúster:

    spec:
  availability:
    enableAutoFailover: false

Ajustar la configuración del activador de conmutación por error automática

Puedes usar los ajustes para modificar las conmutaciones por error automáticas de cada clúster de bases de datos.

El operador de AlloyDB Omni emite comprobaciones de estado periódicas cada 30 segundos. Si una instancia ha alcanzado 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 del umbral de activación de la conmutación por error automática es 3. El valor de umbral es el número de fallos consecutivos de la comprobación del estado antes de que se active una conmutación por error. Para cambiar el valor del umbral, asigna a autoFailoverTriggerThreshold un valor entero en el manifiesto del clúster:

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

Haz los cambios siguientes:

  • TRIGGER_THRESHOLD: un valor entero que indica el número de fallos consecutivos de la comprobación de estado antes de que se active la conmutación por error. El valor predeterminado es 3.

Activar 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

Haz los cambios siguientes:

  • FAILOVER_NAME: el nombre de este recurso. Por ejemplo, failover-1.

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

  • DB_CLUSTER_NAME: el nombre del clúster de base de datos al que se va a hacer failover.

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

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

Haz los cambios siguientes:

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

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

El comando devuelve Success cuando la nueva instancia de base de datos principal está lista para usarse. Para monitorizar el estado de la nueva instancia de espera, consulta la siguiente sección.

Conmutación por error a una instancia de reserva

La conmutación se realiza cuando quieres probar la configuración de recuperación tras desastres o cualquier otra actividad planificada que requiera cambiar los roles de la base de datos principal y la réplica de espera.

Una vez completado el cambio, se invierten los roles de la instancia de base de datos principal y de la réplica de espera, así como la dirección de la replicación. Debes optar por los cambios si quieres tener un mayor control sobre el proceso de prueba de tu configuración de recuperación tras fallos sin perder datos.

El operador AlloyDB Omni admite el cambio manual.

El cambio da lugar a la siguiente secuencia de eventos:

  1. El operador de AlloyDB Omni pone sin conexión la instancia de base de datos principal.

  2. El operador AlloyDB Omni convierte la réplica de espera en la nueva instancia de base de datos principal.

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

.

Hacer un cambio

Antes de realizar un cambio, asegúrate de que se cumplan los siguientes requisitos:

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

Haz los cambios siguientes:

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

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

  • STANDBY_REPLICA_NAME: el nombre de la instancia de base de datos que quieres convertir en la nueva principal.

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

Usar una réplica de espera como instancia de solo lectura

Para usar una réplica en espera como instancia de solo lectura, sigue estos pasos:

  1. Modifica el manifiesto del clúster de bases de datos para definir el parámetro enableStandbyAsReadReplica como true.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Vuelve a aplicar el archivo de manifiesto.

  3. Verifica que el endpoint de solo lectura se haya indicado 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