Gestionar la alta disponibilidad en Kubernetes

Selecciona una versión de la documentación:

En esta página se describe cómo habilitar y probar la alta disponibilidad (HA) en tu clúster de base de datos AlloyDB Omni basado en Kubernetes. En este documento se presupone que tienes 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

Para habilitar la alta disponibilidad en tu clúster de base de datos, configura el operador de AlloyDB Omni Kubernetes para 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 y coincida con todos los cambios de 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 usa el parámetro numberOfStandbys para especificar el número de elementos de reserva que se van a añadir.

    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 no sabes cuántas copias de seguridad necesitas, empieza asignando el valor 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 comprobar el estado de la alta disponibilidad en un clúster de bases de datos, consulta su HAReady. Si el estado de HAReady es True, significa que la alta disponibilidad está habilitada y funciona en el clúster. Si es False, significa que está habilitada, pero no lista porque se está configurando.

Para comprobar el estado de HAReady con la línea de comandos kubectl, 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 de tiempo configurable, el operador de AlloyDB Omni pasará automáticamente de la instancia de base de datos principal a la de espera. Los siguientes parámetros determinan cuándo se debe iniciar una conmutación por error automática:

  • El tiempo entre comprobaciones del estado (el valor predeterminado es 30 segundos).

  • Número de comprobaciones del estado fallidas consecutivas (el valor predeterminado es 3).

Una conmutación por error automática se inicia después de que se produzca el número especificado de comprobaciones del estado fallidas consecutivas, con el tiempo especificado entre cada comprobación del estado fallida. Si se conservan los valores predeterminados, se produce una conmutación por error automática después de 3 fallos consecutivos de comprobación del estado con un intervalo de 30 segundos entre ellos.

Realizar una conmutación por error manual es una buena opción cuando quieres recuperarte rápidamente de un fallo inesperado y minimizar el tiempo de inactividad.

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 de AlloyDB Omni convierte la réplica de espera en la nueva instancia de base de datos principal.

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

  4. El operador de 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 la conmutación por error automática, 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 a la instancia de base de datos principal, así como a todas las réplicas de espera. La frecuencia predeterminada de las comprobaciones de estado es de 30 segundos. Si una instancia alcanza 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 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 periodo de comprobación del estado o el valor de umbral, asigna valores enteros a los campos healthcheckPeriodSeconds y autoFailoverTriggerThreshold en el manifiesto del clúster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Haz los cambios siguientes:

  • HEALTHCHECK_PERIOD: valor entero que indica el número de segundos que deben transcurrir entre cada comprobación del estado. El valor predeterminado es 30. El valor mínimo es 1 y el máximo es 86400 (equivalente a un día).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: un valor entero que indica el número de errores consecutivos de la comprobación de estado antes de que se active una conmutación por error. El valor predeterminado es 3. El valor mínimo es 0. No hay ningún valor máximo. Si este campo se define como 0, se usará el valor predeterminado 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 la dirección de la replicación y los roles de la instancia de base de datos principal y de la réplica de espera. Usa los cambios para tener más control sobre las pruebas de tu configuración de recuperación ante desastres sin perder datos.

El operador AlloyDB Omni admite el cambio manual. Un cambio provoca 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 de 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 iniciar un cambio, haz 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

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:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Reparar una instancia de espera automáticamente

Si una instancia de espera deja de estar disponible, el operador de AlloyDB Omni la corrige eliminando la réplica de espera antigua y creando una nueva réplica de espera que la sustituya. El tiempo predeterminado para activar una reparación automática es de 90 segundos.

La reparación automática del clúster de bases de datos ayuda a mantener una replicación continua y correcta de la base de datos principal.

Inhabilitar la reparación automática de la instancia

De forma predeterminada, la reparación automática de una instancia de espera está habilitada en los clústeres de bases de datos.

Para inhabilitar las reparaciones automáticas, sigue estos pasos:

  1. En el archivo de manifiesto del clúster, asigna el valor false a enableAutoHeal:

    spec:
  availability:
    enableAutoHeal: false

Ajustar la configuración del activador de recuperación automática

En cada clúster de bases de datos, puedes usar ajustes para modificar las reparaciones automáticas.

El operador de AlloyDB Omni emite comprobaciones del estado periódicas que puedes configurar. Para obtener más información, consulta Ajustar la configuración del activador de conmutación por error automática. Si una réplica en espera alcanza el umbral de activación de la reparación automática, el operador de AlloyDB Omni activa una reparación automática.

El valor de umbral es el número de errores consecutivos de la comprobación del estado antes de que se active una reparación. Para cambiar el valor del umbral, define autoHealTriggerThreshold en el manifiesto del clúster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Haz los cambios siguientes:

  • AUTOHEAL_TRIGGER_THRESHOLD: un valor entero que indica el número de errores consecutivos de la comprobación de estado antes de que se active una reparación. El valor predeterminado es 5. El valor mínimo es 2 debido a posibles errores transitorios y puntuales en las comprobaciones de estado de espera.

Solucionar problemas de reparación de instancias

Si usas un gran número de clústeres de bases de datos en un solo clúster de Kubernetes o si tienes clústeres de bases de datos con pocos recursos aprovisionados, la reparación automática puede provocar que el operador de AlloyDB Omni o los clústeres de bases de datos no estén disponibles. Si recibes un error que empieza por HealthCheckProber: health check for instance failed y hace referencia a un tiempo de espera agotado o a un fallo de conexión, prueba las siguientes soluciones recomendadas:

A continuación, se indican ejemplos de errores que pueden deberse a una corrección automática excesiva. En estos ejemplos se omiten los detalles del entorno que te ayudan a identificar la fuente del error, como el nombre de un clúster o una dirección IP.

  • HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...

  • HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

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. Asigna el valor true a enableStandbyAsReadReplica en el archivo de manifiesto del clúster de la base de datos:

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Vuelve a aplicar el archivo de manifiesto.

  3. Comprueba 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