Administra 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 de AlloyDB Omni basado en Kubernetes. En este documento, se supone que tienes conocimientos básicos sobre la aplicación de archivos de manifiesto de Kubernetes y el uso de la herramienta de línea de comandos de kubectl.

Descripción general

Para habilitar la HA en tu clúster de base de datos, debes configurar el operador de Kubernetes de AlloyDB Omni para 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 y coincida con todos los cambios de datos en 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 usa el parámetro numberOfStandbys para especificar la cantidad de copias de seguridad que se agregarán.

    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 no sabes cuántos suplentes 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 verificar el estado de la HA en un clúster de base de datos, consulta su estado HAReady. Si el estado de HAReady es True, la alta disponibilidad está habilitada y funciona en el clúster. Si es False, está habilitado, pero no listo porque está en proceso de configuración.

Para verificar el estado de HAReady con la línea de comandos de kubectl, 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. Los siguientes parámetros determinan cuándo iniciar una conmutación por error automática:

  • El tiempo entre las verificaciones de estado (el valor predeterminado es de 30 segundos)

  • Cantidad de verificaciones de estado consecutivas fallidas (el valor predeterminado es 3)

La conmutación por error automática comienza después de que se produce la cantidad especificada de comprobaciones de estado fallidas consecutivas, con el tiempo especificado entre cada verificación de estado fallida. Si se conservan los valores predeterminados, se produce una conmutación por error automática después de 3 fallas consecutivas en la verificación de estado, cada una con un intervalo de 30 segundos.

Realizar una conmutación por error manual es una buena opción cuando deseas recuperarte rápidamente de una falla inesperada 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 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 la conmutación por error automática, 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 para la instancia de base de datos principal y para todas las réplicas en espera. La frecuencia predeterminada para las verificaciones de estado es de 30 segundos. Si una instancia alcanza el umbral de activación de conmutación por error automática, el operador de AlloyDB Omni activa una conmutación por error automática.

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 período de verificación de estado o el valor de umbral, establece los campos healthcheckPeriodSeconds y autoFailoverTriggerThreshold en valores enteros en el manifiesto del clúster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Reemplaza lo siguiente:

  • HEALTHCHECK_PERIOD: Es un valor entero que indica la cantidad de segundos que se deben esperar entre cada verificación de estado. El valor predeterminado es 30. El valor mínimo es 1 y el valor máximo es 86400 (equivalente a un día).

  • AUTOFAILOVER_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. El valor mínimo es 0. No hay un valor máximo. Si este campo se establece en 0, se usa el valor predeterminado de 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 invierte la dirección de la replicación y los roles de la instancia de la base de datos principal y la réplica en espera. Usa los cambios para obtener más control sobre las pruebas 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. Un 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 para que sea una réplica en espera.

Realiza un cambio

Antes de comenzar un cambio, haz lo siguiente:

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

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 la nueva instancia principal.

    Para identificar el nombre de la réplica en espera, ejecuta el siguiente comando:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Repara una instancia en espera automáticamente

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

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

Inhabilita la reparación automática de la instancia

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

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

  1. En el manifiesto del clúster, configura enableAutoHeal como false:

    spec:
  availability:
    enableAutoHeal: false

Cómo ajustar la configuración del activador de reparación automática

Para cada clúster de base de datos, puedes usar la configuración para ajustar las reparaciones automáticas.

El operador de AlloyDB Omni emite verificaciones de estado periódicas que puedes configurar. Para obtener más información, consulta Cómo 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 reparación automática, el operador de AlloyDB Omni activa una reparación automática.

El valor del umbral es la cantidad de fallas consecutivas para la verificación de estado antes de que se active la reparación. Para cambiar el valor del umbral, establece autoHealTriggerThreshold en el manifiesto del clúster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Reemplaza lo siguiente:

  • AUTOHEAL_TRIGGER_THRESHOLD: Es un valor entero que indica la cantidad de fallas consecutivas en la verificación de estado antes de que se active la reparación. El valor predeterminado es 5. El valor mínimo es 2 debido a posibles errores transitorios y únicos en las verificaciones de estado en espera.

Soluciona problemas de reparación de instancias

Si usas una gran cantidad de clústeres de bases de datos en un solo clúster de Kubernetes o si tienes clústeres de bases de datos con capacidad insuficiente, la reparación automática podría causar la no disponibilidad del operador de AlloyDB Omni o de los clústeres de bases de datos. Si recibes un error que comienza con HealthCheckProber: health check for instance failed y hace referencia a un tiempo de espera o a una falla en la conexión, prueba las siguientes correcciones recomendadas:

A continuación, se muestran ejemplos de errores que pueden deberse a la recuperació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...

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

    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