Пряме оновлення валідатора на mainnet-beta без попереднього тестування — це передчасний ризик простою та пропущених слотів. Нижче — повний операційний цикл перевірки нової версії Agave (клієнт валідатора Solana, написаний на Rust) від моменту появи release до прийняття рішення про промислове розгортання.

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

Звідки дізнатися про новий release

Нові релізи Agave з'являються в кількох перевірених джерелах. Оператору достатньо контролювати два канали:

  • GitHub-репозиторій agave — сторінка Releases містить офіційні теговані релізи з бінарними артефактами та контрольними сумами (SHA256). Саме тут публікуються стабільні версії, призначені для mainnet-beta.
  • Офіційний Discord Solana — канал announcments та робочі канали валідаторів. Тут з'являються попередження про критічні оновлення, термінові патчі та обговорення регресій, які ще не потрапили до release notes.

Рекомендована практика — налаштувати сповіщення (Watch → Custom → Releases) на GitHub-репозиторій Agave. Це гарантує, що ви отримаєте сигнал першим, а не після того, як сусідні валідатори почнуть обговорювати проблему в чаті.

Читання release notes та changelog

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

  • Breaking changes — зміни, що ламають зворотну сумісність: нові обов'язкові прапорці запуску, зміна формату локального сховища, видалення підтримки старих аргументів CLI.
  • Performance changes — модифікації, що впливають на споживання RAM, CPU, дискового вводу-виводу. Навіть позитивні зміни (наприклад, зменшення споживання пам'яті) можуть виявити приховані проблеми на вашому конкретному обладнанні.
  • Dependency updates — оновлення системних бібліотек (наприклад, jemalloc, openssl) можуть вимагати оновлення пакетів на сервері.
  • Known issues — перелік відомих проблем, які не виправлені в цьому релізі. Якщо тут є щось, що стосується вашої конфігурації, це прямий сигнал затримати оновлення.

Якщо release notes посилаються на конкретні pull requests, відкрийте їх і прочитайте обговорення. Часто саме в коментарях розкриваються крайові випадки, які не потрапили до стиснутого опису релізу.

Запуск на testnet або devnet

Жодна версія Agave не повинна потрапити на mainnet-beta без попереднього запуску на тестовому кластері. Базова послідовність:

Передумови: окремий сервер або віртуальна машина з характеристиками, що відповідають вашому production-вузлу (та сама архітектура CPU, обсяг RAM, тип диска). ОС — та сама, що на production (перевірено на Ubuntu 24.04 LTS).

  1. Завантажте бінарний файл нової версії з GitHub Releases та перевірте контрольну суму SHA256.
  2. Розпакуйте в окремий каталог, не замінюючи поточну встановлену версію.
  3. Підготуйте окремий каталог конфігурації та леджер-директорію для тестового кластера.
  4. Запустіть вузол з параметром, що вказує на testnet або devnet, та вашою production-конфігурацією (крім identity, яка має бути тестовою).

Очікуваний результат: вузол успішно синхронізується з тестовим кластером, починає обробляти слоти та не генерує критичних помилок у журналі.

Ризики: тестовий кластер може бути нестабільним сам по собі. Різниця між поведінкою на testnet і mainnet-beta існує, тому тестовий запуск виключає лише очевидні дефекти, а не гарантує ідеальну роботу.

Перевірка сумісності з поточним конфігом

Нова версія може ігнорувати або некоректно обробляти деякі параметри, які ви використовуєте. Під час тестового запуску перевірте:

  • CLI-прапорці запуску — запустіть бінарний файл з вашими повними аргументами. Якщо будь-який прапорець визнається невідомим, процес завершиться з помилкою. Це краще виявити на testnet, ніж під час перезапуску production.
  • Файл config.toml — порівняйте ваш конфіг із прикладом (sample config), який постачається з новою версією. Зверніть увагу на параметри, що змінили значення за замовчуванням або були перейменовані.
  • Леджер — переконайтеся, що нова версія коректно читає існуючий леджер тестового вузла. Зміни у форматі рахунків або слотів можуть вимагати повної ресинхронізації.
  • Системні залежності — перевірте, чи не змінилися мінімальні версії glibc, OpenSSL або інших системних бібліотек у документації до релізу.

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

Моніторинг стабільності тестового запуску

Мінімальний час спостереження за тестовим вузлом — не менше 24 годин безперервної роботи. За цей час контролюйте:

  • Журнал вузла (agave-validator.log) — відсутність panic, unwrap errors, segfault. Увагу звертайте на повторювані попередження (warnings), які можуть вказувати на деградацію.
  • Метрики споживання ресурсів — RAM, CPU, дисковий I/O. Різкі сплески або стійке зростання споживання пам'яті (memory leak) — причина відкласти оновлення.
  • Статус синхронізації — вузол не повинен відставати від голови кластера на testnet. Якщо тестовий вузол постійно відстає, це може вказувати на проблеми з продуктивністю конкретно у вашому середовищі.
  • Статистику пропущених слотів (skipped slots) — навіть на testnet аномально високе значення є тривожним сигналом.

Якщо ви використовуєте зовнішній моніторинг (Prometheus, Grafana, кастомні скрипти), підключіть тестовий вузол до тих самих дашбордів, щоб порівняти поведінку з production-вузлом на поточній версії.

Критерії переходу на production

Рішення про оновлення на mainnet-beta приймається лише після виконання всіх попередніх кроків і за наявності позитивних результатів за такими критеріями:

  • Тестовий вузол працює стабільно — жодних crash, panic або критичних помилок за весь період спостереження.
  • Споживання ресурсів не перевищує production-норми — немає витоків пам'яті, аномального навантаження на CPU або дискову підсистему.
  • Конфігурація сумісна — всі ваші CLI-прапорці та параметри config.toml приймаються без помилок.
  • Відсутність критичних звітів від інших операторів — у каналах валідаторів немає масових скарг на цю версію протягом перших годин після її появи.
  • План відкату підготовлено — у вас є збережена попередня бінарна версія, перевірена процедура відкату та готовність виконати її (детальніше — у матеріалі Як підготувати план відкату валідатора).

Якщо хоча б один критерій не виконано — оновлення відкладається до з'ясування причин. Навіть за повної відповідності критеріям рекомендується оновлюватися поза піковими навантаженнями на кластер і мати можливість негайного реагування протягом першої години після перезапуску production-вузла.

Джерела