Gérer la haute disponibilité dans Kubernetes

Sélectionnez une version de la documentation :

Cette page vous explique comment activer et tester la haute disponibilité (HD) sur votre cluster de base de données AlloyDB Omni basé sur Kubernetes. Pour effectuer les tâches décrites ici, vous devez avoir des 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 bases de données en demandant à l'opérateur Kubernetes AlloyDB Omni de créer des répliques de secours de votre instance de base de données principale. L'opérateur AlloyDB Omni configure votre cluster de base de données pour mettre à jour en continu les données de ce réplica, en les alignant sur 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 bases de données, assurez-vous que votre cluster Kubernetes possède les éléments suivants :

  • Espace de stockage pour deux copies complètes de vos données
  • Ressources de calcul pour deux instances de base de données s'exécutant en parallèle

Pour activer la haute disponibilité :

  1. Modifiez le fichier manifeste du cluster de bases de données pour inclure une section availability sous sa section spec. Cette section définit le nombre de serveurs de secours 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 serveurs de secours que vous souhaitez ajouter. La valeur maximale est de 5. Si vous configurez la haute disponibilité et que vous ne savez pas combien de serveurs de secours sont nécessaires, 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 haute disponibilité :

  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 bases de données

Pour afficher l'état actuel de la haute disponibilité d'un cluster de bases de données, vérifiez la condition HAReady de l'état de ce cluster. Si cette valeur est définie sur True pour status, cela signifie que la haute disponibilité est configurée et fonctionne sur le cluster de bases 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 bases de données.

Basculer vers une instance de secours

Si votre instance principale devient indisponible pendant une période configurable, l'opérateur AlloyDB Omni bascule automatiquement de l'instance de base de données principale vers l'instance de secours. Le délai par défaut pour déclencher le basculement automatique est de 90 secondes.

Les basculements sont une bonne option lorsque vous souhaitez récupérer rapidement après une défaillance inattendue et minimiser les temps d'arrêt, même si cela signifie potentiellement 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 entraîne la séquence d'événements suivante :

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

  2. L'opérateur AlloyDB Omni promeut la réplique 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 de secours.

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 :

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

    spec:
  availability:
    enableAutoFailover: false

Ajuster les paramètres de déclenchement du basculement automatique

Vous pouvez utiliser les paramètres pour ajuster les basculements automatiques pour chaque cluster de bases de données.

L'opérateur AlloyDB Omni effectue des vérifications régulières de l'état toutes les 30 secondes. Si une instance a atteint le seuil de déclenchement du basculement automatique, l'opérateur AlloyDB Omni déclenche un basculement automatique.

La valeur par défaut du seuil de déclenchement du basculement automatique est 3. La valeur seuil correspond au nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'un basculement. Pour modifier la valeur du seuil, définissez autoFailoverTriggerThreshold sur une valeur entière dans le fichier manifeste du cluster :

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

Remplacez les éléments suivants :

  • TRIGGER_THRESHOLD : valeur entière correspondant au nombre d'échecs consécutifs de la vérification de l'état'état avant le déclenchement d'un basculement. La valeur par défaut est 3.

Déclencher un basculement manuel

Pour déclencher un basculement manuel, créez et appliquez un 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 basculement, 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 bases de données pour lequel effectuer le basculement.

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 lors de sa création.

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

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

Basculer vers une instance de secours

La commutation est effectuée lorsque vous souhaitez tester votre configuration de reprise après sinistre ou toute autre activité planifiée nécessitant d'inverser les rôles de la base de données principale et de la réplique de secours.

Une fois le basculement terminé, les rôles de l'instance de base de données principale et de la réplique de secours sont inversés, tout comme le sens de la réplication. Vous devez opter pour les commutations 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 est compatible avec le basculement manuel.

Le basculement entraîne la séquence d'événements suivante :

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

  2. L'opérateur AlloyDB Omni promeut la réplique de secours en tant que nouvelle instance de base de données principale.

  3. L'opérateur AlloyDB Omni bascule l'ancienne instance de base de données principale vers une réplique de secours.

.

Effectuer une commutation

Avant d'effectuer une permutation, assurez-vous des points suivants :

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

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

Remplacez les éléments suivants :

  • SWITCHOVER_NAME : nom de cette ressource de bascule, par exemple switchover-1.

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

  • STANDBY_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 de la réplique de secours, exécutez la commande suivante : posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Utiliser une instance répliquée de secours comme instance en lecture seule

Pour utiliser une réplique de secours comme 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 montre 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