# Rétrogradation d'etcd de la version v3.6 à la v3.5 > Processus, listes de vérification et notes sur la mise à jour inverse d'etcd de la version 3.6 à la version 3.5 --- Index LLMS : [llms.txt](/fr/llms.txt) --- Dans le cas général, la rétrogradation de etcd v3.6 vers v3.5 peut s'effectuer sans interruption de service, en mode rolling : - un à un, arrêtez les processus etcd v3.6 et remplacez-les par des processus etcd v3.5 - après avoir activé la rétrogradation, les nouvelles fonctionnalités de la version v3.6 ne sont plus disponibles pour le cluster Avant de [effectuer une mise vers une version antérieure](#downgrade-procedure), lisez le reste du présent guide afin de vous préparer. ### Listes de vérification pour la mise à jour vers une version antérieure {#downgrade-checklists} Changements importants marquants de la version v3.6 à la v3.5 : #### Différence entre les drapeaux {#difference-in-flags} Si vous utilisez l'un des drapeaux suivants dans vos configurations v3.6, veillez à les supprimer, les renommer ou modifier leur valeur par défaut lors de la mise à jour vers la version v3.5. > [!NOTE] > La différence est basée sur les versions v3.6.0 et v3.5.18. La différence réelle dépend de votre version de correctif ; vérifiez d'abord avec `diff <(etcd-3.6/bin/etcd -h | grep \\-\\-) <(etcd-3.5/bin/etcd -h | grep \\-\\-)`. ```diff # flags not available in v3.5 -etcd --discovery-token '' -etcd --discovery-endpoints '' -etcd --discovery-dial-timeout '2s' -etcd --discovery-request-timeout '5s' -etcd --discovery-keepalive-time '2s' -etcd --discovery-keepalive-timeout '6s' -etcd --discovery-insecure-transport 'true' -etcd --discovery-insecure-skip-tls-verify 'false' -etcd --discovery-cert '' -etcd --discovery-key '' -etcd --discovery-cacert '' -etcd --discovery-user '' -etcd --discovery-password '' -etcd --feature-gates -etcd --log-format # same flag with different names -etcd --bootstrap-defrag-threshold-megabytes +etcd --experimental-bootstrap-defrag-threshold-megabytes -etcd --compaction-batch-limit +etcd --experimental-compaction-batch-limit -etcd --compact-hash-check-time +etcd --experimental-compact-hash-check-time -etcd --compaction-sleep-interval +etcd --experimental-compaction-sleep-interval -etcd --corrupt-check-time +etcd --experimental-corrupt-check-time -etcd --enable-distributed-tracing +etcd --experimental-enable-distributed-tracing -etcd --distributed-tracing-address +etcd --experimental-distributed-tracing-address -etcd --distributed-tracing-instance-id +etcd --experimental-distributed-tracing-instance-id -etcd --distributed-tracing-sampling-rate +etcd --experimental-distributed-tracing-sampling-rate -etcd --distributed-tracing-service-name +etcd --experimental-distributed-tracing-service-name -etcd --downgrade-check-time +etcd --experimental-downgrade-check-time -etcd --max-learners +etcd --experimental-max-learners -etcd --memory-mlock +etcd --experimental-memory-mlock -etcd --peer-skip-client-san-verification +etcd --experimental-peer-skip-client-san-verification -etcd --snapshot-catchup-entries +etcd --experimental-snapshot-catchup-entries -etcd --warning-apply-duration +etcd --experimental-warning-apply-duration -etcd --warning-unary-request-duration +etcd --experimental-warning-unary-request-duration -etcd --watch-progress-notify-interval +etcd --experimental-watch-progress-notify-interval # equivalent flags of v3.6 feature gates -etcd --feature-gates=CompactHashCheck=true +etcd --experimental-compact-hash-check-enabled=true -etcd --feature-gates=InitialCorruptCheck=true +etcd --experimental-enable-initial-corrupt-check=true -etcd --feature-gates=LeaseCheckpoint=true +etcd --experimental-enable-lease-checkpoint=true -etcd --feature-gates=LeaseCheckpointPersist=true +etcd --experimental-enable-lease-checkpoint-persist=true -etcd --feature-gates=StopGRPCServiceOnDefrag=true +etcd --experimental-stop-grpc-service-on-defrag=true -etcd --feature-gates=TxnModeWriteWithSharedBuffer=false +etcd --experimental-txn-mode-write-with-shared-buffer=false # same flag different defaults -etcd --snapshot-count=10000 +etcd --snapshot-count=100000 -etcd --v2-deprecation='write-only' +etcd --v2-deprecation='not-yet' -etcd --discovery-fallback='exit' +etcd --discovery-fallback='proxy' ``` #### Différence entre les métriques Prometheus {#difference-in-prometheus-metrics} ```diff # metrics not available in v3.5 -etcd_network_known_peers -etcd_server_feature_enabled ``` ### Liste de vérification pour la mise à jour vers une version antérieure du serveur {#server-downgrade-checklists} #### Exigences de mise à jour vers une version antérieure {#downgrade-requirements} Pour garantir une mise à jour descendante progressive sans incident, le cluster en cours d'exécution doit être sain. Vérifiez l'état du cluster à l'aide de la commande `etcdctl endpoint health` avant de poursuivre. #### Préparation {#preparation} Avant de procéder à une mise vers une version antérieure d’etcd, testez toujours les services dépendants d’etcd dans un environnement de préproduction avant de déployer la mise à jour vers l’environnement de production. Avant de commencer, [téléchargez l'instantané de sauvegarde](/fr/docs/etcd/op-guide/maintenance/#snapshot-backup). Si une erreur survient lors de la rétrogradation, il sera possible d'utiliser cette sauvegarde pour [annuler](#rollback) la mise à jour et revenir à la version existante de etcd. Avant de commencer, téléchargez la dernière version de etcd v3.5. #### Versions mixtes {#mixed-versions} Lors d'une mise à jour vers une version inférieure, un cluster etcd prend en charge des versions mixtes de membres et fonctionne selon le protocole de la version commune la plus basse. Le cluster est considéré comme mis à jour vers une version inférieure une fois que la mise à jour vers une version inférieure est activée par `etcdctl downgrade enable 3.5`. Internement, la version globale du cluster est définie sur la version cible de la mise à jour vers une version inférieure, ce qui contrôle la version signalée et les fonctionnalités prises en charge. #### Annuler {#rollback} Avant de procéder à la mise à jour inférieure de votre cluster etcd, créez et [téléchargez une sauvegarde sous forme d'instantané](/fr/docs/etcd/op-guide/maintenance/#snapshot-backup) de votre cluster etcd. Cet instantané peut être utilisé pour restaurer le cluster dans son état antérieur à la mise à jour si nécessaire. Si des utilisateurs rencontrent des problèmes lors de la mise à jour inférieure, ils doivent d'abord identifier et résoudre la cause racine. Si la désinstallation a commencé après l'exécution de `etcdctl downgrade enabled`, et que le cluster est toujours dans un état mixte — où au moins un membre reste sur la version v3.6 —, les utilisateurs peuvent annuler le processus de mise à jour en cours en exécutant `etcdctl downgrade cancel`, puis en redémarrant tous les membres mis à jour avec les binaires d'origine v3.6. Une fois que tous les membres ont été rétrogradés vers la version v3.5, le cluster est considéré comme entièrement rétrogradé. Si les utilisateurs souhaitent revenir à la version d'origine après avoir achevé un rétrogradation complète, ils doivent suivre le guide officiel d'[mise à jour](/fr/docs/etcd/upgrades/upgrade_3_6/) afin d'assurer la cohérence et d'éviter toute corruption des données. ### Procédure de rétrogradation {#downgrade-procedure} Cet exemple montre comment effectuer une mise à jour inverse d’un cluster etcd v3.6 à trois membres fonctionnant sur une machine locale. #### Étape 1 : vérifier les conditions de rétrogradation {#step-1-check-downgrade-requirements} Le cluster est-il sain et en cours d'exécution sous la version 3.6.x ? ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint health < [!NOTE] > Une fois la désinstallation autorisée, le cluster continuera à fonctionner avec le protocole v3.5, même si tous les serveurs exécutent encore le binaire v3.6, à moins que la désinstallation ne soit annulée à l’aide de `etcdctl downgrade cancel` #### Étape 5 : arrêter un serveur etcd existant {#step-5-stop-one-existing-etcd-server} Avant d'arrêter le serveur, vérifiez s'il est le leader. Nous recommandons de mettre à jour le leader en dernier. ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint status -w=table < [!NOTE] > Vous verrez que `DOWNGRADE ENABLED` est false pour le serveur v3.5, car les informations de rétrogradation ne sont pas implémentées dans le point de terminaison d'état de la v3.5 ; la rétrogradation reste toutefois activée pour le cluster à ce stade. #### Étape 7 : répéter *étape 5* et *étape 6* pour les membres restants {#step-7-repeat-step-5-and-step-6-for-rest-of-the-members} Lorsque tous les membres sont rétrogradés, vérifiez l’état et la santé du cluster, puis confirmez que la version mineure de tous les membres est v3.5 et que la version de stockage est vide : ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint status -w=table <