Gérer la haute disponibilité dans Kubernetes

Ce document explique comment activer et tester la haute disponibilité (HA) sur votre cluster de base de données AlloyDB Omni basé sur Kubernetes. Ce document suppose que vous disposez de connaissances de base sur l'application des fichiers manifestes Kubernetes et l'utilisation de l'outil de ligne de commande kubectl.

Présentation

Pour activer la haute disponibilité dans votre cluster de base de données, configurez l'opérateur Kubernetes AlloyDB Omni afin de créer des réplicas 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 et correspond à toutes les modifications de 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 utilise le paramètre numberOfStandbys pour spécifier le nombre de modes de veille à ajouter.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Remplacez NUMBER_OF_STANDBYS par le nombre de veilles que vous souhaitez ajouter. La valeur maximale est 5. Si vous ne savez pas combien de veilles 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 vérifier l'état de la haute disponibilité sur un cluster de base de données, vérifiez son état HAReady. Si l'état de HAReady est True, la haute disponibilité est activée et fonctionne sur le cluster. Si la valeur est False, la fonctionnalité est activée, mais pas prête, car elle est en cours de configuration.

Pour vérifier l'état de HAReady à l'aide de la ligne de commande kubectl, 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 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. Les paramètres suivants déterminent quand démarrer un basculement automatique:

  • Intervalle entre les vérifications de l'état (30 secondes par défaut)

  • Nombre de vérifications d'état consécutives échouées (par défaut, 3)

Un basculement automatique se produit après le nombre spécifié de vérifications d'état consécutives ayant échoué, avec le délai spécifié entre chaque vérification de l'état d'état ayant échoué. Si les valeurs par défaut sont conservées, un basculement automatique se produit après trois échecs de vérification de l'état consécutifs, chacun espacé de 30 secondes.

Effectuer un basculement manuel est 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.

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 nouveau 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, procédez comme suit:

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

    spec:
  availability:
    enableAutoFailover: false

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

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

L'opérateur AlloyDB Omni effectue régulièrement des vérifications de l'état de l'instance de base de données principale, ainsi que de tous les réplicas de secours. La fréquence par défaut des vérifications de l'état est de 30 secondes. Si une instance atteint le seuil de déclenchement du basculement automatique, l'opérateur AlloyDB Omni déclenche un basculement automatique.

La valeur du seuil correspond au nombre d'échecs consécutifs de la vérification de l'état'état avant qu'un basculement ne soit déclenché. Pour modifier la période de vérification de l'état de l'état ou la valeur du seuil, définissez les champs healthcheckPeriodSeconds et autoFailoverTriggerThreshold sur des valeurs entières dans le fichier manifeste du cluster:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Remplacez les éléments suivants :

  • HEALTHCHECK_PERIOD: valeur entière indiquant le nombre de secondes à attendre entre chaque vérification de l'état#39;état. La valeur par défaut est 30. La valeur minimale est 1 et la valeur maximale est 86400 (équivalent à un jour).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: valeur entière du nombre d'échecs consécutifs de la vérification de l'état'état avant qu'un basculement ne soit déclenché. La valeur par défaut est 3. La valeur minimale est 0. Il n'y a pas de valeur maximale. Si ce champ est défini sur 0, la valeur par défaut 3 est utilisée à la place.

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 la commutation terminée, le sens de la réplication et les rôles de l'instance de base de données principale et du réplica de secours sont inversés. Utilisez des commutations pour mieux contrôler les tests de votre configuration de reprise après sinistre sans perte de données.

L'opérateur AlloyDB Omni est compatible avec le transfert manuel. Un basculement entraîne 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 définit l'ancienne instance de base de données principale comme réplication de secours.

Effectuer une commutation

Avant de commencer une transition, procédez comme suit:

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:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Réparer automatiquement une instance de secours

Si une instance de secours devient indisponible, l'opérateur AlloyDB Omni répare l'instance en supprimant l'ancien réplica de secours et en créant un nouveau réplica de secours qui le remplace. Le délai par défaut pour déclencher une réparation automatique est de 90 secondes.

La réparation automatique du cluster de bases de données permet de maintenir une réplication saine et continue de la base de données principale.

Désactiver la réparation automatique de l'instance

Par défaut, la réparation automatique d'une instance de secours est activée sur les clusters de bases de données.

Pour désactiver les réparations automatiques, procédez comme suit:

  1. Dans le fichier manifeste du cluster, définissez enableAutoHeal sur false:

    spec:
  availability:
    enableAutoHeal: false

Ajuster les paramètres du déclencheur de réparation automatique

Pour chaque cluster de base de données, vous pouvez utiliser des paramètres pour ajuster les réparations automatiques.

L'opérateur AlloyDB Omni émet des vérifications d'état régulières que vous pouvez configurer. Pour en savoir plus, consultez la section Ajuster les paramètres du déclencheur de basculement automatique. Si un réplica de secours atteint le seuil de déclenchement de la réparation automatique, l'opérateur AlloyDB Omni déclenche une réparation automatique.

La valeur du seuil correspond au nombre d'échecs consécutifs de la vérification de l'état'état avant qu'une réparation ne soit déclenchée. Pour modifier la valeur du seuil, définissez autoHealTriggerThreshold dans le fichier manifeste du cluster:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Remplacez les éléments suivants :

  • AUTOHEAL_TRIGGER_THRESHOLD: valeur entière du nombre d'échecs consécutifs de la vérification de l'état'état avant qu'une réparation ne soit déclenchée. La valeur par défaut est 3. La valeur minimale est 2 en raison de possibles erreurs temporaires et ponctuelles sur les vérifications de l'état en veille.

Résoudre les problèmes de réparation des instances

Si vous utilisez un grand nombre de clusters de bases de données dans un seul cluster Kubernetes, il est possible (bien que peu probable) que la réparation automatique soit submergée. Si vous recevez une erreur commençant par HealthCheckProber: health check for instance failed et faisant référence à un délai avant expiration ou à un échec de connexion, vous pouvez essayer de limiter l'erreur en procédant comme suit:

Voici des exemples d'erreurs pouvant être causées par une réparation automatique excessive. Ces exemples omettent les détails de l'environnement qui vous aident à identifier la source de l'erreur, tels que le nom d'un cluster ou d'une adresse 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...

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. Définissez enableStandbyAsReadReplica sur true dans le fichier manifeste du cluster de bases de données:

    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