# Rétrogradation d'etcd de la version v3.6 à la v3.5 > Processus, listes de vérification et notes sur la rétrogradation 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 d'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 [commencer la rétrogradation](#downgrade-procedure), lisez le reste du présent guide afin de vous préparer. ### Listes de vérification pour la rétrogradation {#downgrade-checklists} Principaux changements avec rupture de compatibilité entre v3.6 et 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 rétrogradation 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 rétrogradation du serveur {#server-downgrade-checklists} #### Exigences de rétrogradation {#downgrade-requirements} Pour garantir une rétrogradation 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 rétrograder 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 d'etcd. Avant de commencer, téléchargez la dernière version d'etcd v3.5. #### Versions mixtes {#mixed-versions} Lors d'une rétrogradation, 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 rétrogradé une fois que la rétrogradation est activée par `etcdctl downgrade enable 3.5`. En interne, la version globale du cluster est définie sur la version cible de la rétrogradation, ce qui contrôle la version signalée et les fonctionnalités prises en charge. #### Retour en arrière {#rollback} Avant de procéder à la rétrogradation 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 rétrogradation si nécessaire. Si des utilisateurs rencontrent des problèmes lors de la rétrogradation, ils doivent d'abord identifier et résoudre la cause racine. Si la rétrogradation a commencé après l'exécution de `etcdctl downgrade enable`, 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 rétrogradation en cours en exécutant `etcdctl downgrade cancel`, puis en redémarrant tous les membres rétrogradés 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é une rétrogradation complète, ils doivent suivre le guide officiel de [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 rétrogradation 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 rétrogradation activé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 rétrogradation 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 rétrograder 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 <