Операційні вимоги для «Як оновити валідатор без зайвого простою» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.

Оновлення валідатора Solana з мінімальним простоєм — це не про магічні команди, а про послідовну підготовку: завантажити бінарний файл заздалегідь, верифікувати його, зупинити процес на секунди, замінити виконуваний файл і запустити знову. Нижче — повний операційний цикл від перевірки версії до стабілізації після оновлення.

Чому регулярні оновлення критичні

Клієнт Agave (спадкоємець solana-labs/solana, який тепер підтримується командою Anza) отримує релізи часто: виправлення консенсусних багів, патчі безпеки, оптимізація памʼяті та мережевого стека. Пропущене оновлення означає:

  • Ризик відставання від суперменшості — валідатор з застарілою версією не може голосувати за форки й втрачає кредити.
  • Вразливості, які вже закриті в нових релізах, але відкриті на вашому вузлі.
  • Накопичення технічного боргу: чим більший стрибок версій, тим вищий шанс несподіваної поведінки при оновленні.

Оперативне оновлення на кожен стабільний реліз — це базова гігієна інфраструктури, а не бажання бути «на передовій».

Перевірка актуальної версії Agave

Перед будь-якими діями визначте, що саме запущено на сервері, і порівняйте з останнім стабільним релізом у репозиторії Anza/agave на GitHub.

Середовище перевірки: Ubuntu 24.04 LTS, клієнт Agave, кластер mainnet-beta. Перевірено станом на червень 2025 року.

Команда на активному валідаторі:

agave-validator --version

Очікуваний результат — рядок із версією, наприклад agave-validator 2.2.x (конкретне значення залежить від дня перевірки — порівняйте з тегами у репозиторії Anza/agave).

Додатково перевірте, чи валідатор фактично синхронізований і голосує:

solana validator-info

solana catchup <YOUR_PUBKEY> --our-localhost

Якщо валідатор відстає (catchup показує відʼємне значення слотів) — оновлення в цей момент не починайте. Спочатку усуньте причину відставання.

Завантаження та верифікація нового release

Ніколи не завантажуйте бінарні файли з неперевірених джерел. Використовуйте офіційні релізи з репозиторію Anza/agave.

Завантаження

Знайдіть потрібний тег релізу на сторінці Releases у репозиторії Anza/agave. Скачайте архів для вашої архітектури (зазвичай x86_64-linux):

wget -O solana-release.tar.bz2 <URL_РЕЛІЗУ_З_GITHUB>

Де <URL_РЕЛІЗУ_З_GITHUB> — пряме посилання на файл solana-release-x86_64-linux.tar.bz2 з обраного релізу. Перевірте, що URL веде саме на github.com та містить правильний тег версії.

Верифікація

Кожен офіційний реліз супроводжується контрольними сумами (SHA256) та підписами. Перевірте обидва:

  1. Контрольна сума: порівняйте sha256sum solana-release.tar.bz2 із значенням із файлу sha256sum.txt у тому ж релізі.
  2. Підпис: якщо реліз підписаний GPG-ключем розробників, верифікуйте його. Ключі публікуються в репозиторії проєкту.

Якщо хоча б один крок не збігається — зупиніться. Не розпаковуйте й не запускайте цей файл.

Розпакування в тимчасову директорію

mkdir -p /tmp/solana-update
tar -xjf solana-release.tar.bz2 -C /tmp/solana-update

Переконайтеся, що в розпакованій директорії є виконуваний файл agave-validator:

/tmp/solana-update/solana-release/bin/agave-validator --version

Версія має збігатися з тегом релізу, який ви завантажили.

Стратегія rolling update

Поняття «rolling update» залежить від вашої інфраструктурної конфігурації:

  • Один валідатор на одному сервері. Повного нульового простою досягти неможливо — процес потрібно зупинити. Але за рахунок попередньої підготовки простої скорочується до секунд: бінарний файл вже завантажений, верифікований і готовий до заміни.
  • Кілька валідаторів або RPC-вузлів за балансувальником. Тут справжній rolling update: оновлюєте вузли по одному, перевіряєте здоровʼя, балансувальник автоматично направляє трафік на живі вузли. Кінцеві користувачі не помічають перебоїв.
  • Гаряче резервування (hot spare). Другий сервер із тією самою identity-пари вже запущений на новій версії. Перемикаєте DNS або балансувальник — нульовий простій. Увага: два вузли з однаковою identity не можуть одночасно голосувати, це призведе до дублювання голосів і штрафів.

Для типової конфігурації «один валідатор — один сервер» нижче описана процедура з мінімізацією вікна простою.

