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 |
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é. |
|
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. |
|
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
etcontrolPlaneAgentsVersion
du fichier manifeste par la version que vous utilisiez auparavant.