etcd 3.7.3 — исправлен порядок репликации Raft, вызывавший задержки в кластерах

Выпуск etcd 3.7.3 от 22 октября 2026 года устраняет ошибку, из-за которой лидер кластера отправлял сообщения репликации Raft в обратном порядке. Обновление также исправляет две гонки данных и обновляет зависимости с известными уязвимостями. Самое заметное изменение касается кластеров с интенсивной записью, где прежнее поведение могло вызывать повторные передачи данных и задержки запросов.

В etcd 3.7.3 — исправлен порядок репликации Raft

Из-за неправильного порядка сообщений Raft участники кластера повторно получали данные

etcd — распределённое хранилище вида «ключ — значение». Его используют, в частности, для хранения состояния кластера Kubernetes. Несколько серверов etcd поддерживают согласованную копию данных, а алгоритм Raft помогает им договориться о порядке изменений. Один из серверов выступает лидером и передаёт остальным новые записи журнала.

В ветке 3.7 обнаружилась ошибка в обработке сообщений MsgApp. Внутренняя функция processMessages обходила сообщения от последнего к первому, отбирала нужные и передавала их дальше в обратном порядке. Последовательность записей журнала при этом нарушалась: участник кластера мог сначала получить более позднюю запись, а затем более раннюю, от которой она зависела.

Такой участник отклонял преждевременное сообщение, после чего лидер корректировал позицию передачи и отправлял данные повторно. Дополнительные обмены увеличивали нагрузку на сеть и время подтверждения операций. Исправление в etcd 3.7.3 сохраняет порядок исходных сообщений Ready, одновременно оставляя необходимую фильтрацию.

Как ошибка проявлялась под нагрузкой

В сообщении об ошибке № 22483 приведены конкретные наблюдения. В кластере из пяти участников, обрабатывавшем записи размером 12 КБ, пропускная способность etcd 3.7.1 при длительной нагрузке составляла примерно половину показателя 3.6.13. По оценке автора отчёта, актуальные участники получали каждую запись примерно 2,5–3 раза.

Другой участник обсуждения воспроизвёл проблему на пяти виртуальных машинах: в тесте с пакетом из 30 000 записей по 14 КиБ скорость снизилась с 1 728 до 589 операций записи в секунду. В журналах появлялось сообщение dropped internal Raft message since sending buffer is full, а отстающим участникам приходилось передавать полные снимки состояния.

Это результаты отдельных испытаний и конфигураций, поэтому их нельзя переносить на все установки etcd. Они объясняют, почему исправление порядка MsgApp имеет практическую ценность даже при сохранении прежних функций и API.

В RangeStream и восстановлении хранилища устранены гонки данных

Два других исправления затрагивают параллельные операции, при которых разные части программы одновременно обращаются к общим данным.

Первое связано с RangeStream в режиме keys-only, когда клиент запрашивает поток ключей без их значений. В определённых условиях параллельные потоки модифицировали общую последовательность байтов ключа во внутреннем индексе. Теперь перед добавлением служебного байта \x00 код создаёт собственную копию ключа. Это предотвращает конфликт между одновременными запросами.

Второе исправление касается сочетания операций Hash и Restore в MVCC-хранилище. Hash вычисляет хеш состояния данных, а Restore заменяет внутреннее хранилище при восстановлении снимка. Раньше чтение ссылки на хранилище и текущей ревизии выполнялось без необходимых блокировок. Разработчики согласовали доступ к этим значениям, сохранив возможность выполнять хеширование без длительной блокировки восстановления.

Для последней ошибки есть воспроизводимый тест. До исправления проверка с детектором гонок обнаруживала проблему в 40 из 40 запусков, после исправления прошли 200 из 200 запусков. Это результаты тестирования конкурентного доступа, а не измерение ускорения работы сервера.

etcd 3.7.3 обновляет OpenTelemetry, сетевые зависимости и Go

В стабильную ветку включили обновление компонентов OpenTelemetry до 1.45.0 для устранения проблемы GO-2026-6505. Библиотеку golang.org/x/net подняли до 0.61.0, закрыв проблемы GO-2026-6617, GO-2026-6612, GO-2026-6611 и GO-2026-6603.

Непосредственно перед выпуском разработчики также обновили настройки инструментальной цепочки ветки 3.7 до Go 1.26.10: это исправление связано с CVE-2026-111943. В тексте changelog на момент проверки по-прежнему указана Go 1.26.9; более позднее изменение конфигурации подтверждено отдельным принятым запросом на включение изменений.

В пакете client/pkg/v3/logutil объявлена устаревшей функция NewJournalWriter. Согласно плану разработчиков, её удаление намечено на etcd 3.8, чтобы убрать зависимость от github.com/coreos/go-systemd/v22.

Обновление etcd и Kubernetes — какие установки затрагивает релиз

Новая версия предназначена прежде всего для тех, кто непосредственно запускает и обслуживает etcd, включая отдельные кластеры и инфраструктуру управления Kubernetes. Сам факт публикации etcd 3.7.3 не означает, что каждый существующий кластер Kubernetes автоматически получил обновление: используемая версия зависит от способа развёртывания и поставщика платформы.

В официальном руководстве переход с ветки 3.6 на 3.7 описан как последовательная замена участников кластера. При этом исходная версия 3.6 должна быть не ниже 3.6.11. Документация отдельно описывает проверку состояния кластера, создание снимка перед переходом и ограничения отката после завершённого обновления всех участников.

Для уже работающих кластеров 3.7.2 релиз 3.7.3 представляет собой патч той же ветки. Здесь ключевыми изменениями выступают корректная последовательность сообщений Raft, защита конкурентных операций с данными и обновление компонентов безопасности.

Исправление Raft возвращает ожидаемый порядок обмена между серверами

Разница между etcd 3.7.2 и 3.7.3 заметнее всего в тех сценариях, где кластер постоянно записывает данные и синхронизирует их между несколькими участниками. По отчётам о предыдущих версиях, неправильная последовательность сообщений могла приводить к повторным отправкам, заполнению буфера и длительному отставанию отдельных серверов. В 3.7.3 разработчики устранили именно причину этого поведения.

Отдельных опубликованных замеров производительности уже собранного релиза 3.7.3 для широкого набора конфигураций в изученных первоисточниках нет. Поэтому величина улучшения в конкретном кластере зависит от нагрузки и того, проявлялась ли в нём ошибка раньше.