Кроки оновлення з мінімальним downtime

Передумови: валідатор синхронізований, голосує, бінарний файл нового релізу верифікований у /tmp/solana-update.

Очікуваний результат: валідатор зупинений, бінарний файл замінений, процес запущений на новій версії. Простій — від кількох секунд до хвилини.

Ризики: якщо нова версія несумісна з поточним станом леджера, валідатор може не стартувати. Тому обовʼково створіть резервну копію бінарного файля перед заміною.

Крок 1. Резервна копія поточного бінарного файлу

sudo cp /usr/local/bin/agave-validator /usr/local/bin/agave-validator.bak

Це ваш шлях назад без повторного завантаження.

Крок 2. Зупинка валідатора

Якщо використовуєте systemd:

sudo systemctl stop agave-validator

Перевірте, що процес зупинився:

sudo systemctl status agave-validator

Має бути стан inactive (dead).

Крок 3. Заміна бінарного файлу

sudo cp /tmp/solana-update/solana-release/bin/agave-validator /usr/local/bin/agave-validator

Перевірте, що заміна відбулася:

agave-validator --version

Крок 4. Запуск валідатора

sudo systemctl start agave-validator

Відразу перевірте статус:

sudo systemctl status agave-validator

Процес має бути active (running).

Крок 5. Спостереження за логами

sudo journalctl -u agave-validator -f

Шукайте такі ознаки здорового старту:

  • Завантаження леджера з існуючої директорії (--ledger /mnt/ledger або ваш шлях).
  • Підключення до мережі, отримання слотів.
  • Початок голосування (vote у логах).

Типові попередження під час першого старту на новій версії (наприклад, реконциліація леджера) — нормальні, якщо процес не зупиняється.

Перевірка після оновлення

Після старту виконайте серію перевірок у такому порядку:

  1. Версія: agave-validator --version — підтверджує, що запущено саме новий реліз.
  2. Синхронізація: solana catchup <YOUR_PUBKEY> --our-localhost — значення має бути близьке до нуля або позитивне. Відʼємне означає відставання.
  3. Голосування: у логах або через моніторинг переконайтеся, що валідатор регулярно відправляє голоси (vote transactions).
  4. Кредити за епоху: перевірте через експлорер або CLI, що кредити продовжують нараховуватися. Падіння кредитів у поточній епосі після оновлення — нормальне, оскільки частина епохи пройшла без голосів. Оцінюйте результат у наступній епосі.
  5. Споживання ресурсів: htop, iostat — переконайтеся, що нова версія не викликає аномального навантаження на CPU, RAM або дискову підсистему.

Якщо всі пункти в нормі — оновлення завершено успішно.

Що робити, якщо щось пішло не так

Розділіть проблеми на два типи: валідатор не стартує взагалі та валідатор стартує, але поводиться аномально.

Валідатор не стартує

Найчастіша причина — несумісність версії леджера з новим бінарним файлом (рідкісно, але трапляється при стрибках через кілька мажорних версій). Перевірте логи:

sudo journalctl -u agave-validator --no-pager -n 50

Якщо бачите помилку формату леджера або несумісності — негайно відкотіть бінарний файл:

sudo systemctl stop agave-validator
sudo cp /usr/local/bin/agave-validator.bak /usr/local/bin/agave-validator
sudo systemctl start agave-validator

Після відкату перевірте здоровʼя за процедурою з попереднього розділу. Повний план відкату з урахуванням леджера, конфігурації та identity-файлів розглянуто в окремому матеріалі — Як підготувати план відкату валідатора.

Валідатор стартує, але відстає або не голосує

  1. Дайте йому 2–3 хвилини: після оновлення клієнт може виконувати додаткову роботу з леджером (replay, snapshot reconciliation).
  2. Якщо відставання зростає перевищує 100 слотів і не зменшується — перевірте мережеве зʼєднання, дискову швидкість та наявність достатнього місця на диску з леджером.
  3. Якщо проблема зберігається після 5 хвилин — відкотіть бінарний файл за процедурою вище.

Коли не варто відкочувати

Якщо валідатор голосує, синхронізований, але ви бачите нові попередження в логах, які не призводять до зупинки процесу — це може бути нова діагностика в релізі. Перевірте release notes обраної версії: розробники часто додають нові лог-повідомлення, які не є помилками.

Якщо оновлення пройшло без ускладнень, а ви плануєте масштабніші зміни інфраструктури — наступний логічний крок розглянуто в матеріалі Як перенести валідатор на новий сервер без втрати даних.

Джерела