# Rétrogradation d'etcd de la version 3.5 à la 3.4 > Processus, listes de vérification et notes sur la mise à jour inverse d'etcd de la version 3.5 à la 3.4 --- Index LLMS : [llms.txt](/fr/llms.txt) --- Dans le cas général, la rétrogradation de etcd 3.5 vers 3.4 peut s'effectuer sans interruption de service, en mode rolling : - un par un, arrêtez les processus etcd 3.5 et remplacez-les par des processus etcd 3.4 - après avoir lancé des processus 3.4, les nouvelles fonctionnalités de 3.5 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} content/enhttps://etcd.io/docs/v3.5/op-guide/authentication/rbac.md > [!WARNING] > Si votre cluster a activé l'authentification, la mise à jour rétrograde depuis la version 3.5 n'est pas prise en charge, car la version 3.5 [modifie le format des entrées WAL liées à l'authentification](https://github.com/etcd-io/etcd/pull/11943). Vous pouvez suivre les [instructions d'authentification](/fr/docs/etcd/op-guide/authentication/rbac/) pour désactiver l'authentification, puis supprimer tous les utilisateurs. Changements importants ayant pour effet de rupture entre 3.5 et 3.4 : #### Différence entre les drapeaux {#difference-in-flags} Si vous utilisez l'un des drapeaux suivants dans vos configurations 3.5, veillez à les supprimer, les renommer ou modifier leur valeur par défaut lors de la mise à jour vers la version 3.4. > [!NOTE] > La différence est basée sur les versions 3.5.14 et 3.4.33. La différence réelle dépend de votre version de correctif ; vérifiez d'abord avec `diff <(etcd-3.5/bin/etcd -h | grep \\-\\-) <(etcd-3.4/bin/etcd -h | grep \\-\\-)`. ```diff # flags not available in 3.4 -etcd --socket-reuse-port -etcd --socket-reuse-address -etcd --raft-read-timeout -etcd --raft-write-timeout -etcd --v2-deprecation -etcd --client-cert-file -etcd --client-key-file -etcd --peer-client-cert-file -etcd --peer-client-key-file -etcd --self-signed-cert-validity -etcd --enable-log-rotation --log-rotation-config-json=some.json -etcd --experimental-enable-distributed-tracing --experimental-distributed-tracing-address='localhost:4317' --experimental-distributed-tracing-service-name='etcd' --experimental-distributed-tracing-instance-id='' --experimental-distributed-tracing-sampling-rate='0' -etcd --experimental-compact-hash-check-enabled --experimental-compact-hash-check-time='1m' -etcd --experimental-downgrade-check-time -etcd --experimental-memory-mlock -etcd --experimental-txn-mode-write-with-shared-buffer -etcd --experimental-bootstrap-defrag-threshold-megabytes -etcd --experimental-stop-grpc-service-on-defrag # same flag with different names -etcd --backend-bbolt-freelist-type=map +etcd --experimental-backend-bbolt-freelist-type=array # same flag different defaults -etcd --pre-vote=true +etcd --pre-vote=false -etcd --logger=zap +etcd --logger=capnslog ``` #### `etcd --logger zap` {#etcd---logger-zap} 3.4 est par défaut `--logger=capnslog` tandis que 3.5 est par défaut `--logger=zap`. Si vous souhaitez continuer à utiliser `zap`, il doit être spécifié explicitement. ```diff +etcd --logger=zap --log-outputs=stderr +# to write logs to stderr and a.log file at the same time +etcd --logger=zap --log-outputs=stderr,a.log ``` #### Différence entre les métriques Prometheus {#difference-in-prometheus-metrics} ```diff # metrics not available in 3.4 -etcd_debugging_mvcc_db_compaction_last ``` ### 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. La version 3.4 vers laquelle effectuer la rétrogradation doit être supérieure ou égale à 3.4.32. #### 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 la sauvegarde d'instantané](/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 étcd existante. Veuillez noter que la `snapshot` commande ne sauvegarde que les données v3. Pour les données v2, consultez [sauvegarde du magasin de données v2](https://etcd.io/docs/v2.3/admin_guide#backing-up-the-datastore). Avant de commencer, téléchargez la dernière version d’etcd 3.4, et vérifiez que sa version est supérieure ou égale à 3.4.32. #### Versions mixtes {#mixed-versions} Lors d'une opération de 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é dès qu’un de ses membres est rétrogradé à la version 3.4. Internement, les membres etcd négocient entre eux afin de déterminer la version globale du cluster, qui détermine la version signalée et les fonctionnalités prises en charge. #### Limitations {#limitations} Note : Si le cluster ne contient que des données v3 et aucune donnée v2, il n'est pas soumis à cette limitation. Si le cluster sert un jeu de données v2 d'une taille supérieure à 50 Mo, chaque membre nouvellement rétrogradé peut prendre jusqu'à deux minutes pour se synchroniser avec le cluster existant. Vérifiez la taille d'un instantané récent afin d'estimer la taille totale des données. Autrement dit, il est préférable d'attendre deux minutes entre chaque rétrogradation de membre. Pour une taille totale de données bien plus importante, de 100 Mo ou plus, ce processus unique peut prendre encore plus de temps. Les administrateurs de clusters etcd très volumineux de cette ampleur peuvent librement contacter l'équipe [etcd][etcd-contact] avant la mise à jour inférieure, et nous serons heureux de leur fournir des conseils sur la procédure. #### Annuler {#rollback} Si un membre a été rétrogradé à la version 3.4, la version du cluster sera rétrogradée à 3.4, et les opérations seront compatibles avec "3.4". Vous devrez suivre les instructions [Mettre à jour etcd de 3.4 vers 3.5](/fr/docs/etcd/upgrades/upgrade_3_5/) pour effectuer un retour en arrière. Veuillez [télécharger la sauvegarde d'instantané](/fr/docs/etcd/op-guide/maintenance/#snapshot-backup) afin de permettre la remontée du cluster, même après qu'il ait été entièrement rétrogradé. ### Procédure de rétrogradation {#downgrade-procedure} Cet exemple montre comment effectuer une mise à jour vers une version antérieure d’un cluster etcd 3.5 composé de 3 membres, en cours d’exécution 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 avec la version 3.5.x ? ```bash etcdctl --endpoints=localhost:2379,localhost:22379,localhost:32379 endpoint health < `{"level":"info","ts":"2024-05-13T21:05:43.981445Z","caller":"membership/cluster.go:561","msg":"set initial cluster version","cluster-id":"ef37ad9dc622a7c4","local-member-id":"8211f1d0f64f3269","cluster-version":"3.0"}` > `{"level":"info","ts":"2024-05-13T21:05:43.982188Z","caller":"api/capability.go:77","msg":"enabled capabilities for version","cluster-version":"3.0"}` > `{"level":"info","ts":"2024-05-13T21:05:43.982312Z","caller":"membership/cluster.go:549","msg":"updated cluster version","cluster-id":"ef37ad9dc622a7c4","local-member-id":"8211f1d0f64f3269","from":"3.0","from":"3.5"}` > `{"level":"info","ts":"2024-05-13T21:05:43.982376Z","caller":"api/capability.go:77","msg":"enabled capabilities for version","cluster-version":"3.5"}` > `{"level":"info","ts":"2024-05-13T21:05:44.000672Z","caller":"etcdserver/server.go:2152","msg":"published local member to cluster through raft","local-member-id":"8211f1d0f64f3269","local-member-attributes":"{Name:infra1 ClientURLs:[http://127.0.0.1:2379]}","request-path":"/0/members/8211f1d0f64f3269/attributes","cluster-id":"ef37ad9dc622a7c4","publish-timeout":"7s"}` > `{"level":"info","ts":"2024-05-13T21:05:46.452631Z","caller":"membership/cluster.go:549","msg":"updated cluster version","cluster-id":"ef37ad9dc622a7c4","local-member-id":"8211f1d0f64f3269","from":"3.5","from":"3.4"}` ``` Vérifiez que chaque membre, puis l’intégralité du cluster, deviennent sains avec la nouvelle binaire etcd 3.4 : ```bash etcdctl endpoint health --endpoints=localhost:2379,localhost:22379,localhost:32379 <