Mettre à niveau la version mineure de la base de données pour AlloyDB Omni sur Kubernetes

Sélectionnez une version de la documentation :

Cette page explique comment mettre à niveau la version mineure de base de données pour AlloyDB Omni sur Kubernetes.

Pour mettre à niveau la version mineure d'une base de données, vous avez deux options :

  • Mise à niveau avec temps d'arrêt réduit : pour les environnements haute disponibilité (HA) exécutant AlloyDB Omni version 15.7.1 ou ultérieure, AlloyDB Omni met d'abord à niveau vos instances de secours. L'opérateur AlloyDB Omni effectue ensuite un basculement, en promouvant l'une des instances de secours mises à niveau pour qu'elle devienne votre nouvelle instance principale. Une fois le basculement réussi, votre ancienne instance principale est mise à jour.

    Ce processus garantit un temps d'arrêt minimal lors de la mise à niveau.

  • Mise à niveau simultanée : dans tous les autres cas, l'opérateur AlloyDB Omni met à niveau toutes les instances simultanément. Cela signifie que vous subirez un temps d'arrêt lors de la mise à niveau.

Limites

Pour les mises à niveau avec un temps d'arrêt réduit, une instance de secours n'est pas disponible à tout moment. Pour vous assurer que votre cluster de bases de données n'atteint pas un objectif de point de récupération (RPO) nul et ne risque pas de perdre des données, il doit comporter une instance principale et au moins deux instances de secours.

Avant de commencer

  • Si votre cluster est à haute disponibilité et que la version d'AlloyDB Omni est antérieure à la version 15.7.1, suivez les étapes décrites dans Mettre à jour les clusters de bases de données avant de suivre cette procédure de mise à niveau de la version mineure.
  • Identifiez une période de faible trafic pendant laquelle vous pouvez effectuer la mise à niveau de la version mineure.
  • Pour éviter toute perte de données, sauvegardez vos données.

Activer le processus de mise à niveau de la version mineure de la base de données avec un temps d'arrêt réduit

Pour activer le processus de mise à niveau de la version mineure de la base de données avec un temps d'arrêt réduit, ajoutez l'annotation suivante à votre cluster de bases de données.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

Remplacez la variable suivante :

  • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du nom du cluster de base de données que vous avez fourni lors de sa création. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

Mettre à niveau votre version AlloyDB Omni

Pour mettre à niveau votre version 16.8.0, mettez à jour les champs databaseVersion et controlPlaneAgentsVersion dans le fichier manifeste du cluster, puis réappliquez le fichier.

Voici le début d'un fichier manifeste qui spécifie la version 16.8.0 pour databaseVersion et la version 1.5.0 pour controlPlaneAgentsVersion :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "16.8.0"
    controlPlaneAgentsVersion: "1.5.0"
...

Remplacez la variable suivante :

  • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du nom du cluster de base de données que vous avez fourni lors de sa création. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

Surveiller le processus de mise à niveau

Une fois que vous avez mis à jour votre fichier manifeste, l'opérateur AlloyDB Omni lance le processus de mise à niveau. Pour surveiller le processus de mise à niveau, vérifiez la condition DBCUpgradeInProgress.

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

Remplacez la variable suivante :

  • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du nom du cluster de base de données que vous avez fourni lors de sa création. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

Pendant le processus, l'état est true. Une fois le processus terminé, l'état de la condition passe à false.

Dépannage

Si vous recevez des messages d'échec pendant le processus de migration, consultez les sections suivantes :

Échecs avant la mise à niveau

Si vous recevez un message d'échec de la pré-mise à niveau sur votre cluster de bases de données, vérifiez le message et résolvez le problème en conséquence.

Si vous souhaitez ignorer le message d'échec de la pré-mise à niveau, vous pouvez activer l'annotation force-upgrade.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

Remplacez la variable suivante :

  • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du nom du cluster de base de données que vous avez fourni lors de sa création. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

Une fois le processus de mise à niveau terminé, définissez l'annotation force-upgrade sur false.

Échecs de mise à niveau

Lors du processus de mise à niveau automatique, plusieurs points peuvent échouer dans les environnements HA. Pour en savoir plus sur chaque scénario d'échec et sur les actions ultérieures effectuées par l'opérateur AlloyDB Omni, consultez le tableau suivant.

Message d'échec Description Actions utilisateur requises
standby instance upgrade succeeded but the replication lag of the standby(s) is too high to be promoted to synchronous standby(s)

La mise à niveau a réussi, mais l'instance de secours n'a pas rattrapé l'instance principale pour établir la réplication synchrone.

Une grande partie du trafic est dirigée vers l'instance principale. À mesure que le trafic diminue, l'instance de secours se rattrape progressivement. Une fois cette opération effectuée, la condition HAReady devient true.

Choisissez une option dans Corriger les instances principale et de secours avec des versions mineures différentes .

all standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby.

La mise à niveau de vos instances de secours a réussi, mais le processus de basculement a échoué.

  1. Vérifiez l'état de la ressource personnalisée de basculement pour déterminer la cause de l'échec.
  2. Choisissez une option dans Corriger les instances principale et de secours avec des versions mineures différentes .
standby instance upgrade failed but rollback succeeded.

La mise à niveau de votre instance de secours a échoué, mais l'opérateur AlloyDB Omni l'a restaurée avec succès dans sa version précédente.

  1. Vérifiez les messages d'échec de la mise à niveau.
  2. Choisissez une option dans Corriger les instances principale et de secours avec des versions mineures différentes .
standby instance upgrade failed and rollback failed.

La mise à niveau de votre instance de secours a échoué et l'opérateur AlloyDB Omni ne peut pas restaurer l'instance vers sa version précédente.

Contactez l'assistance Google pour résoudre le problème.

Corriger les instances principale et de secours avec des versions mineures différentes

Pour résoudre ce problème, choisissez l'une des options suivantes :

  • Si le problème à l'origine de l'échec de la mise à niveau est résolu, réessayez.

    Pour réessayer la mise à niveau, supprimez l'annotation start-time de votre instance. Une fois l'annotation supprimée, l'opérateur AlloyDB Omni génère une nouvelle heure de début et relance le processus de mise à niveau.

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-
    

    Remplacez la variable suivante :

    • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du nom du cluster de base de données que vous avez fourni lors de sa création. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.
  • Si le problème à l'origine de l'échec de la mise à niveau persiste, rétrogradez votre instance vers la version précédente de l'opérateur AlloyDB Omni.

    Pour rétrograder votre instance, suivez la procédure de mise à niveau et remplacez les champs databaseVersion et controlPlaneAgentsVersion du fichier manifeste par la version que vous utilisiez auparavant.