Відкат валідатора Solana до попередньої версії — це керована процедура заміни бінарного файлу та перезапуску ноди з існуючим ledger. Нижче наведено повний операційний цикл: від прийняття рішення до підтвердження стабільності після відкату.
Операційні вимоги для «Як виконати відкат валідатора до попередньої версії» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Середовище перевірки: клієнт Agave, кластер mainnet-beta, Ubuntu 24.04 LTS. Точні версії бінарних файлів та хеші перевірте в офіційному репозиторії на момент виконання процедури.
Коли відкат є необхідним
Відкат — не рутинна операція, а реактивна міра. Виконуйте її за таких умов:
- Критичний дефект нової версії. Валідатор втрачає консенсус, генерує некоректні голоси або зупиняється з помилкою panic у циклі.
- Деградація продуктивності. Зростання використання CPU чи RAM понад очікувані значення, що призводить до пропуску слотів (skip rate вище норми).
- Несумісність ledger. Нова версія не може прочитати існуючий стан ledger через зміну формату або активацію функції, яку старіша версія ще не підтримує.
- Рекомендація мережі. Офіційна команда або валідатор-ком'юніті рекомендують відкат через виявлену проблему в релізі.
Важливо: якщо проблема пов'язана з активацією нової функції протоколу (feature gate), відкат може бути неможливим — старіша версія просто не зможе обробити новий стан мережі. У такому разі єдиний шлях — чекати на патч у межах тієї ж гілки версій.
Зупинка поточного валідатора
Перед заміною бінарного файлу валідатор має бути коректно зупинений. Різке завершення процесу (kill -9) може призвести до пошкодження стану, хоча Solana ledger розроблений з урахуванням crash-стійкості.
- Зупиніть сервіс через systemd:
sudo systemctl stop solana - Перевірте, що процес завершено:
sudo systemctl status solana
Очікуваний результат: inactive (dead). - Перевірте відсутність залишкових процесів:
ps aux | grep agave-validator
Якщо процеси залишилися, завершіть їх: sudo pkill -f agave-validator - Зафіксуйте час зупинки у журналі операцій — це знадобиться для аналізу пропущених слотів.
Ризик: під час зупинки валідатор не голосує і не пропонує блоки. Тривалість простою безпосередньо впливає на відсоток пропущених слотів і, відповідно, на винагороду.
Переключення на резервний бінарний файл
Цей крок припускає, що ви зберегли попередній бінарний файл перед оновленням. Якщо резервної копії немає — її треба завантажити з офіційного релізу та перевірити хеш.
Якщо резервний бінарний файл збережено локально
- Перевірте наявність резервної копії:
ls -la /opt/solana/backup/agave-validator - Перевірте хеш-суму резервного файлу з офіційними даними релізу:
sha256sum /opt/solana/backup/agave-validator - Зробіть резервну копію поточного (проблемного) бінарного файлу перед заміною:
sudo cp /usr/local/bin/agave-validator /usr/local/bin/agave-validator.broken - Замініть поточний бінарний файл на резервний:
sudo cp /opt/solana/backup/agave-validator /usr/local/bin/agave-validator - Перевірте версію:
agave-validator --version
Очікуваний результат: версія має збігатися з тією, на яку виконується відкат.
Якщо резервної копії немає
- Завантажте потрібну версію з офіційного релізу (перевірте точний URL у репозиторії Agave).
- Перевірте хеш-суму завантаженого файлу.
- Встановіть права на виконання:
chmod +x agave-validator - Замініть поточний бінарний файл, попередньо зберігши проблемний (див. крок 3 вище).
Попередження: ніколи не замінюйте бінарний файл без попереднього збереження поточного. Якщо відкат не вирішить проблему, вам потрібен буде шлях повернення до початкового стану для діагностики.
Перевірка ledger на сумісність
Перш ніж запускати валідатор зі старішою версією, переконайтеся, що ledger сумісний.
- Запустіть перевірку ledger інструментом ledger-tool:
solana-ledger-tool verify --ledger /mnt/ledger - Якщо verify завершується помилкою, пов'язаною з невідомою функцією протоколу або форматом, відкат неможливий — ledger містить дані, які старіша версія не розуміє.
- Перевірте, чи немає у ledger слотів з активаціями feature gate, які відсутні в цільовій версії:
solana-ledger-tool slot --ledger /mnt/ledger
Порівняйте останній оброблений слот із часом оновлення. Якщо після оновлення відбулася активація нової функції протоколу — відкат заблокований.
Критичне обмеження: якщо мережа вже активувала feature gate, який не підтримується старішою версією, відкат призведе до неможливості синхронізації. У такому разі не запускайте валідатор на старій версії — зверніться до каналу валідаторів за роз'ясненнями.
Перезапуск та синхронізація
- Запустіть валідатор:
sudo systemctl start solana - Негайно перевірте журнали:
sudo journalctl -u solana -f - Очікувані записи в журналі при успішному старті:
- Ініціалізація ledger з вказаного шляху
- Підключення до gossip-мережі
- Початок отримання слотів (slot ticks)
- Перші голоси (vote)
- Якщо валідатор відставав під час зупинки, він увійде в режим catchup. Моніторьте прогрес у журналах — має з'явитися повідомлення про catchup з вказанням початкового та цільового слота.
- Перевірте статус через CLI:
solana validator-info
solana slot
Ризик: якщо catchup триває надто довго (більше кількох хвилин на mainnet-beta), перевірте мережеве з'єднання та доступність RPC-вузлів, зазначених у конфігурації.
Моніторинг після відкату
Після успішного перезапуску контролюйте такі метрики:
| Метрика | Як перевірити | Нормальне значення |
|---|---|---|
| Skip rate | solana block-production або зовнішній моніторинг | Близько 0%, не вище 2–3% |
| Відстань до кореня (root distance) | Журнали: root slot | Не зростає стабільно |
| Голосування (vote credits) | solana vote-account <ADDRESS> | Зростає з кожним епохою |
| Статус делінквентності | solana validators | Відсутній у списку delinquent |
| Використання ресурсів | htop, iostat | В межах типових значень для вашого обладнання |
Якщо skip rate зростає або валідатор з'являється у статусі delinquent протягом перших 10–15 хвилин після відкату — негайно перевірте журнали на предмет помилок консенсусу або несумісності.
Повідомлення команди та стейкерів
Відкат валідатора — подія, яка безпосередньо впливає на делегаторів. Прозоре комунікування знижує ризик відпливу стейку та підвищує довіру до операційної команди.
- Внутрішня команда. Зафіксуйте подію в операційному журналі (runbook log): час зупинки, причину, версії (з якої і на яку), результат перевірки ledger, час відновлення.
- Стейкери та делегатори. Опублікуйте коротке повідомлення у каналах, де ви спілкуєтеся з делегаторами (Discord, Telegram, Twitter). Вкажіть: причину відкату, тривалість простою, поточний статус, чи вплинуло це на делеговані кошти (відкат не впливає на баланс SOL, але може зменшити винагороду за поточну епоху через пропущені слоти).
- Мережева спільнота. Якщо проблема в релізі може зачепити інших валідаторів, повідомте про неї у відповідному каналі (Validator Discord). Це допоможе іншим уникнути тієї ж ситуації.
Наступний крок: після стабілізації валідатора на старішій версії варто проаналізувати причину проблеми в новому релізі та підготуватися до повторного оновлення після виходу патчу. Дивіться також Як перевірити нову версію Agave перед оновленням для коректної процедури тестування.