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 mineure de la version de la 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 permet de minimiser les temps d'arrêt 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 en 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 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 la procédure de mise à niveau des versions mineures 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 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 17.5.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 17.5.0 pour databaseVersion et la version 1.6.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 base de données. Les valeurs valides sont Debian et UBI9. Si vous ne le spécifiez pas, l'opérateur le définit automatiquement sur Debian si databaseVersion est inférieur à 16.9.0, et sur UBI9 si databaseVersion est 16.9.0 ou ultérieur.

Surveiller le processus de mise à niveau

Une fois le fichier manifeste mis à jour, 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 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 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 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 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 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 à 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 dans sa version précédente.

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

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

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 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 à 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, controlPlaneAgentsVersion et databaseImageOSType dans le fichier manifeste par la version que vous utilisiez auparavant.