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 effectuer une mise à niveau de version mineure de la base de données pour AlloyDB Omni sur Kubernetes.

Pour effectuer une mise à niveau de version mineure de la base de données, vous avez deux possibilités :

  • Mise à niveau avec un temps d’arrêt réduit : cette fonctionnalité est disponible en version preview. 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 en tant que 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 : la méthode de mise à niveau simultanée est en disponibilité générale (DG). 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 à un moment donné. 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 ce processus de mise à niveau de version mineure.
  • Identifiez une période de faible trafic pendant laquelle vous pouvez effectuer la mise à niveau de version mineure.
  • Pour éviter toute perte de données, sauvegardez vos données.

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

Pour activer le processus de mise à niveau de 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 même nom de cluster de bases de données que celui que vous avez fourni lorsque vous l'avez créé. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

Mettre à niveau votre version d'AlloyDB Omni

Pour mettre à niveau votre version 18.1.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 18.1.0 pour databaseVersion et la version 1.7.0 pour controlPlaneAgentsVersion :

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "DB_VERSION"
    controlPlaneAgentsVersion: "CONTROL_PLANE_AGENTS_VERSION"
    # It is recommended to switch to UBI9 for improved security and
    # compatibility.
    # If you need to stick to Debian, set this field to "Debian".
    databaseImageOSType: "OS_TYPE"
...

Remplacez la variable suivante :

  • DB_CLUSTER_NAME : nom de votre cluster de bases de données. Il s'agit du même nom de cluster de bases de données que celui que vous avez fourni lorsque vous l'avez créé. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.
  • DB_VERSION : version de la base de données vers laquelle vous effectuez la mise à niveau.
  • CONTROL_PLANE_AGENTS_VERSION : version des agents du plan de contrôle.
  • OS_TYPE : facultatif. Système d'exploitation de base pour l'image de la base de données. Les valeurs valides sont Debian et UBI9. Si vous ne spécifiez pas cette valeur, l'opérateur la définit automatiquement sur Debian si databaseVersion est inférieur à 16.9.0, et sur UBI9 si databaseVersion est 16.9.0 ou version ultérieure.

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 même nom de cluster de bases de données que celui que vous avez fourni lorsque vous l'avez créé. 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 lors du processus de mise à niveau, consultez les sections suivantes :

Échecs préalables à la mise à niveau

Si vous recevez un échec préalable à la 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 contourner le message d'échec préalable à la 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 même nom de cluster de bases de données que celui que vous avez fourni lorsque vous l'avez créé. 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 à haute disponibilité. 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)

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

Un volume de trafic élevé est envoyé à l'instance principale. À mesure que le trafic diminue, l'instance de secours rattrape progressivement son retard. Une fois que cela se produit, la HAReady condition devient true.

Choisissez une option dans Corriger les instances principales 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 ce qui a causé l'échec.
  2. Choisissez une option dans Corriger les instances principales 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 à sa version précédente.

  1. Vérifiez les messages d'échec de la mise à niveau.
  2. Choisissez une option dans Corriger les instances principales 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 à sa version précédente.

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

Corriger les instances principales 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 qui a provoqué l'échec de la mise à niveau est résolu, réessayez la mise à niveau.

    Pour réessayer la mise à niveau, supprimez l'annotation start-time de la mise à niveau 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 même nom de cluster de bases de données que celui que vous avez fourni lorsque vous l'avez créé. Pour en savoir plus, consultez Installer AlloyDB Omni sur Kubernetes.

  • Si le problème qui a provoqué 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 le processus de mise à niveau et remplacez les champs databaseVersion, controlPlaneAgentsVersion et databaseImageOSType dans le fichier manifeste par la version que vous utilisiez auparavant.