Gérer la haute disponibilité dans Kubernetes

Cette page explique comment activer et tester la haute disponibilité (HA) sur votre cluster de base de données AlloyDB Omni basé sur Kubernetes. Pour effectuer les tâches décrites ici, vous devez disposer de connaissances de base sur l'application des fichiers manifestes Kubernetes et l'utilisation de l'outil de ligne de commande kubectl.

Présentation

Vous pouvez activer la haute disponibilité dans votre cluster de base de données en demandant à l'opérateur Kubernetes AlloyDB Omni de créer des réplicas de votre instance de base de données principale. L'opérateur AlloyDB Omni configure votre cluster de base de données pour qu'il mette à jour en continu les données de ce réplica, en correspondant à toutes les modifications apportées aux données de votre instance principale.

Activer la haute disponibilité

Avant d'activer la haute disponibilité sur votre cluster de base de données, assurez-vous que votre cluster Kubernetes dispose des éléments suivants:

• Stockage de deux copies complètes de vos données
• Ressources de calcul pour deux instances de base de données exécutées en parallèle

Pour activer la HA, procédez comme suit:

1. Modifiez le fichier manifeste du cluster de base de données pour inclure une section availability sous sa section spec. Cette section définit le nombre de veilles que vous souhaitez ajouter en définissant le paramètre numberOfStandbys.

   spec:
     availability:
       numberOfStandbys: NUMBER_OF_STANDBYS
   

   Remplacez NUMBER_OF_STANDBYS par le nombre de modes de veille que vous souhaitez ajouter. La valeur maximale est 5. Si vous configurez la haute disponibilité et que vous ne savez pas combien de nœuds de secours vous avez besoin, commencez par définir la valeur sur 1 ou 2.

2. Appliquez à nouveau le fichier manifeste.

Désactiver la haute disponibilité

Pour désactiver la HA, procédez comme suit:

1. Définissez numberOfStandbys sur 0 dans le fichier manifeste du cluster:

   spec:
     availability:
       numberOfStandbys: 0
   

2. Appliquez à nouveau le fichier manifeste.

Vérifier la haute disponibilité sur un cluster de base de données

Pour afficher l'état actuel de la haute disponibilité d'un cluster de base de données, vérifiez la condition HAReady de l'état de ce cluster. Si la valeur status est définie sur True, la haute disponibilité est configurée et fonctionne sur le cluster de base de données.

Pour vérifier cette valeur dans la ligne de commande, exécutez la commande suivante:

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Remplacez les éléments suivants :

• DB_CLUSTER_NAME: nom du cluster de base de données.

• NAMESPACE: espace de noms du cluster de base de données.

Basculer vers une instance de secours

Si votre instance principale devient indisponible pendant plus de 90 secondes, l'opérateur AlloyDB Omni bascule automatiquement de l'instance de base de données principale vers l'instance de secours.

Les basculements sont une bonne option lorsque vous souhaitez rapidement récupérer après une défaillance inattendue et réduire au maximum les temps d'arrêt, même si cela implique de perdre une petite quantité de données si la base de données principale devient indisponible avant que la sauvegarde ne soit entièrement mise à jour.

L'opérateur AlloyDB Omni est compatible avec le basculement automatique et manuel. Le basculement automatique est activé par défaut.

Le basculement se produit dans la séquence d'événements suivante:

1. L'opérateur AlloyDB Omni met l'instance de base de données principale hors service.

2. L'opérateur AlloyDB Omni fait passer le réplica de secours en tant que nouvelle instance de base de données principale.

3. L'opérateur AlloyDB Omni supprime l'instance de base de données principale précédente.

4. L'opérateur AlloyDB Omni crée un réplica en attente.

Désactiver le basculement automatique

Les basculements automatiques sont activés par défaut sur les clusters de bases de données.

Pour désactiver un basculement, procédez comme suit:

1. Définissez enableAutoFailover sur false dans le fichier manifeste du cluster:

   spec:
     availability:
       enableAutoFailover: false
   

2. Appliquez à nouveau le fichier manifeste.

Déclencher un basculement manuel

Pour déclencher un basculement manuel, créez et appliquez un fichier manifeste pour une nouvelle ressource de basculement:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Remplacez les éléments suivants :

