Часть 6. Как обновлять мульти-ноды: без простоев и с головой

donald

Модератор
Команда форума
Местный
Регистрация
29.09.2025
Сообщения
49
Поддерживать мульти-ноды в актуальном состоянии — это не просто рекомендация, а необходимость. Обновления приносят не только новые фичи, но и критические исправления, важные изменения в конфиге и подготовку к хардфоркам.

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

Общий принцип: не обновляй всё сразу

Если у тебя на сервере крутятся сразу 3, 5 или 10 нод — не обновляй их одновременно.
Всегда начинай с одной.
Убедись, что всё работает, что она подхватила сеть, не выпала из консенсуса и не упала.
Только потом переходи к остальным.
Так ты избежишь ситуации, когда все ноды вылетели из строя из-за одного некорректного обновления.

Обновление бинарников

Для нод, которые работают не в контейнерах, а запускаются вручную или через systemd, процесс обновления такой:
  1. Останови ноду. systemctl stop nodename или просто заверши процесс, если он в screen/tmux.
  2. Сделай резерв. Скопируй config.toml, app.toml, priv_validator_key.json, node_key.json и т.д. База блоков (data/) обычно не требует бэкапа, но если места хватает — не помешает.
  3. Заменить бинарник. Скачай свежую версию (wget, curl, git pull, make build, в зависимости от проекта) и положи поверх старой.
  4. Проверь зависимости. Если бинарник требует новую версию Go, Rust или другого окружения — обнови её до начала.
  5. Перезапусти и смотри логи. Убедись, что нода стартанула без ошибок, начала синхронизацию и подключилась к пирам.

Обновление Docker-контейнеров

Если ты используешь контейнеры, обновление делается в пару шагов:
  1. Скачай новый образ: docker pull repo/name:new_tag
  2. Останови старый контейнер: docker stop nodename && docker rm nodename
  3. Запусти новый: Используй тот же docker run или docker-compose, но с новой версией образа.
  4. Проверь, что volume остался: Блокчейн должен храниться в --volume или -v. Контейнер можно сносить, но том — нет.
Совет: храни docker-команды для всех нод в одном deploy.sh — это ускорит массовый перезапуск и уменьшит шанс забыть аргументы.

Хардфорки и миграции

Хардфорк — это когда старая версия перестаёт быть валидной на определённой высоте блока.
Чтобы не вылететь из сети:

  • Следи за новостями проекта. Уточни точную высоту или дату форка.
  • Обновись до неё. Желательно — за день-два. Не жди последнего часа: если обновление кривое, у тебя будет время на откат или исправление.
  • Используй cosmovisor (или аналоги). Это инструмент, который автоматически переключает ноду на нужную версию при достижении блока-форка. Особенно актуально для Cosmos-сетей.
  • Проверь chain-id и версию. После форка иногда меняется chain-id. Проверь, что твоя нода в правильной сети.
  • Тестируй на dev/тестнете. Если проект предоставляет тестовую сеть, лучше там проверить все шаги заранее.

Вывод

Обновление — это не про нажать «обновить» и забыть.
Это про подготовку, контроль и аккуратность.
Неважно, одна у тебя нода или десять — подход должен быть системный.

Следи за релизами, работай с шаблонами, делай бэкапы и тестируй всё в изолированной среде.
Тогда ни один хардфорк, миграция или внезапный баг тебя не застанут врасплох.
 
Назад
Верх