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 cómo aplicar archivos de manifiesto de Kubernetes y usar la herramienta de línea de comandos kubectl.

Descripción general

Para habilitar la HA en tu clúster de base de datos, configura el operador de Kubernetes de AlloyDB Omni para crear 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 y coincide con todos los cambios de datos en tu instancia principal.

También puedes habilitar la HA en tu clúster de base de datos habilitado para TDE. Para obtener más información sobre cómo crear un clúster habilitado para TDE, consulta Crea un clúster habilitado para TDE.

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. Esta sección usa el parámetro numberOfStandbys para especificar la cantidad de instancias en espera que se agregarán.

    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 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 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 HA está habilitada y funciona en el clúster. Si es False, está habilitada, pero no está lista porque está en proceso de configuración.

Para verificar el estado 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

Reemplaza lo siguiente:

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

  • NAMESPACE: el espacio de nombres del clúster de 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 conmuta por error automáticamente 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)

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

Se inicia una conmutación por error automática después de que se produce la cantidad especificada de verificaciones de estado consecutivas fallidas, 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 de verificación de estado que están separadas por 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 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 la conmutación por error automática, sigue estos pasos:

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

    spec:
  availability:
    enableAutoFailover: false

Ajusta 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 para cada clúster de base de datos.

El operador de AlloyDB Omni emite verificaciones de estado periódicas a la instancia de base de datos principal, así como a todas las réplicas en espera. La frecuencia predeterminada para las verificaciones de estado es de 30 segundos. Si una instancia alcanza el umbral del activador 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 para 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 del 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: 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: un valor entero para la cantidad de fallas consecutivas para 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: un nombre para 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 base de datos al que se aplica.

  • DB_CLUSTER_NAME: el nombre del clúster de base de datos al que se conmutará 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: el nombre que asignaste al recurso de conmutación por error cuando lo creaste.

  • NAMESPACE: 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.

Cambia 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 base de datos principal y la réplica en espera. Usa los cambios para obtener más control sobre la prueba de la configuración de recuperación ante desastres sin pérdida de datos.

El operador de AlloyDB Omni admite el cambio manual. Un 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 para que sea una réplica en espera.

Realiza un cambio

Antes de comenzar 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

Reemplaza lo siguiente:

  • 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 deseas promover para que sea la nueva 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 réplica en espera que la reemplace. El tiempo predeterminado para activar una reparación automática es de 90 segundos.

La reparación automática del clúster de 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 base de datos.

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

  1. En el manifiesto del clúster, establece enableAutoHeal en false:

    spec:
  availability:
    enableAutoHeal: false

Ajusta 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 Ajusta la configuración del activador de conmutación por error automática. Si una réplica en espera alcanza el umbral del activador 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 una 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: un valor entero para la cantidad de fallas consecutivas para la verificació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 únicos en las verificaciones de estado en espera.

Soluciona problemas de reparación de instancias

Si usas una gran cantidad de clústeres de base de datos en un solo clúster de Kubernetes o si tienes clústeres de base de datos con recursos insuficientes, la reparación automática puede causar falta de disponibilidad para el operador de AlloyDB Omni o los clústeres de base de datos. Si recibes un error que comienza con HealthCheckProber: health check for instance failed y el error hace referencia a un tiempo de espera agotado o a una falla de conexión, prueba las siguientes correcciones recomendadas:

A continuación, se muestran ejemplos de errores que pueden deberse a una reparación automática abrumadora. 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 una instancia de solo lectura, completa los siguientes pasos:

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