• FAILOVER_NAME: nom de cette ressource (par exemple, failover-1).

• NAMESPACE: espace de noms de cette ressource de bascule, qui doit correspondre à l'espace de noms du cluster de bases de données auquel elle s'applique.

• DB_CLUSTER_NAME: nom du cluster de base de données à transférer.

Pour surveiller le basculement, exécutez la commande suivante:

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Remplacez les éléments suivants :

• FAILOVER_NAME: nom que vous avez attribué à la ressource de basculement lorsque vous l'avez créée.

• NAMESPACE: espace de noms du cluster de base de données.

La commande renvoie Success une fois que la nouvelle instance de base de données principale est prête à l'emploi. Pour surveiller l'état de la nouvelle instance de secours, consultez la section suivante.

Passer à une instance de secours

Le basculement est effectué lorsque vous souhaitez tester votre configuration de reprise après sinistre ou toute autre activité planifiée nécessitant de changer les rôles de la base de données principale et du réplica de secours.

Une fois le basculement terminé, les rôles de l'instance de base de données principale et du réplica de secours sont inversés, ainsi que le sens de la réplication. Vous devez opter pour des transferts si vous souhaitez mieux contrôler le processus de test de votre configuration de reprise après sinistre sans perte de données.

L'opérateur AlloyDB Omni prend en charge le transfert manuel.

Le basculement se traduit par la séquence d'événements suivante:

1. L'opérateur AlloyDB Omni met l'instance de base de données principale hors service.

2. L'opérateur AlloyDB Omni fait passer le réplica de secours en tant que nouvelle instance de base de données principale.

3. L'opérateur AlloyDB Omni bascule l'instance de base de données principale précédente vers un réplica de secours.

Remarque :Vous pouvez configurer un réplica de secours pour qu'il soit utilisé en tant qu'instance en lecture seule. Pour en savoir plus, consultez Utiliser une instance de secours en tant qu'instance en lecture seule

.

Effectuer une commutation

Avant de procéder à un transfert, vérifiez les points suivants:

• Vérifiez que l'instance de base de données principale et le réplica de secours sont tous deux opérationnels. Pour en savoir plus, consultez Gérer et surveiller AlloyDB Omni.
• Vérifiez que l'état actuel de la haute disponibilité est HAReady. Pour en savoir plus, consultez Vérifier la haute disponibilité sur un cluster de bases de données.

Pour effectuer un transfert, créez et appliquez un fichier manifeste pour une nouvelle ressource de transfert:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     NewPrimary: STANBDY_REPLICA_NAME

Remplacez les éléments suivants :

• SWITCHOVER_NAME: nom de cette ressource de basculement (par exemple, switchover-1)

• DB_CLUSTER_NAME: nom de l'instance de base de données principale à laquelle l'opération de basculement s'applique.

• STANBDY_REPLICA_NAME: nom de l'instance de base de données que vous souhaitez promouvoir en tant que nouvelle instance principale.

  Pour identifier le nom du réplica de secours, exécutez la commande suivante : posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Important :Les sauvegardes locales effectuées avant le transfert ne peuvent pas être restaurées automatiquement à l'aide de la ressource personnalisée Restore. Si vous souhaitez cloner manuellement la sauvegarde, consultez Cloner un cluster de base de données dans Kubernetes à l'aide d'une sauvegarde locale.

Utiliser un réplica en attente comme instance en lecture seule

Pour utiliser un réplica en attente en tant qu'instance en lecture seule, procédez comme suit:

1. Modifiez le fichier manifeste du cluster de bases de données pour définir le paramètre enableStandbyAsReadReplica sur true.

   spec:
     availability:
       enableStandbyAsReadReplica: true
   

2. Appliquez à nouveau le fichier manifeste.

3. Vérifiez que le point de terminaison en lecture seule est indiqué dans le champ status de l'objet DBCluster:

   kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

   L'exemple de réponse suivant affiche le point de terminaison de l'instance en lecture seule:

     Status:
     [...]
     Primary: 
       [...]
       Endpoints:
         Name: Read-Write
         Value: 10.128.0.81:5432
         Name: Read-Only
         Value: 10.128.0.82:5432