Administra la alta disponibilidad en Kubernetes

En esta página, 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. Para realizar las tareas documentadas aquí, se requieren 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 AD en tu clúster de bases de datos, dirige al operador de Kubernetes de AlloyDB Omni a crear réplicas de reserva 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, lo que coincide con todos los cambios en los datos de 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 define la cantidad de esperas que deseas agregar configurando el parámetro numberOfStandbys.

   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 estás configurando HA y no sabes con certeza la cantidad de unidades de reserva 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 ver el estado actual de la HA de un clúster de bases de datos, verifica la condición HAReady del estado de ese clúster. Si este valor tiene un status establecido en True, la HA está configurada y funciona en el clúster de bases de datos.

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

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 más de 90 segundos, 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.

Las conmutaciones por error son una buena opción cuando deseas recuperarte rápidamente de una falla inesperada y minimizar el tiempo de inactividad, incluso si eso significa perder una pequeña cantidad de datos si la base de datos principal deja de estar disponible antes de que la copia de seguridad se actualice por completo.

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

2. Vuelve a aplicar el manifiesto.

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, los roles de la instancia de la base de datos principal y la réplica en espera se invierten junto con la dirección de la replicación. Debes optar por los cambios si deseas tener un mejor control sobre el proceso de prueba de tu configuración de recuperación ante desastres sin pérdida de datos.

El operador de AlloyDB Omni admite el cambio manual.

El 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 a 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 estado de espera como una instancia de solo lectura

Realiza un cambio

Antes de realizar un cambio, asegúrate de lo siguiente:

• Verifica que la instancia de la base de datos principal 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 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 cambio.

• STANBDY_REPLICA_NAME: El nombre de la instancia de base de datos que deseas promocionar como nueva principal.

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

Importante: Las copias de seguridad locales que se hayan tomado antes de realizar la migración no se pueden restablecer automáticamente con el recurso personalizado Restore. Si deseas clonar la copia de seguridad de forma manual, consulta Clona un clúster de bases de datos en Kubernetes con una copia de seguridad local.

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. Modifica el manifiesto del clúster de bases de datos para establecer el parámetro enableStandbyAsReadReplica en true.

   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