Administra la alta disponibilidad en Kubernetes

En este documento, se muestra cómo habilitar y probar la alta disponibilidad (HA) en tu clúster de bases 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 bases 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 bases de datos para que actualice de forma continua los datos de 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 el clúster de bases de datos, asegúrate de que el 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 HA, sigue estos pasos:

1. Modifica el manifiesto del clúster de bases 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 copias de seguridad que deseas agregar. El valor máximo es 5. Si no sabes con exactitud la cantidad de esperas 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 HA en un clúster de bases de datos

Para verificar el estado de la HA en un clúster de bases de datos, verifica su estado HAReady. Si el estado de HAReady es True, la HA está habilitada y funciona en el clúster. Si es False, significa que está habilitado, pero no está 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 bases de datos.

• NAMESPACE: Es el espacio de nombres del clúster de bases 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 una conmutación por error automática de la instancia de base de datos principal a la instancia en espera. Los siguientes parámetros determinan cuándo iniciar un resguardo automático:

• Es 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)

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

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

2. El operador de AlloyDB Omni promueve la réplica de reserva 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 réplica de reserva nueva.

Inhabilita la conmutación por error automática

Los resguardos automáticos están habilitados de forma predeterminada en los clústeres de bases de datos.

Para inhabilitar un resguardo, 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 los resguardos automáticos para cada clúster de bases de datos.

El operador de AlloyDB Omni emite verificaciones de estado regulares a la instancia de base de datos principal y a todas las réplicas en espera. La frecuencia predeterminada de las verificaciones 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 del umbral es la cantidad de fallas consecutivas de la verificación de estado antes de que se active la 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: Es un valor entero para la cantidad de fallas consecutivas de 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 bases de datos al que se aplica.

• DB_CLUSTER_NAME: Es el nombre del clúster de bases de datos que fallará.

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 asignaste al recurso de resguardo cuando lo creaste.

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

El comando muestra Success después de que la nueva instancia de base de datos principal esté lista para su uso. Para supervisar el estado de la nueva instancia de reserva, consulta la siguiente sección.

Cómo realizar el cambio a una instancia de 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 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 el cambio manual. Un cambio genera la siguiente secuencia de eventos:

1. El operador de AlloyDB Omni desconecta la instancia principal de la base de datos.

2. El operador de AlloyDB Omni promueve la réplica de reserva 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.

Nota: Puedes configurar una réplica de Standby para que se use como instancia de solo lectura. Para obtener más información, consulta Cómo usar un dispositivo en modo de espera como instancia de solo lectura.

Realiza un cambio

Antes de comenzar un cambio, haz lo siguiente:

• Verifica que la instancia principal de la base de datos y la réplica en espera estén en buen estado. Para obtener más información, consulta Administra y supervisa AlloyDB Omni.

• Verifica que el estado actual de la HA esté en la condición HAReady. Para obtener más información, consulta Cómo verificar la HA en un clúster de bases de datos.

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: STANBDY_REPLICA_NAME

Reemplaza lo siguiente:

• SWITCHOVER_NAME: Es 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.

• STANBDY_REPLICA_NAME: Es el nombre de la instancia de la base de datos que deseas promocionar para que sea la nueva instancia principal.

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

  kubectl get instances.alloydbomni.internal.dbadmin.goog

Importante: Si se crean copias de seguridad locales antes de que se realice la migración, no podrás restablecerlas con el recurso personalizado Restore. Si deseas clonar manualmente la copia de seguridad, consulta Cómo clonar un clúster de bases de datos en Kubernetes con una copia de seguridad local.

Repara una instancia de reserva automáticamente

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

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

Inhabilita la recuperación automática de la instancia

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

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

1. En el manifiesto del clúster, establece 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 bases de datos, puedes usar la configuración para ajustar las correcciones 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 del activador de restablecimiento automático, el operador de AlloyDB Omni activa un restablecimiento automático.

El valor del umbral es la cantidad de fallas consecutivas de la verificación de estado antes de que se active una recuperació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 para la cantidad de fallas consecutivas de la verificación de estado antes de que se active una recuperación. El valor predeterminado es 3. El valor mínimo es 2 debido a posibles errores transitorios y únicos en las verificaciones de estado en espera.

Soluciona problemas de restablecimiento de instancias

Si usas una gran cantidad de clústeres de bases de datos en un solo clúster de Kubernetes, es posible (aunque poco probable) que se abarrote la curación automática. Si recibes un error que comienza con HealthCheckProber: health check for instance failed y hace referencia a un tiempo de espera o una falla de conexión, puedes intentar mitigar el error de la siguiente manera:

• Reduce la cantidad de clústeres de bases de datos que administras en tu clúster de Kubernetes.

• Aumenta el valor del umbral healthcheckPeriodSeconds para que las verificaciones de estado ocurran con menos frecuencia. Para obtener más información, consulta Cómo ajustar la configuración del activador de conmutación por error automática.

• Aumenta el límite de CPU, el límite de memoria o ambos para el operador de AlloyDB Omni. Para obtener más información, consulta Acerca de la administración automática de la memoria y Cómo analizar el uso del montón de memoria del operador de AlloyDB Omni.

Los siguientes son ejemplos de errores que pueden deberse a una correcció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 de resguardo como una instancia de solo lectura

Para usar una réplica de resguardo como una instancia de solo lectura, completa los siguientes pasos:

1. Establece enableStandbyAsReadReplica como true en el manifiesto del clúster de bases 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 la siguiente respuesta de ejemplo, 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